The setting of $pageParams in that code path was assuming the page was
specified by title, breaking when it was passed a pageid.
Bug: T241362
Change-Id: Ia5b34ee392c94e5ae7693e95b58806c1dac2b24e
Until I70473280, integer literals were always quoted as strings, because
the databases we support all have no problem with casting
string-literals for comparisons and such.
But it turned out that gave MySQL/MariaDB's planner problems in some
queries, so we changed it to not quote actual PHP integers.
But then we run into the fact that PHP associative arrays don't preserve
the types of keys, it converts integer-like strings into actual
integers. And when those are passed to the DB unquoted for comparison
with a string-typed column, MySQL/MariaDB screws up the comparison while
PostgreSQL simply throws an error. Sigh.
So ensure the user names passed to the database are actually strings.
Bug: T240808
Change-Id: If2bca6ab9faa5b50516e47f06b0b26b3648e4cbf
The OpenSearch and prefixsearch APIs are always on for external use.
This internal parameter and feature flag was used as emergency switch
when the feature was still new, as a way to selectively ignore queries
from our own frontend code if we decided to turn the feature off.
At the time, there was also the $wgEnableMWSuggest configuration variable.
The idea being that if the JS is undeployed, it may still be cached in the
HTML and in some browsers. The $wgEnableOpenSearchSuggest variable allowed
the MW servers to identify those requests and return empty array without
any further DB load. Thus returning an empty array, which the frontend
at the time (mwsuggest.js) treated the same way visually as if the suggestion
feature didn't exist.
Since then:
* $wgEnableMWSuggest was removed in MediaWiki 1.20. The search suggestions
in Vector and other skins are now always on.
* The "Disable search suggestions" user preference was removed
in MediaWiki 1.23 (T54812).
Proposing to remove this additional complexity.
Change-Id: Iec572012de171d02871b8dc3207d2b34d17bf9ef
The 'editconflict' message is used by the normal edit form, and it
expects a parameter (page name), which was never passed.
'edit-conflict' should have been used instead.
This doesn't change the error code, which is mapped in ApiMessageTrait
and it already has a case for 'edit-conflict'/'editconflict'.
Change-Id: Ic95af27a67b95310b27ec344503d0a5cd88d79a2
Passing around strings that are expected to be safe html and are
known to be based on user input is a fairly unsafe operation. Make
it harder to do the wrong thing by requiring HtmlArmor to be returned
from the ResultSet snippets. This does not address the snippets on
individual result objects as the api surface is larger and requires
more bc handling.
Change-Id: I76231d6fc53c4982eb4cd174d2e6a75eb2740497
Now we can do this given we are using php7, this would also fix some
errors in php 7.4
Bug: T239761
Change-Id: I78254afd16ec88e3bf2ffa4890b92275bd794596
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
In several places, we're including rc_timestamp or other fields in a
query selecting on rc_this_oldid because there was historically no index
on the column.
The needed index was created by I0ccfd26d and deployed by T202167, so
let's remove the hacks.
Bug: T139012
Bug: T239772
Change-Id: Ic99760075bde6603c9f2ab3ee262f5a2878205c7
Repeating the variable name doesn't do anything. Documentation
generators don't need it. It's more stuff to read that doesn't add new
information. And it can become outdated.
Note there are two types of @var docs. When used inline (and not on a
class property) the variable name is needed.
Change-Id: If5a520405efacd8cefd90b878c999b842b91ac61
This updates some code that has been constructing TitleValue directly
to use TitleValue::tryNew or TitleParser::makeTitleValueSafe.
Bug: T200055
Change-Id: If781fe62213413c8fb847fd9e90f079e2f9ffc9d
Pass 'rcslot' as a param for the recent changes API to
only get changes (incl. reverts) for the specified slot
Bug: T230862
Change-Id: Iae53b1b22515116c61318ebe5ad3550c45554484
Using @see is not enough description
Enable the php sniffs for now, but skip /tests/ to fix it later.
That avoids new issues in future patch sets
Change-Id: I49cb341a2880bfaeefb6bbfbb1717051ea3a4b16
Currently apihelp doesn't mention that if you query information
about revisions, e.g a user that made a certain revision,
the response will be "userhidden". This commit includes that information
in modules API:Revisions, API:AllRevisions, API:DeletedRevisions,
API:RecentChanges, API:UserContribs, API:Watchlist, API:ImageInfo
and API:Compare.
Bug: T186573
Change-Id: I579f0d8c8183d5b158b9d3c9d6ae58e99984e58c
