meta=siteinfo gets a list of all configured central ID lookup providers
and which one is being used as the default, while meta=userinfo,
list=users, and list=allusers get the ability to return the IDs and
attachment status.
Change-Id: Iea15b6c22baac79b3f8ca6df0e20a6a4299507d2
Use message-per-value for message
apihelp-query+allusers-param-prop to allow smaller strings
for translation.
Each prop in a message also will show up a new parameter on the help
page without the adjust of the translation (but than in english instead
of fully skip it).
Change-Id: I695277f579f2b8f13c3b4743e49a890bb641a269
strtr() is marginally faster as it runs through the string only
once. A better fit for one-for-one character translation.
The strtr() function also supports an associative array as second
parameter for entire string replacements. This, too, has the same
performance and predictable behaviour (starts with the longest key).
Whereas str_replace is for more aggressive needs where you want
multiple passes until there are no further matches.
The associative array form is arguably also easier to understand
and harder to mess up since the needle/replacement pairs are
explicitly connected instead of two separate arrays.
Also:
* Use getFormattedNsText instead of strtr( getNsText, .. ) which
reduces duplication of this fact through a more semantic intent.
Change-Id: Ie23e4210a5b6908dd79eebc8a2b931d12fe31af6
Did this for ApiQueryUsers and ApiQueryUserInfo in I35007089, but missed
the corresponding code here.
Change-Id: I3786ab4a10b96600037816dd88580870d155a2fe
Mysqli is returning SELECTed ints as strings rather than as ints, I'm
guessing to avoid problems with 64-bit int types on 32-bit systems. PHP
mostly doesn't care, but it causes API JSON output to have strings
instead of ints all over the place.
This also fixes ForeignAPIFile::getUser( 'id' ) returning the user
*name*.
Bug: T98276
Change-Id: Ie6591d72b3ac40172f8176a8ca8b6fad8e9275a5
* This avoids writes on view and is more reliable
* Also made the wfWaitForSlaves() there actually work
Bug: T95501
Bug: T92357
Bug: T89027
Change-Id: I0a006fc92a9268feb185c9d88aa04002ea51ecd3
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
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
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The existing query only works with a single value for augroup, or mostly
if it's combined with auprop=groups or auprop=rights (since most users
don't have every possible group).
When used with multiple values for augroup, it will raise an error if it
happens to encounter enough users who have more than one of the
specified groups. And further, it will lead to repeated groups for these
users if combined with auprop=groups or auprop=rights.
An attempt to use EXISTS instead of a JOIN to query user_groups failed
because it made the planner scan the user table where a smaller scan of
user_groups plus a filesort was faster. So instead, let's just fix it
directly by acknowledging that supplying multiple groups for
augroup is going to give us duplicate rows.
At the same time, let's try using a subquery (with GROUP_CONCAT) to
fetch the actual groups the user belongs to, both to avoid processing so
many duplicate rows and to simplify the row-processing code. And let's
kill the forced index, it's probably not needed anymore.
Bug: 70496
Change-Id: Ic87dbc3b2d933775ca71a72932e0658e2f082bb6
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
The existing query only works with a single value for augroup, or mostly
if it's combined with auprop=groups or auprop=rights (since most users
don't have every possible group).
When used with multiple values for augroup, it will raise an error if it
happens to encounter enough users who have more than one of the
specified groups. And further, it will lead to repeated groups for these
users if combined with auprop=groups or auprop=rights.
To avoid both these issues, let's use EXISTS instead of a JOIN to test
augroup. While auexcludegroup doesn't have this problem, we may as well
make the same change there, too. And doing that, there's no reason to
continue with an error when both augroup and auexcludegroup are used.
Bug: 70496
Change-Id: Ia7086ce87012c22651ac4c7a3f75558347276226
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
The query introduced to support the auactiveusers is itself broken (it
counts every edit multiple times when combined with the group filters or
auprop=groups or auprop=rights, or for users with multiple rows in
ipblocks) and it breaks auprop=groups and auprop=rights.
Instead, let's filter using the same cached data used by
Special:ActiveUsers and do the actual counting of recent "edits" in a
subquery. And for parity with Special:ActiveUsers, let's skip
RC_EXTERNAL when doing the count.
Also, it turns out the "recenteditcount" property in the result is
really more like "recentactions" since it counts any action that shows
up in recentchanges; the discrepancy between that and "editcount" can be
confusing if someone is doing a lot of logged actions that don't create
dummy revisions. Let's rename that, but we'll have to keep the old
property around for a while for BC.
Bug: 64505
Bug: 64507
Bug: 67301
Change-Id: I461e92819188c311cbb3853bc6bfad45962c8d7b
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
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
Filter for an unused right gives an empty group array, which
is not added to the query and than all users (with limit) are
selected.
Change-Id: I57c3c4d2b49653d71391b0d7755fdc0ad1d3a7d0
This introduce the syntax from aliased table names for aliased field
names into the abstract database layer:
array( 'alias' => 'field' ) gives 'field AS alias'
This patch also includes changes to query pages, api and some more
places to show, how the new syntax looks in "production".
This allow us to remove the "AS" for Non-PostgreSQL databases, if we
want that.
Change-Id: I5f0de1c2f29092c173aec3de93ffdef436799e8d
No need to duplicate the code of User::getAutomaticGroups() in
ApiQueryUsers::getAutoGroups(), instead just call that method
directly.
Also deprecated the latter in favour of the former and replaced
all calls in core.
Change-Id: I224cb610cbd6a927a4c7f7137951416368f8cb5d
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
Listings with aurights can't show users with rights which are
granted by implicit or auto-promoted groups like *, user, or autoconfirmed.
This is my first commit, btw.
Change-Id: I083eb977393729961317d0f3cf9f7cfaa50fde51
Add some calls to Database::timestamp
Change some calls from Database::strencode to
Database::addQuotes to avoid ' in raw sql
Remove ' from ints in raw sql
Rename some vars to avoid duplicate names
Change-Id: I63f5602fa968f969a42932902a3ccc45fc54b432
Follow up to: I7d115e734cb8c93dcf6dc3b98bdbc81975951273.
I have replaced $this->keyToTitle calls with simple str_replace.
As a result invalid user names will be accepted in parameters, so
the chain of requests based on query-continue will not be broken
by invalid entry in the database.
Change-Id: I8a80fe6395ae6e9304e4d9ec7b604195ec3c9d00
Some MediaWiki installations have invalid user names in user table
(most notable example: en.wikipedia). This commit DOES NOT resolve
the issue completely, it only makes the API behave more gracefully.
I have replaced User::newFromName call with User::newFromId, so the
User object should be always constructed. In case it was not, an
empty array will be provided instead of null when returning user
rights. I have removed keyToTitle calls for ContinueEnumParameter
as user names in the database are stored without underscores
(en.wikipedia has of course one user with _ in the database...).
This should fix invalidtitle error thrown.
There is one issue I don't know how to solve. When API outputs in
query-continue aufrom value with invalid user name, subsequent
call with aufrom set will return an error, because input parameters
'from' and 'to' are passed to keyToTitle method too. Should I
replace it with simple str_replace('_', ' ')?
Change-Id: I7d115e734cb8c93dcf6dc3b98bdbc81975951273
