In order to replace the /api/rest_v1/page/title/{title} endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The v1/page/{title}/bare and v1/revision/{id}/bare endpoints
are functionally equivalent, so the easiest approach seemed to be to
add a compatibility mode to them. The compatibility mode is triggered
using the x-restbase-compat header, which can be set via the gateway
when routing the request from /api/rest_v1/page/title/.
Bug: T374136
Change-Id: I4af7ff5325660ae30faebb24753b9dc1c3acb2b3
Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: Idf17719c875466810313f0fbbf16bc67f3e40059
This patch lays the groundwork for incremental/selective parsing in
Parsoid by ensuring that we can pass previous cached parses through
the parse pipeline to Parsoid. We do this by adding a new render
hint type, `previous-output`, and ensuring it is passed along.
Because revisions can contain a ParserOutput which is the combination
of separate ParserOutput objects for each of their slots, RenderedRevision
also contains a method to unsplit the combined ParserOutput to reconstruct
an original ParserOutput for use in incremental parsing. Currently this
is mostly a stub, but illustrates how slot combination and splitting can
work, assuming those transformations are reversible.
Extra calls to ParserCache::getDirty() are added to some code paths
in order to ensure that any previously-cached ParserOutput is available
for selective update. In order to mitigate any performance concerns,
these are only done for the Parsoid parser at the moment. Future
patches will add additional metrics to quantify the cost/benefit ratio
of the additional cache lookups on these paths.
Bug: T363421
Bug: T371713
Change-Id: I440884f1d7e09c1ff9806f848b7b53a636367690
The generated OpenAPI spec should contain information from the info
section of module spec files.
Bug: T366834
Change-Id: I488f550adbf32205bdcdcb59b1e7f5273643bf69
The main benefit is that this syntax avoids repeating the variable
name. It does the same as before.
Change-Id: I2040be889c749f4e2416ca9948ba261345858af2
T366837 added the ability to group REST endpoints into modules.
This change now introduces the first use of a REST module.
The existing endpoints remain accessible at their original paths,
and mocha tests are run against both old and new paths.
Bug: T370430
Change-Id: I83a5cdbdd359e4d3e5f70dd3930783616b556738
Since I72c5e6f86b7f081ab5ce7a56f5365d2f75067a78 it is part of the
contract of ContentRenderer::getParserOutput() that the render ID (and
other cache parameters) will be set when it returns.
(ContentHandler::getParserOutput() can set them even earlier if it has
custom content-based overrides.) We had a lot of temporary
backward-compatibility code "later" in the parse process to try to close
the barn door if some code path "forgot" to set them, but these are
unnecessary now.
This patch removes that backward-compatibility code in ParsoidParser;
there is similar remaining code in ParserCache etc. which can be
addressed in follow ups.
(For compatibility we do have to temporarily copy the render ID code
inside ParsoidOutputAccess::parseUncachable, but that class is
deprecated and will be removed.)
The HtmlOutputRendererHelper path which used to call
ParsoidParser::parseFakeRevision() is now replaced with a codepath that
goes through RevisionRenderer. In order to maintain the same behavior
of the ParsoidHandler, we have also added 'useParsoid' handling to the
JsonContentHandler. This support can perhaps be deprecated eventually.
Bug: T350538
Change-Id: I0853624cf785f72fd956c6c2336f979f4402a68f
Instead of creating a half-initialized helper and later calling ::init,
provide all the information necessary for the helper in the constructor.
This is facilitated by the fact that there already exists a factory
class, PageRestHelperFactory, which holds all the services required.
This affects:
* HtmlOutputRendererHelper::init()
* HtmlMessageOutputHelper::init()
* HtmlInputTransformHelper::init()
Change-Id: I1e1213597c6be012f2bc024c2b370c968ff3b472
This class was @unstable and should be replaced by ParserOutputAccess.
Bug: T367074
Depends-On: I543a6e9da4fc473a2ac54ac635286453f2aff96a
Change-Id: Ie51b9b7a8b42a6faafeb28378c188347f274a9c5
This removes the last use of ParsoidOutputAccess in core, allowing it
to be deprecated and eventually removed.
Bug: T367074
Bug: T317018
Change-Id: Ica2c880e2e7c2b126aaea66a3e4be460b3f2234f
I believe this makes the code less brittle, and also makes it a bit
more obvious what these strings are meant to represent.
Change-Id: Ia39b5c80af4b495931d0a68fd091b783645dd709
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
This splits RouteFileModule into two classes, ExtraRoutesModule and
SpecBasedModule.
ExtraRoutesModule has no module prefix and supports
only "flat" route definition files and additional routes from
extension.json.
SpecBasedModule represents a single module defined in a definition
file similar to an OpenAPI spec. The idea is that a full OpenAPI spec
can be generated by filling in any missing information based on
information provided by the Handler implementation. In particular, the
definition of parameters and request body schemas will be generated.
A JSON schema for the new file format is added under docs/rest/.
Support for the intermediate format introduced in Iebcde4645d4 is
removed. It was not included in a release and was not being used outside
core tests.
Bug: T366837
Change-Id: I4ce306b0997f80b78a3d901e38bbfa8445bed604
Use more specific and less fragile assertions whenever possible;
most tests don't need to examine the internals of the status so
closely. Use StatusValue::getMessages() when necessary.
Change-Id: Ie4b3ebc03abb0e352e82394ced6ab9e733c83fb4
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I4ff4d0c10820dc2a3b8419b4115fadf81a76f7a2
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
More could be done, but to keep this patch reasonably sized, I only
changed the most obvious and unambiguously correct cases.
In some cases, I also removed redundant doc comments on the
constructor, and re-ordered the properties to match the constructor.
Change-Id: Ifa710fdf4d8d44a2d7244798b787a1b2a58c35a7
One more step in gradually replacing uses of ParsoidOutputAccess with
ParserOutputAccess. This is mostly just inlining the code from
ParsoidOutputAccess (which already uses ParserOutputAccess internally)
and then removing dead code.
Change-Id: I87d6568d9dc71bc11f406ea3c31ce86e01667e05
The default used to be 'ucs2' when linting but
Ic9b7cc0fcf365e772b7d080d76a065e3fd585f80 stopped setting the offsetType
in the environment options, which changed the output to Parsoid's
default, 'byte'.
For the parsing paths, pagebundles are now post-processed and
non-pagebundles were left as a TODO.
However, for the lint paths, it was always ok to continue setting the
environment option because Parsoid is called directly and doesn't go
through the ParserOutputAccess. The above patch was trying to limit
Parsoid specific options to that.
Bug: T365284
Change-Id: I8389c2f53b399b39a9f1d908a38aecb3abcb15ef
Ic9b7cc0fcf365e772b7d080d76a065e3fd585f80 stopped setting it as an
envOptions so pull it from the attribs when constructing.
The tests continued to set the offsetType in the envOptions, despite the
ParsoidHandler no longer doing that, so they failed to catch the error.
HtmlInputTransformHelper still considers it an envOptions though and a
cleanup could happen there too. Although, offsetType still is an
envOptions to Parsoid, so maybe it's fine as is.
Change-Id: I661a170fbb2c61308e32a43a9f6b0ce8d2ffb797
One step in gradually replacing uses of ParsoidOutputAccess with
ParserOutputAccess. This is mostly just inlining the code from
ParsoidOutputAccess (which already uses ParserOutputAccess internally)
and then removing dead code.
Change-Id: I9807149c30f4bfe06fd7ad12f96c13816c22aa9c
The `supportsContentModel` method is really querying Parsoid for the
set of content models it supports, so it makes sense to put it in the
Parsoid-specific SiteConfig service.
This is part of the work to deprecate and remove ParsoidOutputAccess.
Change-Id: I81eb2df8cef93ede95361a4e03185b3d58e5b84b
This patch introduces a namespace declaration for the
MediaWiki\Content to TextContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I2c72dacf28ee72fb70b15acdd81d0eb717ea949a
This patch introduces a namespace declaration for the
MediaWiki\Content to TextContent and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ic251b1ddfcf6db9c85cb54cddf912aa827d2bc3a
Move open search description endpoint from /w/opensource_desc.php
to /w/rest.php/v1/search.
Bug: T363984
Change-Id: Idb5b0d21adc6152ef77e6d17846b6acc6a904e01
This patch introduces a namespace declaration for the
MediaWiki\Content to CssContent and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I6ab25787893cb2195f8cd2ba125ed8dd5a60de43
This patch introduces a namespace declaration for the
MediaWiki\Content to JavaScriptContent and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I87c17327911e28a461feaf2ff46242454cff257a
This patch introduces a namespace declaration for the
MediaWiki\Json to FormatJson and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5e1311e4eb7a878a7db319b725ae262f40671c32
These methods are no longer needed by the Parsoid PageConfig API.
Depends-On: Ie3b8802153e380d25f9fc8a75469ec1c3a1b7015
Change-Id: I1bf9aad24b2bb04592d62e08923c79d8d46a977e
Modules group together endpoints by a shared prefix. The idea is that each module has its own version and can generated self-contained self-documentation. This allows clients to have clear expectations about the endpoints of each module, no matter what wiki they are accessing. So far, each wiki may be exposing a different set of endpoints, with no way to provide a spec that describes that set of endpoints in a way that would be consistent across wikis and stable over time.
Bug: T362480
Change-Id: Iebcde4645d472d27eee5a30adb6eee12cc7d046b
- fix type on the "rest-body-validation-error" message key, causing
the message to remain untranslated.
- fix error meta-data included when reporting body validation failures.
Bug: T358560
Change-Id: I56ef63e3534770c777cb5f938e3032101abae54b
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae