A crude solution for the acquireTarget() race condition. Use SQL
GET_LOCK() to lock the target from the acquireTarget() call until the
transaction is committed.
Add FOR UPDATE to the acquireTarget() SELECT, otherwise it just sees the
snapshot version of the row and inserts a new row anyway.
Add a test which reliably failed prior to the change.
Reword the ipb-block-not-found message. This is normal for simultaneous
blocks of the same target. Don't contact us. In the API, remap it to
"alreadyblocked".
Bug: T389028
Change-Id: I1fa35bf08d456a93930194786f77df389217ba61
(cherry picked from commit 2b65587e4d92e7f27661e8821b14f74ade939cfa)
Users should have 'reupload' or 'reupload-own' rights to do file revert.
Bug: T304474
Change-Id: I2d0eaeeea237286741708c2b5920fe7cca3acf50
(cherry picked from commit 7b4aee237e257954195c4d695b2cfe2a9a3b4116)
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
php documentation:
If the size of post data is greater than post_max_size, the $_POST and
$_FILES superglobals are empty.
When the action= and format= are not in the GET data,
the help page is returned in html, breaking the clients expected format.
Return api error with http status 413
Bug: T291754
Change-Id: I5906fb6b4412b161b198df0b51e2476e7e1079b8
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
