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 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
New hooks:
* AddNewAccountApiForm
* AddNewAccountApiResult
These hooks are used in ConfirmEdit here: Id628def
Sample API client: https://github.com/brion/api-createaccount
Bug: 46072
Change-Id: If5b7dab80ac85dbfa0f7a54a445356783df5e914
Add checks to token-returning functions to prevent returning tokens in
jsonp mode. This affects action=tokens, action=login,
action=createaccount, and action=query&list=deletedrevs.
Also, remove the "gettoken" parameter to action=block and
action=unblock, which has been deprecated since 1.20.
Bug: 49090
Change-Id: Ibeaa5c72d8084585092b15935a3f5709104bf7f7
Currently, WatchAction::doWatch and WatchAction::doUnwatch return true
always. Let's have them return a status object instead.
This also cleans up the handling of Status objects in some of the API
modules.
Change-Id: I9dd9f0fd499c37f29fa12bcdb6142238a1f11e4d
$wgLoginLanguageSelector is related to how the interface of
special:userlogin works. It doesn't make sense to listen to it
in the api module
Also throw error if invalid lang code is specified (for sanity)
Change-Id: Ibf72fd5a318cadc450b3b579757ee8145864a27a
Certain errors (user blocked, user doesn't have permission)
were causing uncaught exceptions to be thrown in this api module.
Try to check for those cases first. Also added some errors
to the possible error list.
Change-Id: Id86984ade23a818317b942de3e9cf0ccdb43fba7
If you made a request to action=createaccount and this was
the first time (so no account creation token had yet been
generated for you) a "nocookiesfornew" error was returned.
This is incorrect, what is supposed to happen in that
case is the api returns what token to use. This is
how users are supposed to request tokens, so the
issue is very confusing.
No release notes since this module was introduced in
this version.
Also removed sessionfailure from possible errors,
as it isn't one (that status triggers the needtoken
result).
Change-Id: Ibfc3879fa89b1e11303aef65feb45a91afc215e6
Improved documentation for the parameters for action=createaccount
and fixed the help link so it is valid.
Change-Id: I8123aed59077d2cb7446df43fefbb6632dc608d7
This happens when an anonymous user wants to create an account for himself through
the API. This is due to the fact that User::addNewUserLogEntry() was always using
$wgUser as performer, but the API does not replace $wgUser by the newly created user
object when the peformer is an anonymous user.
Changed User::addNewUserLogEntry() to directly take the log action as first parameter,
rather than a boolean value saying whether the password was sent by e-mail or not,
and force the performer to be the user itself in the log action is "create". This
avoids such problems in that case, no matter the value of $wgUser, and it makes this
parameter much more readable that the old one. Backward compatibility is maintained.
Creating an user and sending its password by e-mail will still log the performer's
IP address in the log if this is made by an anonymous user.
Finally the second parameter of the AddNewAccount is now correct when creating an
account from the API, it was always false previously.
Change-Id: I188ecf420b85e9d1dab6fb933ed50d5f58532109
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
Created new API action "createaccount" that
allows access to account creation. Takes
username, password, email, realname, token,
and optionally mailpassword and reason.
Errors are given in an errors array. Note
there is no way to natively handle CAPTCHAs
as there is no uniform implementation of
presenting CAPTCHA links to user. Right now
the best an extension can do is return an
error in AbortNewAccount, which will then
be displayed as an error in the Api result.
Change-Id: Ibdb1e50d434fb857683e1e4ff5a4a5a91c6b7c3a
