PHP doesn't care much but I think we humans do because we should
call methods by the name we give them. Method fixed are;
- isOk() -> isOK()
- setOk() -> setOK()
- teardown() -> tearDown()
Change-Id: I6b3f0cf3902887058efa426968da380803869e0b
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
Fixes unintended breaking change made by I84ed21641c44b2f65ebe.
ApiQueryUserInfo::getBlockInfo() is restoed as a hard deprecated stub.
This renames the method in the new ApiBlockInfoTrait to
getBlockDetails.
Depends-On: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
Change-Id: If47a93878f87d69800e5f305404c22528dac5e94
ApiBase directly uses this method causing a cyclic dependency between
ApiBase and ApiQueryUserInfo
Change-Id: I84ed21641c44b2f65ebe1980b0893d1846db3b34
Two bugs here:
* If the error array contains an entry using a Message object instead of
a string as the key, it'll blow up trying to do
`self::$blockMsgMap[$error[0]]`.
* If the error array contains a Message object not wrapped in an array,
it'll blow up trying to do `...(array)$error`.
Bug: T217382
Change-Id: I2a08e02bca0fb194416b3f2e6a1d6192d5c13cb2
When using ApiBase::errorArrayToStatus(), block info was added to
'blocked' errors. But when using dieStatus() with a Status object
returned by core MediaWiki code, block info was not being added.
Change-Id: I14887b6dd76d665055283945b956b2e26c521ed5
Depends-On: Ie3addf53ab5fabf1c24e1033b58e63927f4e21bf
If a deprecated parameter has a default value, or a deprecated value is
part of the default value for a parameter, don't give the client a
deprecation warning about it.
Bug: T215548
Change-Id: I980763e3d44fb1b7459c64b175fcaddf5fd44a13
So we can make the job voting, preventing other tests from regressing.
These tests can be re-enabled whenever they're made to pass.
Bug: T195807
Change-Id: I58261dd70eea3581803987a4a7739c7d55558f42
Some unit tests for the MCR schema migration change the DB schema
in the test setup. However, addCoreDBData() will not work with the
modified schema. Since these tests don't actually need addCoreDBData()
to do anything, they can simply override it to do nothing.
Without this change, tests for Ic2221da30c and Ifabf39e12ba843
fail with $wgMultiContentRevisionSchemaMigrationStage = MIGRATION_WRITE_BOTH.
Change-Id: I86e140ec981dfa4e904822b1600399c533f9e3d6
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Since 2008 the API has truncated with a warning when too many values are
passed to a multi-valued parameter. It's long past time to make this an
error.
Bug: T41936
Change-Id: I0f9efbdf9230373fa0c175a7fcacbca68225cf40
This is a bit more interoperable than trying to roll our own by using
Title::makeTitleSafe().
We still need to handle IP addresses separately, of course.
Bug: T194916
Change-Id: Ie3900d768cbe15aef079b97d91f7fd23dc7c3e26
With MCR coming up, ApiEditPage is going to need to be able to take
"text" and "contentmodel" parameters for each slot-role, and enumerating
such parameters for every possible slot would probably get rather
confusing as to what is required when, or at least long-winded in
repeating the exact same thing for every possible role.
So let's abstract it: we'll have an "editroles" parameter to specify which
slots are being edited, and ApiEditPage will just declare that
"text-{role}" and "contentmodel-{role}" parameters should exist for each
value of "editroles" in the submission.
Note this patch doesn't introduce anything that uses templated
parameters, just the functionality itself. For testing purposes you
might cherry pick I2d658e9a.
Bug: T174032
Change-Id: Ia19a1617b73067bfb1f0f16ccc57d471778b7361
Follows-up d3da5e08d3, which broke PHP 7.1 and PHP 7.2 test jobs.
This isn't about logic in ApiBase, but about PHP's str-to-int
logic which actually varies between PHP5 and PHP7.
One maps it to 1000, the other as strict int 1 (with non-numerical
text chopped off, the same as it would for 1foo).
If we want to support 1e3 as part of the API itself, then we'd
need to parse it ourselves and then add the test back.
Bug: T192425
Change-Id: I6fc43f29425749a1abe785fefa312db6a98ea7cd
One bug fixed: a timestamp of '00' or similar would get interpreted as
'now' by mistake instead of Unix timestamp 0, without throwing the
warning for using 0 instead of 'now'. This is because it called
wfTimestamp() once to parse the input date, got a Unix timestamp of 0
back, and then tried passing that 0 back to wfTimestamp again to
reformat as a wiki date, but it got reinterpreted as 'now'.
Also fixed parameters with type "user" to validate usernames more
correctly. This might be risky, though, if I missed any valid
usernames, or if API clients were for some reason relying on passing in
invalid usernames. If we don't actually want to do this, we should add
a comment explaining why we're allowing any title without a fragment
rather than validating properly.
Still lots more work to do here.
Change-Id: I56b4290263df8698efdbddda71a7eabd9e303abc
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
Blocks made for configured proxies, dnsbls, or the configured range
soft-blocks being added in I6c11a6b9 aren't real blocks stored in the
database. Let's actually flag these blocks as such and use a more
appropriate message when displaying them to the user.
Change-Id: I697e3eec2520792e98c193200c2b1c28c35bf382
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
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
