When code was copy-pasted to create the module, apparently the messages
didn't get renamed correctly.
Change-Id: I1bab2ed5a2b014602b6c3dc1e53a4ce53f78fa6f
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
* Also make ErrorPageError exceptions display themselves
in PRESEND mode. Before they were always suppressed.
* Make DataUpdate::runUpdates() simply wrap
DeferredUpdates::execute().
* Remove unused installDBListener() method, which was
basically moved to Maintenance.
* Enable DBO_TRX for DeferredUpdates::execute() in CLI mode
* Also perform sub-DeferrableUpdate jobs right after their
parent for better transaction locality.
* Made rollbackMasterChangesAndLog() clear all master
transactions/rounds, even if there are no changes yet.
This keeps the state cleaner for continuing.
* For sanity, avoid calling acquirePageLock() in link updates
unless the transaction ticket is set. These locks are
already redundant and weaker in range than the locks the
Job classes that run them get. This helps guard against
DBTransactionError.
* Renamed $type to $stage to be more clear about the order.
Change-Id: I1e90b56cc80041d70fb9158ac4f027285ad0f2c9
This allows fetching info for all query submodules with modules=query+*,
and info for all modules recursively with modules=main|main+**.
Bug: T28680
Change-Id: Icca5d2fda39d9d43fe20d77e34779412cec77aad
* If the user specifically requests an empty list of namespaces, they
should get no pages.
* `ar_namespace` should always be in the query so MySQL can do a range
search instead of a full index scan.
* The example provided didn't match its description.
Bug: T89665
Change-Id: I91afc25db488f75c7f2b1ef343766b4bd7da5472
This avoids master queries on HTTP GET. Filter out rows on the
fly and allow for pruning to only happen when blocks do.
Change-Id: Idd25b2f8a789ba191fde87e997910e78d67c7021
If a client submits data that is not NFC-normalized Unicode or that
contains C0 controls other than HT, LF, and CR, it gets normalized before
the API ever sees it. Which can lead to difficult-to-handle bugs when,
for example, a title is subject to normalization so the client can't
find the specific title it submitted anywhere in the response (T139130).
This patch does two things:
* Detects when normalization was applied to an input value (at the
MediaWiki level, anyway; if PHP or earlier does it we're just out of
luck) and add a warning to that effect.
* For ApiPageSet's 'titles' parameter, split into the individual titles
and add them to the 'normalized' list in the response. This requires
encoding the pre-normalized strings to avoid ApiResult's own
normalization.
Bug: T29849
Bug: T144071
Change-Id: I215fd3edd7a5e1b45292e60768bf6dd5ad7f34de
When a multi-valued parameter's value begins with U+001F, the values
will be split on that character instead of pipes. This will be useful
for things such as action=options&change= or meta=allmessages&amargs=.
Since MediaWiki doesn't otherwise accept C0 control characters
(WebRequest::getVal() replaces them with �), there's no possibility that
this will conflict with a literal use of U+001F.
Special:ApiSandbox and mw.Api are updated to make use of this, with the
latter having an option to disable the behavior in case something is
depending on [ 'foo', 'bar|baz' ] turning into 'foo|bar|baz'.
Pipe is still used as the separator when the value doesn't begin with
U+001F, and will be forever since it's generally more human-friendly and
is needed for backwards compatibility with basically every API client in
existence. The requirement that the value begin with U+001F, rather than
simply contain U+001F, is to avoid clients having to somehow
special-case "param=foo|bar" where that's intended to be a single value
"foo|bar" rather than two values "foo" and "bar".
Bug: T141960
Change-Id: I45f69997667b48887a2b67e93906364a652ace5a
* Set an indexed tag name in ApiParamInfo and ApiAuthManagerHelper.
* Use 'key' instead of 'message' for the (not yet used) non-BC
ApiErrorFormatter.
Change-Id: I07f0a690e263b34e09210673241af8bf750cbd1b
Currently the API just throws away the excess values, no continuation.
This is probably not the best behavior. There is a warning, but clients
are notorious for just ignoring warnings.
We could improve the situation:
* Turn it into an error.
* Turn it into an error for most cases, but allow some to override if
necessary.
* Allow some cases to make it an error, while keeping it a warning by
default.
Before we can decide which option to pick, we should get an idea of how
often this is being hit and which things it's being hit for.
Bug: T41936
Change-Id: I52926f410c30d1cd7e7fcd86465b16519fb5cbd2
Prevents leaking page contents for extensions that deny read rights
to certain pages via a userCan hook, but still allow the user to
have read rights in general.
Issue originally reported by Tobias
Bug: T115333
Change-Id: I19f5c2583393794cff802a70af7ccf43c2fed85c
If $extraData was null, but $moreExtraData was given, the following
fatal would occur:
Fatal error: Unsupported operand types in
/var/www/html/w/includes/api/ApiUpload.php on line 408
Follow-up to c9b5b3e988.
Change-Id: I613eed1f7429247fe46afa454d36f518f6a81ebe
Instead, go back to validating the individual values so one invalid name
doesn't cause the whole module to error out. The code for that was all
still there, just unused since Ic67fb540.
Bug: T142895
Change-Id: Ia5eae51d69185580ac2c772afc198a92813e407a
