Because GlobalPreferences needs an API and that API needs to behave like
this one, it makes sense to make them share code. Move some functionality
into separate functions to make this possible.
Bug: T62856
Change-Id: Ic64934e7f7226a309d71c22626119ea233e2caeb
Specifically, check the assert and assertuser parameters before setting
up the action module, so errors in parsing the module's parameters due
to being logged out don't override the client's intended "am I logged
in?" check.
Note this means that assertion failures will no longer use custom module
output formatters. This seems like an acceptable tradeoff: on Wikimedia
sites in May 2018 there were no requests that would have been affected
by this change.
Bug: T197672
Change-Id: I02a71395d5ed9f445e57162f2136292825f8dbb5
This avoids documenting properties that may not be valid on the local
wiki, depending on which repos are actually available.
This patch also documents the other values available from repo types
available in MediaWiki core.
Bug: T197730
Change-Id: I6bf9fbf4ac29042d9f7524c6c1a5990051150cd3
Selectable sort orders were added to search some time ago, but never
appear to have been used. Expose them in ApiQuerySearch.
There is one large problem here, but it's not easily solvable.
Specifically supported sort orders vary per search engine, but the
available api parameters are calculated with the default search
engine. This is already a problem with search profiles so it's
nothing new, just continuing the existing problem. Much like
search profiles we hide the functionality when multiple engines
are available.
Bug: T195071
Change-Id: I187a530bc973c08386d2c2126e02a85b952d9022
Various code using the search engine shouldn't need to implement it's
own methods, such as over-fetching, to determine if there are more
results available. This should be knowledge internal to search that is
exposed by a boolean.
Change-Id: Ica094428700637dfdedb723b03f6aeadfe12b9f4
The funky iteration here was at best annoying. Switch
it over to an iterator based approach with appropriate
BC code to simulate the old iteration style.
Depends-On: I19a8d6621a130811871dec9335038797627d9448
Change-Id: I9fccda15dd58a0dc35771d3b5cd7a6e8b02514a0
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
This will be useful when an extension does something expensive and wants to
make sure users don't put too much pressure on the system.
Bug: T194950
Change-Id: I8a396d07c2d5764a680d0e5536cd1f99edbe141e
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
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
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
I searched the entire codebase for 'const' and looked for things
that looked suspiciously like manually calculated bitfield unions.
As of PHP 5.6, we can have them calculated automatically when
defining constants.
Change-Id: I7d971d1a63f8916db2f8f6c053c7dd0a13add92d
