prop=revisions has long ordered revisions by rev_id rather than timestamp
when returning results for a single page. In most cases this doesn't make a
difference, but for old pages imported from earlier versions of Wikipedia,
for revisions imported from Special:Import, and so on these orderings don't
always match.
prop=revisions has now been updated[1] to order by timestamp rather than
id. While this is technically a breaking change, it seems unlikely that any
clients will actually be broken by this.
This should be deployed to WMF wikis with 1.26wmf4, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule.
[1]: https://gerrit.wikimedia.org/r/#/c/188843/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Previous announcement:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-September…
During the 1.25 development cycle, the API has been warning you if you're
specifying neither the "continue" nor "rawcontinue" parameters to
action=query. Recently this warning was targeted more specifically to
queries that actually return continuation data. The time is coming soon for
making this change, so please check your bots, bot frameworks, scripts, and
so on to ensure that you won't be broken when this change is made.
If you want to continue using your existing continuation code unchanged,
all you need to do is add the "rawcontinue" parameter to your action=query
queries.
If you'd rather change to the easier-to-get-right new style, add an empty
"continue" parameter to your initial action=query queries. See
https://www.mediawiki.org/wiki/API:Query#Continuing_queries for details on
the new mechanism.
If you do nothing, sometime in the next few months your code will likely
start thinking that no queries ever need continuation when the default is
changed to return the new 'continue' node rather than the old
'query-continue'. I'll send an announcement when the specific date is
decided, but I don't promise more than a week's notice.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Bug T38358[1] points out that using a '#' character in input passed to
ApiQueryBase::titlePartToKey() will silently truncate at the character
before the '#', often generating incorrect results.
With the merge of Gerrit change 191889,[2] passing a '#' into this method
will now return an invalidtitle error, just as already happens when a
title-part containing invalid characters such as '<' or '>' is passed in.
The affected parameters include:
* list=allpages apto, apfrom, and apprefix
* list=alldeletedrevisions adrto, adrfrom, and adrprefix
* list=deletedrevs drto, drfrom, and drprefix
* list=filearchive fato, fafrom, and faprefix
* list=allimages aito, aifrom, and aiprefix
* list=alllinks alto, alfrom, and alprefix
* list=alltransclusions atto, atfrom, and atprefix
* list=allfileusages afto, affrom, and afprefix
* list=allredirects arto, arfrom, and arprefix
* list=allcategories acto, acfrom, and acprefix
This should be deployed to WMF wikis with 1.25wmf19, see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
[1]: https://phabricator.wikimedia.org/T38358
[2]: https://gerrit.wikimedia.org/r/#/c/191889/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
It was pointed out in T88397[1] that a list=search query was populating the
'redirecttitle' output property as an object containing the internal
members of a MediaWiki Title object, where a string containing the prefixed
title is more likely what was intended.
Any clients relying on this output property should be updated to deal with
the corrected value.
This will be deployed to WMF wikis with 1.25wmf16, see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
[1]: https://phabricator.wikimedia.org/T88397
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
I've just deployed the ApiFeatureUsage extension to Beta Labs for testing.
If an API client (e.g. a bot or a user script) sets a unique User-Agent or
Api-User-Agent header, a summary of deprecated API features hit by that
client may be fetched from Special:ApiFeatureUsage[1] or from the API
itself.[2]
Please try it out, and report any issues in Phabricator using the
MediaWiki-extension-ApiFeatureUsage project. If things look good after
testing I'll be looking at getting it deployed to production in the next
month or so.
[1]: http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiFeatureUsage
[2]:
http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=query+fe…
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
With Gerrit change 174200,[1] an HTTP header "Api-User-Agent" header will
be recognized for logging from the API. This should benefit clients using
XMLHttpRequest where the normal User-Agent header is locked down by the
browser. The logged agent will be the concatenation of Api-User-Agent and
the browser's User-Agent header.
This should come in handy once the ApiFeatureUsage extension[2][3] is
reviewed and deployed.
The new header will be recognized starting with 1.25wmf10, see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule. It
will be ignored for wikis still on 1.25wmf8 or 1.25wmf9, so feel free to
upgrade any scripts immediately. Bots and other clients that have full
control over the User-Agent header should continue to use that header
exclusively.
[1]: https://gerrit.wikimedia.org/r/#/c/174200/
[2]: https://www.mediawiki.org/wiki/Extension:ApiFeatureUsage
[3]:
https://www.mediawiki.org/wiki/API/Architecture_work/Planning#Deprecated_AP…
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Bug 73321[1] pointed out that generator=search was incorrectly trying to
set the same "searchinfo" and other properties on the result that were set
by list=search.
Gerrit change 172794[2] removes this setting, so generator=search will no
longer provide 'searchinfo' or 'interwikisearchinfo' members in the result.
Interwiki titles from the generator will no longer populate an
'interwikisearch' result property, but will instead be included in the
generated titles and thus (for action=query) will populate the 'interwiki'
property.
This change should be deployed to WMF wikis with 1.25wmf9, see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=73321
[2]: https://gerrit.wikimedia.org/r/#/c/172794/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
The ApiQueryDeletedrevs module has issues: since it's a list module rather
than a prop module, it isn't handled correctly by the simplified
continuation, it doesn't support input of specific revids, and so on.
Gerrit change 168646[1] deprecates list=deletedrevs in favor of two new
modules:
* list=alldeletedrevisions will query the deleted revisions in a namespace
and/or for a user.
* prop=deletedrevisions will work like prop=revisions, querying deleted
revisions for a page, or specific revisions requested using action=query's
revids parameter.
For the latter to work properly, the revids parameter will now recognize
deleted revision IDs as valid if the querying user has the 'deletedhistory'
user right; before this change deleted revision IDs were treated as
non-existent.
These changes should be deployed to WMF wikis with 1.25wmf7, see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
At some point in the future, limited information from the archive table may
be made available to all users, as is already done on Tool Labs.[2] If that
happens, recognition of deleted revision IDs as valid for the revids
parameter will likely be extended to all users.
[1]: https://gerrit.wikimedia.org/r/#/c/168646/
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=49088
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
The API supports two methods for continuing action=query when more results
are available, the simple method[1] and the raw method.[2] The raw method
is currently the default for historical reasons, but as the simple method
is much easier for new users to use *correctly* that really should be the
default.
To make this transition easy for clients, the current plan is to make the
change on the following timetable:
* Starting with 1.24wmf22,[3][4] action=query will recognize a
"rawcontinue" boolean input parameter. Clients that wish to continue using
the raw method for continuation should begin supplying this parameter with
all action=query queries.
* Sometime during the MediaWiki 1.25 development cycle, the API will begin
reporting warnings when neither "continue" nor "rawcontinue" are supplied
with action=query.[5]
* Sometime during the MediaWiki 1.26 development cycle, simplified
continuation will become the default.[6]
Note this is also documented at <
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Simplified_…>.
See other sections on that page for additional planned API changes.
[1]: https://www.mediawiki.org/wiki/API:Query#Continuing_queries
[2]: https://www.mediawiki.org/wiki/API:Raw_Query_Continue
[3]: https://gerrit.wikimedia.org/r/#/c/154092/
[4]: See https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the
schedule of deployments to WMF wikis.
[5]: https://gerrit.wikimedia.org/r/#/c/160222/
[6]: https://gerrit.wikimedia.org/r/#/c/160223/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation