Per https://bugzilla.wikimedia.org/show_bug.cgi?id=24781 , the XML
output returned by the API has a namespace since 1.18.
1.17: <api>
1.18: <api xmlns="http://www.mediawiki.org/xml/api/">
Apparently this breaks for some people using XPATH expressions,
although comments on Bugzilla indicated this shouldn't be the case,
and since I don't know anything about XML namespaces I trusted my
fellow MW devs who said it wouldn't be a problem :)
Roan
With MediaWiki 1.18 now being deployed to WMF wikis (the final set of
wikis is slated to get 1.18 tonight starting at 23:00 UTC), I've heard
reports of people using list=categorymembers&cmnamespace=6 and getting
an empty result, even though there are files in the category. This is
a symptom of the cmnamespace workaround that was introduced about two
years ago.
However, we now have the cmtype parameter that can be used to replace
most uses of cmnamespace, and doesn't suffer from any of its flaws (no
nasty hacks to work around slow DB queries, no incomplete or empty
results):
To only list files, use &cmtype=file (previously &cmnamespace=6)
To only list subcategories, use &cmtype=subcat (previously &cmnamespace=14)
To only list 'normal' pages that aren't files or subcategories, use
&cmtype=page (previously
&cmnamespace=0|1|etc|everything|except|six|and|fourteen)
You can combine values for cmtype, e.g. &cmtype=file|subcat to list
both files and subcategories. The default value for cmtype is
file|subcat|page (i.e. list everything).
Roan
---------- Forwarded message ----------
From: Krinkle <krinklemail(a)gmail.com>
Date: Mon, Jun 6, 2011 at 3:08 AM
Subject: [Wikitech-l] BREAKING CHANGE: action=watch now requires token
(and API requires token and POST)
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>, Wikimedia developers
<wikitech-l(a)lists.wikimedia.org>
Hi all,
As of MediaWiki 1.19 the action of watching or unwatching a page
requires a
token [1]. A similar measure was taken during the development of 1.17
for
the markpatrolled action, and the reason is the same: To prevent
third-party sites from executing write actions without the users'
permission.
The ApiWatch module must be posted and given a token. As with other
edittoken-based api actions, the token is salted but stays the same
throughout a session. Scripts may retrieve this token, as usual, through
the ApiQueryInfo (must be logged in, anon users don't have action-watch)
[4]
On a sidenote, recently the the mw.user.tokens resourceloader module [8]
has been created [9]. This, together with the mw.user.options module
introduced in 1.17, gadgets can do advanced actions without polling
the API
for common data. If you script is ran from a wiki, you can get the
tokens
from [5] this Map without an http request to the query info module. An
example has been made in the mediawiki.action.watch.ajax module [6].
This
(un)watches through the API.
The actual change in the WatchAction class was made in r89545 [3].
The ApiWatch module was changed in r88522 [7].
--
Krinkle
[1] https://bugzilla.wikimedia.org/27655 Require token for
(un)watching pages
[2] https://bugzilla.wikimedia.org/29070 Add token to action=watch API
[3] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89545
[4] http://yourdomain/w/api.php?action=query&prop=info&titles=Main+Page&intoken…
[5] http://www.mediawiki.org/wiki/ResourceLoader/Default_modules#tokens
[6] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/mediawiki.…
[7] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88522
[8] https://bugzilla.wikimedia.org/29067 Expose user.tokens like we do
user.options in ResourceLoader
[9] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88553
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
---------- Forwarded message ----------
From: Brion Vibber <brion(a)pobox.com>
Date: Tue, May 3, 2011 at 8:19 PM
Subject: API YAML output change heads-up
To: Roan Kattouw <roan(a)wikimedia.org>
One of the MediaWiki API's output formats for some time has been YAML
<http://www.yaml.org> -- while it doesn't seem to be widely used, it
is there and I assume someone, somewhere is pulling data in this
format. :)
The spyc library we've used to generate YAML output has had a number
of bugs; recently, MediaWiki development trunk has resolved this by
replacing spyc with the existing JSON output module:
https://bugzilla.wikimedia.org/show_bug.cgi?id=28591
Since YAML is a superset of JSON, this should be a transparent change
-- YAML clients should interpret the new output into the same data
structures as before.
Be aware though that there will be differences where previously the
formatting was affected by bugs in the YAML outputter, such as this
example:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86302#c16513
If your code relied on particular structures in YAML output, it could
fail with the corrected structures; please double-check that your code
continues to work if switched over to format=json.
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
As of r86257 [1], which will be deployed to Wikimedia wikis soon and
will be included in the 1.17 release, sortkeys output by
list=categorymembers and prop=categories are now encoded as
hexadecimal strings, so "FOO" becomes "464f4f".
As previously announced, sortkeys are no longer guaranteed to be
human-readable, and may in fact contain binary data (this will happen
when Wikimedia switches to the UCA/ICU collation). However, outputting
binary data, notably in XML, was problematic [2], so I decided to use
hexadecimal encoding. This means the sortkey as returned by the API is
now guaranteed to not be human-readable, even if the underlying
collation uses a human-readable format (such as the uppercase
collation currently in use on Wikimedia wikis). However, it will still
sort correctly: if A sorts before B in the binary format, that will
also be the case in the hexadecimal format.
The following things changed:
* The 'sortkey' property in list=categorymembers and prop=categories
is now a hexadecimal string
* In prop=categories , clprop=sortkey will now also output the
'sortkeyprefix' property (human-readable part of the sortkey).
list=categorymembers already provided this through
cmprop=sortkeyprefix
* The format of cmcontinue has changed from type|pageid|rawsortkey to
type|hexsortkey|pageid . If you did not make any assumptions about the
format of cmcontinue and just passed back whatever you got in
query-continue, this won't affect you
Roan Kattouw (Catrope)
[1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWik…
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28541
As of r84905 [1] (going live to Wikimedia within the hour), the cltype
parameter to list=categorymembers is ignored when clsort=timestamp is
set. This change is needed for performance reasons: long-running
queries were causing bug 28291 [2] on Wikimedia wikis.
This does not break backwards compatibility with any released version
of MediaWiki, because cltype is new in 1.17. Functional
cltype=foo&clsort=timestamp behavior was only live on Wikimedia wikis
for about 2-3 weeks.
Roan Kattouw (Catrope)
2010/10/23 Roan Kattouw <roan.kattouw(a)gmail.com>:
> As of r75274, patrol tokens accepted by action=patrol and generated by
> list=recentchanges are no longer equal to edit tokens and are no
> longer the same within a session. Instead, they are now different for
> every recentchanges row (i.e. they depend on the rcid).
>
> It may take a while for this change to be deployed to the Wikimedia
> cluster, but in the meantime changing your clients to no longer depend
> on the patrol token to stay the same can't hurt.
>
This has changed again in r78141. Patrol tokens no longer depend on
rcid; instead, they are the same throughout the session (like the edit
token is), but NOT equal to the edit token. Also,
api.php?action=patrol now only accepts POST requests.
The changes in r75274 were never part of any release and were never
deployed to Wikimedia wikis.
Roan Kattouw (Catrope)
As of r75274, patrol tokens accepted by action=patrol and generated by
list=recentchanges are no longer equal to edit tokens and are no
longer the same within a session. Instead, they are now different for
every recentchanges row (i.e. they depend on the rcid).
It may take a while for this change to be deployed to the Wikimedia
cluster, but in the meantime changing your clients to no longer depend
on the patrol token to stay the same can't hurt.
Roan Kattouw (Catrope)
As of Monday Feb 15, passing a User-Agent header is mandatory for
*all* HTTP requests to Wikimedia sites. This includes the API. If your
client doesn't provide a User-Agent header, it'll receive HTTP 403
errors with the text "Please provide a User-Agent" or something along
those lines. This was announced in a (now rather lengthy) thread on
wikitech-l: http://lists.wikimedia.org/pipermail/wikitech-l/2010-February/046777.html
Ideally, your User-Agent header should identify your client in such a
way that Wikimedia staff are able to figure out who to contact if your
client is somehow engaging in disruptive behavior. Putting in an
e-mail address works well for this, but mentioning your wiki username,
the name of the wiki page of the tool (with wiki prefix, so they know
on which of the 812 wikis to look) or a URL to a page about you or
your tool are fine too, provided that they lead to a functional way of
contacting you.
Please don't take this as "if I set a User-Agent my client will
potentially be blocked". If it's being disruptive, it'll be blocked
anyway; if you set a User-Agent header, you'll be informed
immediately, or better, get a chance to fix your client without having
it blocked.
Roan Kattouw (Catrope)