When saving an edit is prevented by the AbuseFilter or SpamBlacklist
extensions, the error is currently reported as a successful API response
with a 'failure' code in the body.[1][2]
In the future, these will be reported as standard API errors.[3][4]
This change should be deployed to Wikimedia wikis with 1.34.0-wmf.23. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule.
Clients that do not need to specially handle failures due to AbuseFilter or
SpamBlacklist will likely need no changes, as they probably already include
code to generically handle API error responses.
Clients that do handle AbuseFilter or SpamBlacklist failures specially will
need to be updated to check for error codes 'abusefilter-warning',
'abusefilter-disallowed', and/or 'spamblacklist' and handle them as they do
the current AbuseFilter and SpamBlacklist failures, if they want to
preserve their current special handling.
Note that edit failures due to CAPTCHAs from ConfirmEdit are not being
changed at this time. They will continue to be reported as before.[5]
[1]: AbuseFilter: https://phabricator.wikimedia.org/P8988
[2]: SpamBlacklist: https://phabricator.wikimedia.org/P8990
[3]: AbuseFilter: https://phabricator.wikimedia.org/P8989
[4]: SpamBlacklist: https://phabricator.wikimedia.org/P8991
[5]: ConfirmEdit: https://phabricator.wikimedia.org/P9076
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
According to RFC 7231 § 3.1.1.5,[1] a POST request that does not include a
Content-Type header may be interpreted by the server in one of two ways:
1. It may assume application/octet-stream. In this case, PHP and the
Action API will not see the request as having any parameters, and so
will probably serve the auto-generated help page.[2]
2. It may "sniff" the content type. It's likely enough to correctly
guess application/x-www-form-urlencoded in this case, and therefore PHP and
the Action API will see the request as having the intended parameters.
It turns out that HHVM and PHP 7 (at least as used at Wikimedia) differ in
their behaviors: PHP 7 seems to choose option 1, while HHVM chooses option
2.
Thus, clients that have been generating POST requests to Wikimedia wikis'
Action APIs without a Content-Type header will have been receiving expected
results from HHVM but will now start receiving unexpected results as
Wikimedia's migration to PHP 7 proceeds.[3] Affected clients should be
updated to include the Content-Type header in their requests.
See https://phabricator.wikimedia.org/T230526 for some details on this
issue.
[1]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
[2]: As seen for example at https://www.mediawiki.org/w/api.php.
[3]: See https://phabricator.wikimedia.org/T176370 for progress on the
migration.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
An upgrade to the timestamp library used by MediaWiki is resulting in two
changes to the handling of timestamp inputs to the action API. There will
be no change to timestamps output by the API.
All of these changes should be deployed to Wikimedia wikis with
1.34.0-wmf.10.
Historically MediaWiki has ignored timezones in supported formats that
include timestamps, treating them as if the timezone specified were UTC. In
the future, specified timezones will be honored (and converted to UTC).
Historically some invalid formats were accepted, such
as "2019-05-22T12:00:00.....1257" or "Wed, 22 May 2019 12:00:00 A potato".
Due to improved validation, these will no longer be accepted.
Support for ISO 8601 and other formats has also been improved. See
https://www.mediawiki.org/wiki/Timestamp for details on the formats that
will be supported.
With the merge of Icb674095,[1] use of API action=logout will require a
CSRF token. This was considered a security issue, so the usual deprecation
process was not followed. See T25227[2] for details.
Clients that do not use a CSRF token with action=logout will receive a
badtoken error message ***and will not be logged out***.
This change should be deployed to Wikimedia wikis with 1.34.0-wmf.3. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule.
Overall client impact is expected to be relatively low, as gathered
statistics indicate there are relatively few users of this API call. None
the less, maintainers should check their code for use of action=logout and
update as necessary to maintain expected operation.
[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/504565
[2]: https://phabricator.wikimedia.orgdo not use /T25227
<https://phabricator.wikimedia.org/T25227>
[3]: https://phabricator.wikimedia.org/T25227#4902709
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
When list=allusers is used with auactiveusers, a property 'recenteditcount'
is returned in the result. In bug 67301[1] it was pointed out that this
property is including various other logged actions, and so should really be
named something like "recentactions".
Gerrit change 130093,[2] merged today, adds the "recentactions" result
property. "recenteditcount" is also returned for backwards compatability,
but will be removed at some point during the MediaWiki 1.25 development
cycle.
Any clients using this property should be updated to use the new property
name. The new property will be available on WMF wikis with 1.24wmf12, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
[2]: https://gerrit.wikimedia.org/r/#/c/130093/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Currently the codes for uncaught exceptions include the class name, for
example "internal_api_error_ReadOnlyError", or
"internal_api_error_DBQueryError", or possibly something like
"internal_api_error_MediaWiki\Namespace\FooBarException". As you can see in
that last example, that can get rather ugly and complicates recent attempts
to verify that all error codes use a restricted character set.
Thus, we are deprecating these error codes. In the future all such errors
will use the code "internal_api_error". The date for that change has not
yet been set.
If a client for some reason needs to see the class of the uncaught
exception, this is available in a new 'errorclass' data property in the API
error. This will be returned beginning in 1.33.0-wmf.8 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule. Note
that database errors will report the actual class, such as
"MediaWiki\rdbms\DBQueryError", rather than the old unprefixed name that
had been being maintained for backwards compatibility.
Clients relying on specific internal error codes or detecting internal
errors by looking for a "internal_api_error_" prefix should be updated to
recognize "internal_api_error" and to use 'errorclass' in preference to
using any class name that might be present in the error code.
In JSON format with errorformat=bc, an internal error might look something
like this:
{
"error": {
"code": "internal_api_error_InvalidArgumentException",
"info": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"errorclass": "InvalidArgumentException",
"trace": "InvalidArgumentException at ..."
},
"servedby": "hostname"
}
With modern errorformats, it might look like this:
{
"errors": [
{
"code": "internal_api_error_InvalidArgumentException",
"text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"data": {
"errorclass": "InvalidArgumentException"
}
}
],
"trace": "InvalidArgumentException at ...",
"servedby": "hostname"
}
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Now that MediaWiki has a pure-PHP tidying implementation, we are
deprecating non-tidy output.[1] Further, the future rewrite of Parsoid in
PHP[2] and its merge to core will have "tidying" as an integral feature.
Thus, the disabletidy parameter to action=parse is being deprecated and
will be removed at some point in the future. Clients should stop using the
parameter and begin using tidied HTML output.
This change should be deployed to Wikimedia wikis with 1.32.0-wmf.24 or
later, see https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a
schedule.
[1]: https://phabricator.wikimedia.org/T198214
[2]: https://phabricator.wikimedia.org/tag/parsoid-php/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
In preparation for multi-content revisions (MCR), we've made[1] several
changes to action=compare. These changes should be deployed to Wikimedia
wikis with 1.32.0-wmf.19 or later. The changes should also be available on
the Beta Cluster[2] soon for testing.
*== Supplying content using templated parameters ==*
For MCR, when specifying content (as with the `fromtext` and `totext`
parameters) we need the ability to specify content for each "slot" in the
page. The way this works for action=compare is that (1) the base revision
is determined using the parameters that identify the page and/or revision
(`fromtitle`/`totitle`, `fromrev`/`torev`, and so on), then (2) the new
`fromslots`/`toslots` parameter specifies which slots are being changed,
and then (3) new parameters for each value of `fromslots`/`toslots` specify
the content for each of those slots.
In the API help, these new parameters for each value of
`fromslots`/`toslots` are described as "templated parameters" and have a
placeholder in their names. Where the help describes "totext-{slot}", it's
meaning that if you supply "toslots=foo|bar" then there would be
corresponding parameters "totext-foo" and "totext-bar" to supply the text
for those two slots.
In Special:ApiSandbox, input fields for "totext-foo" and "totext-bar" will
appear when you enter those value for "toslots".
In the future templated parameters will be introduced for action=edit and
action=parse as well, and other modules as the need arises.
*== Deprecations and changes in action=compare ==*
The following parameters are deprecated, with replacements as indicated.
- `fromtext` is replaced with `fromtext-main` with `fromslots=main`.
- `fromcontentmodel` is replaced with `fromcontentmodel-main` with
`fromslots=main`.
- .`fromcontentformat` is replaced with `fromcontentformat-main` with
`fromslots=main`.
- `totext` is replaced with `totext-main` with `toslots=main`.
- `tocontentmodel` is replaced with `tocontentmodel-main` with
`toslots=main`.
- .`tocontentformat` is replaced with `tocontentformat-main` with
`toslots=main`.
The `fromsection` and `tosection` parameters are also deprecated with no
direct replacement. The intended use case for these parameters was to
simulate a diff of a section edit, by supplying the edited section's text
as `totext` and supplying `fromsection` to extract just the section being
edited from the current revision. This use case is now supported by
specifying `totext-main` as the edited section's text and supplying
`tosection-main` to identify the section being edited, which will be
combined into the existing content as for a section edit. This will result
in a diff more closely matching that returned for a section edit from the
web UI with respect to line numbers and context lines.
By default action=compare will return one HTML blob combining the diffs of
all slots, much as is shown in the web UI. The new `slots` parameter may be
used to get separate HTML blobs for each slot's diff and to limit which
slots' diffs are returned..
*== Other notes ==*
Note that the already-deprecated[3] diffing parameters to revision-related
modules, such as the rvdifftotext parameter to action=query&prop=revisions,
will not be updated for MCR. Code using these parameters should be updated
to use action=compare instead.
[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/448160
[2]: e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?modules=compare
[3]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2017-June/0001…
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
The Multi-Content Revisions project [1] introduced the concept of slots to
MediaWiki: instead of a single content, a revision can now contain multiple
content slots, each identified by a role name. With Gerrit change 413223
[2], the revision-related query API modules (action=query&prop=revisions,
action=query&prop=deletedrevisions, action=query&list=allrevisions, and
action=query&list=alldeletedrevisions) are updated to account for that:
* They take a new '<prefix>slots' parameter (where <prefix> is one of 'rv',
'drv', 'arv', 'adr') to indicate which roles to return information about.
Use '*' to return information about all slots, 'main' to return information
about the main slot (which is what was called the content of the revision
before multi-content revisions were introduced). When not used, it will
default to 'main' and the legacy response format will be used.
* Their '<prefix>prop' parameter takes a new value, 'roles', to list roles
for which a slot exists in the given revision.
* Using '<prefix>prop=content' or '<prefix>prop=contentmodel' without
specifiying '<prefix>slots' has been deprecated.
* The parameter '<prefix>contentformat' has been deprecated. Clients should
be prepared to handle the default format.
* Using '<prefix>slots' together with the (already deprecated) parameters
'<prefix>expandtemplates', '<prefix>generatexml', '<prefix>parse',
'<prefix>diffto', '<prefix>difftotext', '<prefix>difftotextpst',
'<prefix>contentformat' and '<prefix>prop=parsetree' results in an error.
Multi-Content Revisions is a work in progress; at this point in time, you
are unlikely to find a wiki with pages which have roles other than 'main'.
This will change in the next few months.
[1] https://www.mediawiki.org/wiki/Multi-Content_Revisions
[2] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/413223
--
Gergő Tisza (Tgr)
Senior Software Engineer
Wikimedia Foundation
It was noticed[1] that the error messages for "missing parameter" errors
were not including the module prefix, for example a query to
action=query&list=search could complain that the "search" parameter must be
set when the actual parameter name is "srsearch". This extends to the error
code, which in this example is "nosearch" rather than "nosrsearch".
This is now fixed, and should be deployed to Wikimedia sites with MediaWiki
1.32.0-wmf.15 and later. See
https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a schedule.
If your client is checking for specific missing parameter error codes, it
may need to be updated for the changed codes.
[1]: https://phabricator.wikimedia.org/T200155
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation