Gerrit change 135283 <https://gerrit.wikimedia.org/r/#/c/135283/> will
cause action=logevents to return an error if both the letitle and leprefix
parameters are specified. Previously specifying both of these parameters
would apply both filters, making leprefix pointless if letitle matches the
prefix or returning no results if not.
The expected impact of this change is low, as no uses of this parameter
combination were logged in the time period checked.
If any client is affected by this change, it may simply remove leprefix
when letitle is specified.
This change will be deployed to WMF wikis with 1.24wmf7, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Gerrit change 133955 <https://gerrit.wikimedia.org/r/#/c/133955/>, which I
plan to merge on Thursday for deployment to WMF wikis with
1.24wmf7<https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap>,
will cause the API to report an error when action=edit is used with the
"redirect" parameter and none of "appendtext", "prependtext", or
"section=new" are used. This will occur regardless of whether the page
being edited is actually a redirect.
API action=edit has a "redirect" parameter, which will automatically edit
the target page if the supplied title is a redirect. The original intention
of this feature was to be used in combination with appendtext or
section=new for posting notifications to user talk pages without having to
first check whether the page is a redirect (see bug
24330<https://bugzilla.wikimedia.org/show_bug.cgi?id=24330>).
But as currently implemented it will perform the edit even when replacement
page text is supplied, which is extremely prone to error: while reviewing
the patch proposing this change, I reviewed several scripts and bots that
were logged as submitting API requests with this combination of parameters
and every one would make erroneous edits when the target page is a redirect.
Clients not using the "redirect" parameter to action=edit or clients that
use it in combination with "appendtext", "prependtext", or "section=new"
will not be affected by this change. Affected clients have several options
for coping with this change, such as:
- Stop supplying the "redirect" parameter to action=edit, which will
edit the redirect page itself.
- When fetching the page content to transform it for the edit, use the
"redirect" parameter to action=query and submit the edit to the target page
directly (and without using the "redirect" parameter to action=edit) rather
than via the redirect title.
- Use appendtext, prependtext, or section=new instead of loading the
page's wikitext and appending or prepending content on the client side.
- Detect the redirect when fetching the page content and treat the
unexpected redirect as an error condition. Or handle the error returned by
action=edit in whatever manner is appropriate to your script, bot, or tool.
See https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the
deployment schedule.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Remember that clients should not be depending on the specific query string
data returned inside the query-continue or continue nodes. Clients should
be treating the returned key-value pairs as opaque data to be returned to
the server with the subsequent query.
Interested users may also wish to review the discussion thread from when a
similar change was made last year.[1]
To finish fixing bug 24782[2], Gerrit change 103589[3] changes the names
and values of various items under the continue or query-continue node in
the API response. Specifically,
* list=allimages will always use aicontinue, rather than sometimes using
aistart. The formatting of the value for the modes that formerly used
aistart will differ from that used by the modes that already used
aicontinue.
* list=blocks will now use bkcontinue rather than bkstart.
* list=categorymembers will always use cmcontinue, rather than sometimes
using cmstart. The formatting of the value for the modes that formerly used
cmstart will differ from that used by the modes that already used
cmcontinue.
* list=deletedrevs will always use drcontinue, rather than sometimes using
drstart. The formatting of the value for drcontinue is also changing for
the modes that did use it, and the formats differ between modes.
* list=logevents will now use lecontinue rather than lestart.
* list=protectedtitles will now use ptcontinue rather than ptstart.
* list=recentchanges is changing the formatting of the value of rccontinue.
* list=usercontribs will always use uccontinue, rather than sometimes using
ucstart. The formatting of the value for uccontinue is also changing for
the modes that did use it previously, and the formats differ between modes.
* list=watchlist will now use wlcontinue rather than wlstart.
These changes should be deployed to WMF wikis with 1.23wmf23, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
Also, if anyone is aware of other modules that use a bare timestamp[4] or
other non-unique value as their continuation, please reopen bug 24782 (if
they are in MediaWiki core) or file a new bug (if they are in an
extension). Thanks.
[1]:
http://lists.wikimedia.org/pipermail/mediawiki-api/2013-March/002926.html
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=24782
[3]: https://gerrit.wikimedia.org/r/#/c/103589/
[4]: Note prop=imageinfo uses a timestamp, but this is OK as in this case
it is apparently a unique identifier.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
It was noticed recently that these blockinfo properties return the internal
value from the database for the blockexpiry field, rather than formatting
them as does list=blocks. This means the formatting is more difficult to
parse, and that it may differ between installations of MediaWiki depending
on the database backend in use, and it doesn't match the formatting of
other timestamps returned by the API.
If anyone objects to this field being changed to be formatted in the same
manner as the expiry field returned by list=blocks, speak up on the
mediawik-api list.[1]
Thanks.
[1]: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
The API has long had difficulty in reporting the redirects to a title:
the best that could be done was to use
list=backlinks&blfilterredir=redirects, but that has issues if the
redirect has additional wikilinks in the non-redirect content (e.g.
bug 57057[1]). It also had issues with file and category redirects
(e.g. bug 27621[2]).
With the merge of Gerrit change 104764,[3] the API has a new
prop=redirects to query the redirects table directly. There is also a
new list=allredirects, corresponding to existing modules such as
list=alllinks. This should be deployed to WMF sites with 1.23wmf16.[4]
In addition, since Gerrit change 105829 (deployed with 1.23wmf10[4])
file and category redirects will no longer show up when using
list=imageusage or list=categorymembers, unless the target file or
category is also included in the non-redirect content. They will be
reported in list=backlinks instead.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=57057
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=27621
[3]: https://gerrit.wikimedia.org/r/#/c/104764/
[4]: https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap
[5]: https://gerrit.wikimedia.org/r/#/c/105829/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
---------- Forwarded message ----------
From: Yuvi Panda <yuvipanda(a)gmail.com>
Date: Thu, Feb 20, 2014 at 9:05 PM
Hello!
Account creation[1] was enabled on Wikimedia wikis a few weeks ago.
There is a bug[2] in the implementation that returns status codes in
all lower case ('success', 'needtoken') rather than in CamelCase
('Success', 'NeedToken'), which is what all other parts of the API
use. There is a patch[3] that will make action=createaccount behave
similar to the other actions.
If you have code that uses action=createaccount, you might have to
tweak your client to uppercase a few characters.
[1]: https://www.mediawiki.org/wiki/API:Account_creation
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=61663
[3]: https://gerrit.wikimedia.org/r/#/c/114473/
--
Yuvi Panda T
http://yuvi.in/blog
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
(Sorry for the double post, mediawiki-api subscribers)
---------- Forwarded message ----------
From: This, that and the other <at.light(a)live.com.au>
Date: Thu, Feb 13, 2014 at 5:46 AM
Subject: Modification to FlaggedRevs timestamp outputs
A patch is currently in Gerrit [1] to alter the way the FlaggedRevs
extension formats some timestamps in its API output.
Specifically, the "expiry" attribute generated by action=stabilize, and the
"protection_expiry" attribute generated by action=query&prop=flagged, are
changed to use an ISO-formatted timestamp (2014-02-13T11:00:00Z) in the
output, instead of the current internal format (20140213110000).
This change brings the timestamp formatting of FlaggedRevs into line with
the rest of the MediaWiki API, and allows external users to parse the
timestamp more easily.
(This may well affect nobody at all: [2] comes to mind!)
TTO
--
[1] https://gerrit.wikimedia.org/r/#/c/76460/
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=44468#c5
Gerrit change 107389[1] adds RevDel support to various API query modules,
so for example a user with the 'deletedhistory' right will be able to
retrieve the user and summary from prop=revisions.
This will cause some changes:
- list=deletedrevs, list=filearchive, list=recentchanges, and
list=watchlist formerly would not return any information at all for entries
where any field was revision-deleted. These entries will now be returned.
"hidden" indicators will be provided as is done for modules such as
prop=revisions.
- prop=imageinfo, list=logevents, prop=revisions, and list=usercontribs
will now return field values in addition to the "hidden" indicators, if the
user has the necessary user rights.
- When "hidden" indicators are returned, a new indicator "suppressed"
may also be returned to indicate whether suppression was activated.
- prop=imageinfo will now return info for revision-deleted files.
- list=logevents, when searching by user or title, will no longer skip
revisions where the user or title was revision-deleted if the requesting
user has the deletedhistory right.
- list=usercontributions will now look at the correct user rights
(deletedhistory and suppressrevision, not hideuser) to determine whether to
hide revision-deleted contributions.
All clients should be updated to expect rows with hidden fields for
deletedrevs, filearchive, recentchanges, and watchlist, and clients with
advanced permissions should be updated to properly handle (and to not
publicly reveal) the data for revision-deleted fields from these modules as
well as imageinfo, logevents, revisions, and usercontribs.
These changes will be deployed to WMF wikis with 1.23wmf11, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
[1]: https://gerrit.wikimedia.org/r/#/c/107389/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
The AssertEdit extension has long been installed on WMF wikis,
allowing bots to include "&assert=user" or "&assert=bot" in their
action=edit requests to prevent accidentally editing while logged out.
With Gerrit change 90263,[1] the functionality will be included in
MediaWiki core. At the same time, the following changes will be made
to the functioning of this feature:
* Assertion will be available on all API actions, not just edit.
* Assertion failure will now be indicated by an API error, code
'assertbotfailed' or 'assertuserfailed'.
* The 'nassert' parameter will be ignored, and using it will give an
unrecognized parameter warning.
* Other assertions, such as 'true', 'false', and 'exists', will no
longer function and attempting to use them will result in an
'unknown_assert' error.
Most clients should notice little change from this transition besides
the fact of receiving an error rather than a failure status from
action=edit.
This change will be rolled out with 1.23wmf10, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the
schedule.
[1]: https://gerrit.wikimedia.org/r/#/c/90263/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
When uploading files via the API, various warnings may be returned. One of
these warnings is "deleted-archive", with a value indicating the title
under which the file was previously uploaded and deleted.
With the merge of Gerrit change 105215,[1] which fixes bug 59167,[2] this
"deleted-archive" warning may have an empty value when the file content has
been suppressed. Clients should be adjusted to account for this possibility.
[1]: https://gerrit.wikimedia.org/r/#/c/105215/
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=59167
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation