When no PARAM_HELP_MSG is set, the code builds a dynamic message key in
ApiBase::getFinalParamDescription, check the possible message as well
To make core tests pass in ApiFeedWatchlist the PARAM_HELP_MSG must be
always set
Depends-On: Iedb4f9d9f53a06d0ff8c11309de6c546182f752e
Depends-On: If490db5eef5db8fef349cd287232a409ae2dc85f
Depends-On: Ief80d8524472051fc03aec75047fc7a2127aab26
Depends-On: I74d2575de9765d69d967a0760a10b735eb811eca
Depends-On: Ib18c90b71d586750beb80171cc8109322e87bd92
Depends-On: Ia6e63188e3776476d401c8c2f266a370aa35a3bf
Depends-On: Iffed1a77f9267d382abaeffe533e577fca6a2844
Depends-On: I0f548b47121e07dd4199428d015df3da85166843
Change-Id: Id1a42b4a7742b96bdc9a55703a225d23c04d2991
TestUser creates the user and therefore needs the database. Avoid using
it in non-database tests.
Add ApiQueryBlockInfoTraitTest to the Database group because it needs
the database.
Add DeleteUserEmailTest to the Database group because since 3bedffa8
the default user is not created any more in non-database tests
Change-Id: Iff438964dde47a47a2fa4a314d55010bd8c7fee5
Initally used a new sniff with autofix (T333745),
but some provide are defined non-static in TestBase class
and need more work to make them static in a compatible way
Bug: T332865
Change-Id: I889d33424f0c01fb26f2d86f8d4fc3de3e568843
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
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 mandatory Unicode NFC normalization on API parameters was causing
spurious dirty diffs in VisualEditor/DiscussionTools when editors used
HTML entities to encode non-NFC codepoints, like  . Although
wikitext is (ought to be!) in NFC form, the output HTML may not be,
due to explicit entities in the wikitext.
This type is used in VisualEditor change
I0d34c9a01f1132c2616ed3392ea40d8b73e15325 to prevent Parsoid HTML from
being corrupted when it is round-tripped.
Bug: T266140
Change-Id: I2e78e660ba1867744e34eda7d00ea527ec016b71
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
Introduces $wgWatchlistExpiryMaxDuration which is used instead of given
expiry if the given exceeds it. This is done in the storage layer. The
reasoning is to control the size of the watchlist_expiry table. Hence,
the max duration does not apply to indefinite expiries (since that would
mean now row in watchlist_expiry).
The frontend is responsible for disallowing expiries greater than the
max, if it choses to do so.
APIs should now pass in $wgWatchlistExpiryMaxDuration as the PARAM_MAX
setting for the 'expiry' type. They should also set PARAM_USE_MAX so
that the maximum value is used if it is exceeded.
Other APIs that watch pages will be updated in separate patches
(see T248512 and T248514).
Bug: T249672
Change-Id: I811c444c36c1da1470f2d6e185404b6121a263eb
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
ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
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
