As you might have noticed, there have recently been many changes to
MediaWiki API. This is in part due to my push for API
2.0<http://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap/Naming_Clean…>,
which will include API versioning, streamlined JSON-only result format,
localized warnings and errors, naming
cleanup<http://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap/Naming_Clean…>,
and many other changes. On top of that, there has been various proposals
for content-oriented RESTful API (as oppose to SQL-like query API). To
learn more or to participate in the planning or implementation, see proposed
changes <http://www.mediawiki.org/wiki/Requests_for_comment/API_Future> or
contact me directly.
*
*
There will be a
conference<https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Wikipedia_Day>in
New York tomorrow, Feb 23rd, at NYU. I intend to do an introductory
API
presentation there, partially covering some of the proposed changes. Please
stop by if you want to discuss API, or just to say hi.
*Important reminder to API users*: Please ensure you set the user agent
string to contain both the name of your tool, the framework it uses, and a
way to contact you. See User-Agent
policy<http://meta.wikimedia.org/wiki/User-Agent_policy>.
API users that do not follow this policy may be banned at any moment.
Example:* MyCoolTool/1.1 (http://example.com/MyCoolTool/;
MyCoolTool(a)example.com) BasedOnSuperLib/1.4*
Lastly, to minimize traffic on this list, I will try to batch announcements
into one email, unless there is an immediate breaking change.
* prop=pageprops & ppprom=... now allows multiple
values<https://gerrit.wikimedia.org/r/#/c/41590/>
(anomie)
* Extensions: $wgAPIGeneratorModules is now
obsolete<https://gerrit.wikimedia.org/r/#/c/46196/>, the
list of generators is now dynamic (yurik)
* HTML-formatted results (format=*fm) will now wrap long
lines<https://gerrit.wikimedia.org/r/#/c/37188/>(waldir)
--yurik
In change I7a3d7b6e[1] which was recently merged, the ApiPageSet
module received a major overhaul. In particular, the parameters to the
constructor have changed, and it now extends ApiBase rather than
ApiQueryBase. These changes will not affect API clients, but any
third-party API modules that use ApiPageSet will need to be updated.
Also as part of this change, ApiQuery is losing its newGenerator() and
executeGeneratorModule() methods, and ApiQueryGeneratorBase's
setGeneratorMode() is gaining a required parameter. These methods are
unlikely to have been used in non-core code.
This brings with it enhanced functionality: non-query actions using
ApiPageSet may now use generators. The core action=purge and
action=setnotificationtimestamp modules have already been enhanced in
this way.
This change should go live on WMF wikis with 1.21wmf10; see the
roadmap for details.[2]
[1]: https://gerrit.wikimedia.org/r/#/c/44087/
[2]: https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
Since it has been broken since the move to git[1] and is unlikely to
have been particularly useful anyway, I've just merged a change[2] to
remove the version information (and the 'version' parameter) from the
API help. This may result in a warning about an unrecognized
parameter.
Also, the 'version' property in the results from action=paraminfo will
now be the empty string. It was not removed completely at this time to
avoid breaking clients where accessing an undefined property is a
fatal error; however, it should be considered deprecated and may be
removed in a future version.
Note that version information for MediaWiki as a whole is still
available via prop=siteinfo.[3]
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=35885
[2]: https://gerrit.wikimedia.org/r/#/c/43622/
[3]: e.g. https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
For badcontinue errors, the API currently returns a code of either
"??badcontinue" or "??_badcontinue" (where ?? is the module's prefix),
depending on the module. The human-readable error message text may
also vary depending on the module.
In 1.21wmf8,[1] these will be standardized as "??badcontinue", with a
human-readable message of "Invalid continue param. You should pass the
original value returned by the previous query".
Since well-behaved API clients should never see this error message,
this change should not require any client updates.
[1]: Gerrit change https://gerrit.wikimedia.org/r/#/c/42398
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
Forwarding to the announcements list. This also causes this to re-post
to the mediawiki-api list, sorry about that.
Roan
---------- Forwarded message ----------
From: Chris Steipp <csteipp(a)wikimedia.org>
Date: Thu, Aug 30, 2012 at 10:47 PM
Subject: [Mediawiki-api] X-Frame-Options header
To: mediawiki-api(a)lists.wikimedia.org
Hi, I wanted to call attention on this list to a small change [1] in
the api that we just released as part of a security update [2]. We
previously had not set X-Frame-Option headers on the result of api
queries. This could leave a site open to a variety of UI redressing
attacks, so the WMF sites now set the X-Frame-Option: header to 'DENY'
on API results. This will also be the default configuration for new
downloads.
If you need to show the result of an API query in an iframe, you can
set the $wgApiFrameOptions = false to disable the header. However, I
would encourage everyone to keep the header, as it will help prevent
this type of attack.
[1] - https://bugzilla.wikimedia.org/show_bug.cgi?id=39180
[2] - http://lists.wikimedia.org/pipermail/mediawiki-announce/2012-August/000119.…
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
The behavior of the ignorewarnings parameter in action=upload was
changed [1] recently. The ignorewarnings parameter causes an upload to
go through even if there were (non-fatal) warnings. Previously, it
also removed the warnings from the API output, but with Mark's recent
change, these warnings will now be shown. Clients that check for
"Success" or "Warning" shouldn't break, but clients that only check
for the <warnings> element to see if an upload failed may start
failing.
This change will be part of the 1.20wmf9 deployment, which will go
live on WMF wikis in stages between August 6 and August 13 [2].
Roan
[1] https://gerrit.wikimedia.org/r/#/c/9261/
[2] https://www.mediawiki.org/wiki/MediaWiki_1.20/Roadmap#Schedule_for_the_depl…
Today I approved and merged a change [1] by Brad Jorsch that changes
the way continue parameters are used in some API modules. These
changes do not break backwards compatibility unless you were doing
things you weren't supposed to, but I figured I should announce them
anyway.
There were a few modules that were using continuations like
<query-continue><allcategories acfrom="Foobar" /></query-continue> ;
some of these were changed to use a dedicated accontinue parameter
instead of reusing acfrom (keeping acfrom, it has a legitimate
purpose). This shouldn't be a problem for clients that use values from
query-continue verbatim and don't make any assumptions about which
parameters will be used for continuations. The following modules are
affected:
* allcategories (acfrom -> accontinue)
* allimages (aifrom -> aicontinue)
* alllinks now consistently uses alcontinue instead of alfrom in all
cases; previously, alfrom was used in some cases and alcontinue in
others
* allpages (apfrom -> apcontinue)
* filearchive (fafrom -> facontinue)
Additionally, the values provided in query-continue will no longer be
normalized for presentation, and the values read from the continue
parameters will no longer be normalized for database usage. This won't
be a problem if you're just passing query-continue values back in
verbatim, but it might present problems if you were using continue
parameters in hacky ways to jump to certain parts of the result. This
change was needed to fix bug 36987[2] and bug 29290 [3]. The following
modules and parameters are affected:
* allcategories (accontinue)
* allimages (aicontinue)
* alllinks (alcontinue)
* allpages (apcontinue)
* categories (clcontinue)
* deletedrevs (dlcontinue)
* duplicatefiles (dfcontinue)
* filearchive (facontinue)
* iwbacklinks (iwblcontinue)
* iwlinks (iwcontinue)
* images (imcontinue)
* langbacklinks (lblcontinue)
* links (plcontinue)
* templates (tlcontinue)
* watchlistraw (wrcontinue)
This change will be deployed as part of the 1.20wmf8 deployment. This
will be deployed to different wikis on different days over the course
of the next two weeks, see the deployment schedule [4].
Roan
[1] https://gerrit.wikimedia.org/r/#/c/8407/
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36987
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=29290
[4] https://www.mediawiki.org/wiki/MediaWiki_1.20/Roadmap#Schedule_for_the_depl…
Forwarding this to mediawiki-api-announce. Apologies to the
mediawiki-api subscribers who'll get this message for the second time.
Roan
---------- Forwarded message ----------
From: Sumana Harihareswara <sumanah(a)wikimedia.org>
Date: Tue, Jan 17, 2012 at 2:20 AM
Subject: [Mediawiki-api] Editing en.wp via API to be disabled on 18 January
To: mediawiki-api(a)lists.wikimedia.org
https://blog.wikimedia.org/2012/01/16/wikipedias-community-calls-for-anti-s…
Editing pages on English Wikipedia via the web service API will be
disabled for 24 hours beginning at 05:00 UTC on Wednesday, January 18,
as part of the anti-SOPA/PIPA blackout.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Per the below, protocol-relative URLs are now enabled on
test.wikipedia.org and will be rolled out to the rest of the wikis
over the course of the next few weeks. What this means is that URLs
used in the interface will now look like //example.com instead of
http://example.com , so we can support both HTTP and HTTPS without
splitting our cache.
The API, in most cases, will not output protocol-relative URLs, but
will continue to output http:// URLs no matter whether you call it
over HTTP or HTTPS. This is because we don't expect API clients to be
able to resolve these correctly, and that the context of these URLs
(which is needed to resolve them) will frequently get lost along the
way. And we don't wanna go breaking clients, now, do we? :)
The exceptions to this, as far as I am aware, are:
* HTML produced by the parser will have protocol-relative URLs in <a
href="..."> tags etc.
* prop=extlinks and list=exturlusage will output URLs verbatim as they
appear in the article, which means they may output protocol-relative
URLs
If you are getting protocol-relative URLs in some other place, that's
probably a bug (or maybe it's intentional and I forgot to list it
here), so please let me know, or e-mail this list, or file bug, if you
see that happening.
Roan Kattouw (Catrope)
---------- Forwarded message ----------
From: Ryan Lane <rlane32(a)gmail.com>
Date: Thu, Jul 14, 2011 at 8:55 PM
Subject: [Wikitech-l] Protocol-relative URLs enabled on test.wikipedia.org
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Over the past couple days Roan Kattouw and I have been pushing out
changes to enable protocol-relative URL support. We've gotten to a
point where we think it is stable and working.
We've enabled this on test.wikipedia.org, and plan on running it for
two weeks before enabling it elsewhere. Please test if everything is
working properly, especially with regards to the API and bots. Report
bugs in bugzilla if any are found.
- Ryan
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Forwarding to the announce list. Apologies to the mediawiki-api list
for double-posting.
---------- Forwarded message ----------
From: Bryan Tong Minh <bryan.tongminh(a)gmail.com>
Date: Thu, Oct 6, 2011 at 10:14 PM
Subject: Re: [Mediawiki-api] [Mediawiki-api-announce] API XML output
now has a namespace
To: mediawiki-api(a)lists.wikimedia.org
Cc: MediaWiki API announcements & discussion
<mediawiki-api-announce(a)lists.wikimedia.org>
On Thu, Oct 6, 2011 at 1:47 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
> Per https://bugzilla.wikimedia.org/show_bug.cgi?id=24781 , the XML
> output returned by the API has a namespace since 1.18.
>
Per the discussion on the bug, this list, and elsewhere, I have
reverted the unconditional addition of the XML namespace. Once r99135
[1] has been deployed, the API will no longer output an XML namespace
unless the includexmlnamespace has been set.
Bryan
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/99135