Various tools want to display the full HTML error messages
when &errorformat=html&errorsuselocal=1 is specified.
Depends-On: I06c89534be605557ee9b0d90d2748f806fa2ae9e
Depends-On: I353e34d81afaa06750f8725181c808fabcebea42
Depends-On: Ib60ac795e9dda124b927816321aafe0853ee4500
Bug: T335319
Change-Id: Ie17987991d1e9a0d77da97e3a81fe0a21c6d7866
Error messages are not guaranteed to be stable, and these tests
prevent us from improving them.
Error codes are supposed to be stable, so we should be asserting
that they do not change (especially since many of them are
dynamically generated by the dodgy code in ApiMessageTrait).
Introduce helpers assertApiErrorCode() and expectApiErrorCode()
to be used instead of the usual PHPUnit assertions/expectations
for this case.
Change-Id: I752f82f29bf5f9405ea117ebf9e5cf70335464ad
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
Allow the use of PARAM_HELP_MSG_PER_VALUE for PARAM_TYPE='string'
and PARAM_ISMULTI=true, which is the setting used for templated
parameters (PARAM_TEMPLATE_VARS).
It's common for templated parameters to take the variable parts
of the name from some fixed set, but they are required to use
PARAM_TYPE=string so it makes sense to allow the use of multi-
valued parameter documentation for that case.
The other option would have been to allow templated parameters
to be enums, which also makes sense and could be a complimentary
improvement; there are two reasons to prefer the current approach:
* Getting the list of allowed values might have a performance
impact that we only want to incur when the (optional) parameter
is used, while an enum requires the value list to be generated
every time the API module is used. So there would be some
value in using string type for templated parameters with a
known set of documentable values even if enum were also allowed.
* Per-value documentation might be useful outside the template
use case for non-restricted multi-valued strings: maybe all
values are allowed but there are some values with special
meanings that are worth documenting.
Change-Id: I53f9ae840c0a7eee76c4b57f95390b5045707efd
And also assertNotRegExp -> assertDoesNotMatchRegularExpression. The
methods were renamed in PHPUnit 9.
Done automatically with:
grep -rl assertRegExp tests/ | xargs sed -r -i "s/>assertRegExp\(/>assertMatchesRegularExpression\(/"
grep -rl assertNotRegExp tests/ | xargs sed -r -i "s/>assertNotRegExp\(/>assertDoesNotMatchRegularExpression\(/"
Split out from Ifdba0f9e98eb6bce4590b7eb73170c51a697d7c6 so that it
remains smaller and easier to review.
Also make a test use MediaWikiUnitTestCase (it's already in the unit/
dir) so that it can access the forward-compat method.
Bug: T243600
Change-Id: Ifa279d5f201d7abeebece292141ebface8278046
It seems some tests are fixed in the meantime without removing the
skipped part for this.
Bug: T195807
Follow-Up: I58261dd70eea3581803987a4a7739c7d55558f42
Change-Id: Ie883b7056cdd0cb6bec81c2f7e4ed54177b4ecb2
Providing just standard timestamps means that formatting
has to happen in the client, however that means loading a
large deprecated library (moment.js). We already have
localised formatting functions in PHP so just provide
the output of those in the API.
Also fix test mocks to correctly provide a language object
rather than a string.
Bug: T224635
Change-Id: I73dcfcdbbc6e90bc692bf5a456075fe1eaed2df9
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
The limit tests would fail if there is apihighlimits for everyone
(group *)
mergeMwGlobalArrayValue does not do deep merge, it just overrides;
setting the '*' group to the minimum required to pass tests.
Change-Id: I95fba69af1845f28132370e9ded3350acdfdb8c4
Following 23c3c70d7f, soft deprecate the static methods on
DatabaseBlock that have been moved to DatabaseBlockStore:
* ::insert
* ::delete
* ::update
* ::purgeExpired
Update calls to the deprecated methods from core.
Change-Id: I1272eb978594fd4f386bda12cbc24131ad7d882f
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
This commit also changes ApiWatch to make use of the new parameter type.
Other APIs will be updated to use it in a separate patch (T248196).
In doing this, we are for the first using logic within a TypeDef outside
the API. This seems acceptable given TypeDefs chiefly appear to serve as
a validation method, with otherwise no particular logic tied to the
concept of APIs.
wfIsInfinity() now uses ExpiryDef::INFINITY_VALS
Bug: T248508
Change-Id: If8f0df059eafb73ec9f39cc076b3a9ce2412d60a
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
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
