Why:
- The REST API takes an optional renderid param when converting HTML
back to source wikitext, which is user-provided and may be invalid.
- Invalid render IDs cause an InvalidArgumentException to be thrown that
causes a 500 response.
What:
- Introduce a new error message for invalid render IDs in the REST API.
- Return a 400 with this new error message for HTML reverse-parses with
an invalid render ID.
Bug: T385568
Change-Id: I062419fe8952329a39781a49cdca2e94c3996447
(cherry picked from commit cd1d42a5066e4bcb9b9d4ed9b4f7714fd428fea3)
A previous change made it possible to include response schemas in
generated OpenAPI specs. However, it did not provide the http method
to the code that generates/includes these schemas. Because some
handlers support multiple http methods, this is necessary. So add it.
Bug: T375530
Change-Id: Ie681d576cdffc387d78a1686e058903761b749ac
(cherry picked from commit 576b29092d5fd6a8480e02ddc2141b69cf698936)
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead.
Followup to e662614f, using PHPStan.
Bug: T376276
Change-Id: I60d639b042b537bf2f531cc132f1b75a66b85acb
(cherry picked from commit da0a395efa7847916371f9c0a6b271faa022ff59)
HtmlInputTransformHelper::setMetrics() and
HtmlToContentTransform::setMetrics() take a StatsFactory now; deprecate
passing a StatsdDataFactoryInterface.
Depends-On: I0d8eb6cacd761fa4959419b10d59046e61c714ff
Change-Id: I2374731f6d37a191fc4a865d2665f2ca18182db1
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Previously, response body schemas could be specified by handlers as
php associative arrays, that were included in the final OpenApi spec.
This mixed the schemas with code, and required developers to deal with
specs in multiple formats. Instead, allow specs to be specified in
JSON format, in separate files. In addition to keeping schemas in JSON,
this gives each schame its own git history.
Bug: T376290
Change-Id: Ic27f422df0ab12a3a0b1cbce79eb0be30f7b7815
HtmlOutputRendererHelper sets ParserOptions::setTargetLanguage(),
but this isn't actually included in ParserOptions::$cacheVaryingOptionsHash
so even though this setting changes the ParserOutput it wasn't
being included in the cache key.
Bug: T376783
Change-Id: Ie76020dc4fa3545f827e1674051530b479f01f31
A constant is not a variable. The type is hard-coded via the value
and can never change. While the extra @var probably doesn't hurt much,
it's redundant and error-prone and can't provide any additional
information.
Change-Id: Iee1f36a1905d9b9c6b26d0684b7848571f0c1733
Previously, parameter descriptions could only be specified as
strings. We want OpenAPI specs generated from parameter
definitions to be internationalizable, so allow specifying
descriptions as MessageValue objects, which can be translated
using normal MediaWiki mechanisms.
Associated improvements to ResponseFactory.
Bug: T376493
Change-Id: If1cbe4f7bfd5c375e64b802b666c0247d65b1ee0
The discovery endpoint provides basic information about accessing the
wiki's APIs, as well as a directory of available modules.
Bug: T365753
Change-Id: I161aa68566da91867b650e13c8aadc87cd0c428c
In order to replace certain /api/rest_v1 endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The MediaWiki REST API error format does not match
RESTbase. So the easiest approach seemed to be to
add a compatibility mode, triggered using the x-restbase-compat
header. This can be set via the gateway when rerouting the request.
Bug: T374136
Change-Id: I73934940d367be52941bd27861c248ab5bcfb5d2
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
This touches various production classes and maintenance scripts.
The code should do the exact same as before. The main benefit is that
the syntax avoids any repetition.
Change-Id: I5c552125469f4d7fb5b0fe494d198951b05eb35f
The generated OpenAPI spec should contain information from the info
section of module spec files.
Bug: T366834
Change-Id: I488f550adbf32205bdcdcb59b1e7f5273643bf69
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
This demonstrates how to use ArrayDef::makeObjectSchema to define a
schema for a complex body field.
The "latest" field in the request body for page PUT requests identifies
the base revision. To allow the base revision info to be looped through
from an earlier GET request, it's nice to allow the "timestamp" field
to be present, even though we don't use it.
I changed the relevant part of Update.js to test that use case specifically.
Bug: T368131
Change-Id: I166396e0dbfc995e5346252ee438c9afe2c808e2
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
