Idfe23a07d didn't go far enough with this method, it can be passed
arbitrary other scalars in addition to null and arrays.
Bug: T182377
Change-Id: I63ec23f70d6d7ad638aa382b740ec44d0ca47f85
PHP 7.2 broke existing functionality in making count( null ) raise a
warning. So add tests for null all over the place, or change tests where
we know the value is null or an array (but not false, empty-string, or
0) to just cast to boolean.
Bug: T182004
Change-Id: Idfe23a07daa9f60eee72f2daf04304be87057a29
These particular functions build up data to be passed into the database
abstraction, which accepts not only strings but arrays. Where conditions
generate `field IN ('a', 'b', 'c')` clauses. The options can be used
with, for example, sort to sort by one field and then a second.
Change-Id: I743f14f0e56c7f0546dfecd130925e15d63c7d64
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
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
This will allow extensions to inject into the query to implement
"xxshow" parameters, and to add additional properties to the output
data for "xxprop" parameters.
Also, call these new hooks from ApiQueryRevisions, ApiQueryAllRevisions,
ApiQueryUserContributions, and ApiQueryRecentChanges since I701e8e19 is
going to be wanting them.
Bug: T143614
Bug: T143616
Change-Id: Id6b42c7f2eb53a6f659d0d61383287f41d96ca00
This should have been marked as deprecated in 1.25 when
ApiBase::getParamDescription was deprecated, since that's its only use,
but it was overlooked at the time.
Change-Id: Ifd67c3e11188adebd3b6218df79a9dde967c4e17
Naming is "fromtitle" rather than just "from" because "from" parameters
in API query modules generally mean a title without namespace, and this
should make use of the client-supplied namespace.
Bug: T98985
Change-Id: I8370f47f6eed71ea97a44a66eb6be2a8f89fea53
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
The profileIn/profileOut pair should be covered by the Xhprof profiling
of the method calls it was wrapping.
The profileDBIn/profileDBOut pair are covered by profiling done by the
Database class.
Nothing in extensions in Gerrit is calling anything besides the
profileIn/profileOut pair (and likely those are only to avoid core
formerly throwing exceptions from internal profileDBIn/profileDBOut
calls), and nothing in core or extensions-in-Gerrit is using the methods
for fetching profiling data.
The methods are left as stubs for now to allow for backwards
compatibility in extensions.
Change-Id: I05ba4e2762dc86d5e2bafc183dce701239b43f5c
As-is, this causes loss of a character from the passed-in title leading
to wrong output. But there should never be a '#' in a title-part anyway,
the best thing is to just disallow it completely.
Bug: T38358
Change-Id: Id90bfb9c63a5960e7d2d49350d3e0da0327d0e24
The simplified continuation includes a continuation parameter to
indicate when the prop/list/meta modules are complete, so it can skip
executing them.
But if someone submitted a malformed value for 'continue', it might
decide that the generator was complete but still try to uselessly
execute the prop modules.
Bug: 72764
Change-Id: I6af24e5d4f30e64782fb7dd1c2211ebdd4ec2317
The existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
This change affects list=allusers, list=users
and meta=userinfo.
Note: This change also add block expiry to meta=userinfo.
Unlike this field in other modules, it formats the timestamp
properly, instead of just dumping db contents.
Resurrecting from abandoned change Ifdeac5c5f547
Bug: 63326
Change-Id: I4b3e55fe2d07271e1ded89d36d0b98de0e643177
* Group methods in ApiBase by function
* ApiBase::validateLimit and ApiBase::validateTimestamp are now
protected; there are no callers in any extensions in Gerrit
* Group methods in ApiQueryBase by function
* Move ApiFormatFeedWrapper out of ApiFormatBase.php
* Deprecate some methods in ApiQueryBase that seem useless and are
unused in core or any extensions in Gerrit
Change-Id: I32092f13906b6826d2137401724c21ccefa6f670
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
In this change, a new passive user right named "viewsuppressed"
which can be used in order to view suppressed page content was added
to MediaWiki core.
Furthermore, this right was also added to the list of available rights,
to qqq.json and to en.json where also the description of the
"suppressrevision" right was adjusted in order to reflect reality.
Bug: 20476
Change-Id: Id1baacb9c782763db5e05ef8b5c1b761997efcc9
While generator support was added to various actions, the continuation
parameters from the generators weren't being returned to the client.
This patch refactors the code for handling continuation out of ApiQuery
and into ApiResult, and then uses it in the other actions that need it.
Bug: 60734
Change-Id: I1a6e51cdc964ddcdd69aaa2f735223371233e8af
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
* ApiQueryDeletedrevs, ApiQueryFilearchive, ApiQueryRecentChanges, and
ApiQueryWatchlist will now return entires where fields have been
revision-deleted. "Hidden" indicators will be provided as appropriate.
* ApiQueryImageInfo, ApiQueryLogEvents, ApiQueryRevisions,
ApiQueryContributions will now return field values in addition to the
"hidden" indicators when the requesting user has the necessary rights.
* Modules that return "hidden" indicators will now also return a
"suppressed" indicator.
* ApiQueryImageInfo will now return info for DELETED_FILE file revisions
if the requesting user has the 'deletedtext' right.
* ApiQueryLogEvents, when searching by user or title, will now return
entries where the user or action are revision-deleted if the
requesting user has the 'deletedhistory' right.
* ApiQueryContributions now uses the correct user rights rather than
'hideuser' to determine when to show contributions where the username
was revision-deleted.
* ApiQueryContributions will now indicate when the revision text is
hidden.
* Fix a bug in ApiQueryDeletedrevs found during testing where specifying
the "content" prop along with the "tags" prop or "drtag" parameter
would cause an SQL error.
* Fix various PHP warnings in ApiQueryFilearchive caused by the lack of
ArchivedFile::selectFields() fields.
* ApiQueryImageInfo::getInfo's $metadataOpts parameter has been renamed
$opts, and now may have an option to indicate the user to use for
RevDel visibility checks.
* ApiQueryWatchlist now properly uses the actual user's rights for
checking whether wlprop=patrol is allowed, rather than using the
wlowner's rights.
Bug: 27747
Bug: 27748
Bug: 28261
Bug: 34926
Bug: 48966
Change-Id: Idec2199976f460e1c73a26d0717e9fc4ab8042bb
ApiQueryBase::titlePartToKey now allows an extra parameter that
indicates the namespace in order to properly capitalize the title part.
This allows list=allcategories, list=allimages, list=alllinks,
list=allpages, list=deletedrevs and list=filearchive to
handle case-sensitivity properly for all parameters.
Bug: 25702
Change-Id: Iaa5a71ec536f3716f54bc84b39f645545dfd8660
When a user with the hideuser permission is using list=[all]users, a
- Notice: Undefined property: stdClass::$ipb_deleted in
\includes\api\ApiQueryUsers.php on line 172
- Notice: Undefined property: stdClass::$ipb_deleted in
\includes\api\ApiQueryAllUsers.php on line 238
can be raised, because the join on the ipblocks table was not done for
the user.
Change-Id: I25ead34b7905e99c249cb05c9d4940195c8b6263
