-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As you may know, the current MediaWiki API was based on an earlier interface, the BotQuery extension accessed via query.php.
During development of the new API, the old query.php was left in place on Wikimedia's sites to provide backwards-compatibility for tools and user scripts using it.
However it's a bit of a burden to keep it around -- being nearly unmaintained it suffers from "bitrot":
* Queries sometimes break due to backend changes
* Security problems are sometimes discovered and must be patched
We've been reluctant to just turn it off since some user scripts still use it (Lupin's Popups are rumored to be the most popular such), but I'd like to go ahead and plan to kill it.
I'm currently scheduling the Death of query.php for Monday, August 25 -- a little less than 4 weeks from today.
This gives interested parties a chance to either migrate their scripts to the current API ahead of time, or to start work on an adaptor to replace query.php -- transforming queries to send them to the new API and transforming the results back to a format compatible with the old one.
- -- brion vibber (brion @ wikimedia.org)
On Wed, Jul 30, 2008 at 11:48 PM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As you may know, the current MediaWiki API was based on an earlier interface, the BotQuery extension accessed via query.php.
During development of the new API, the old query.php was left in place on Wikimedia's sites to provide backwards-compatibility for tools and user scripts using it.
However it's a bit of a burden to keep it around -- being nearly unmaintained it suffers from "bitrot":
Queries sometimes break due to backend changes
Security problems are sometimes discovered and must be patched
We've been reluctant to just turn it off since some user scripts still use it (Lupin's Popups are rumored to be the most popular such), but I'd like to go ahead and plan to kill it.
I'm currently scheduling the Death of query.php for Monday, August 25 -- a little less than 4 weeks from today.
This gives interested parties a chance to either migrate their scripts to the current API ahead of time, or to start work on an adaptor to replace query.php -- transforming queries to send them to the new API and transforming the results back to a format compatible with the old one.
So far, I've found two things query.php does which api.php does not: * give bit depth of image (not exactly critical for my purposes, though) * for redirect pages, give the redirect target (this could affect a tool of mine)
I'll report more as I find them.
Magnus
On Thu, Jul 31, 2008 at 9:36 PM, Magnus Manske magnusmanske@googlemail.com wrote:
So far, I've found two things query.php does which api.php does not:
- give bit depth of image (not exactly critical for my purposes, though)
I may or may not fix this tonight.
- for redirect pages, give the redirect target (this could affect a
tool of mine)
http://en.wikipedia.org/w/api.php?action=query&titles=-100&prop=info&redirects
On Thu, Jul 31, 2008 at 8:56 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On Thu, Jul 31, 2008 at 9:36 PM, Magnus Manske magnusmanske@googlemail.com wrote:
So far, I've found two things query.php does which api.php does not:
- give bit depth of image (not exactly critical for my purposes, though)
I may or may not fix this tonight.
- for redirect pages, give the redirect target (this could affect a
tool of mine)
http://en.wikipedia.org/w/api.php?action=query&titles=-100&prop=info&redirects
Ah! Thanks.
I also see that some query.php functions return properties "touched" (not the same as timestamp, apparently) and "revid". This is not critical AFAIK, and could be replaced with another query; that, however, seems inefficient.
Magnus
Magnus Manske schreef:
Ah! Thanks. I also see that some query.php functions return properties "touched" (not the same as timestamp, apparently) and "revid". This is not critical AFAIK, and could be replaced with another query; that, however, seems inefficient.
Since touched is provided by prop=info and revid by prop=revisions (the latter in a slightly different format), you could just use generator=whatever&prop=info|revisions here.
Roan Kattouw (Catrope)
One thing I think cannot be done directly in api.php is to return the pages that embed a *list* of templates.
So for example if I have template1, template2, template3, with query.php I am able to return all pages embedding any of these, while in api.php I have to make a query for each one.
The problem is that eititle only accepts one title, and that titles= is now ignored.
[[en:User:Tizio]] Paolo Liberatore
On Thu, 31 Jul 2008, Magnus Manske wrote:
On Wed, Jul 30, 2008 at 11:48 PM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As you may know, the current MediaWiki API was based on an earlier interface, the BotQuery extension accessed via query.php.
During development of the new API, the old query.php was left in place on Wikimedia's sites to provide backwards-compatibility for tools and user scripts using it.
However it's a bit of a burden to keep it around -- being nearly unmaintained it suffers from "bitrot":
Queries sometimes break due to backend changes
Security problems are sometimes discovered and must be patched
We've been reluctant to just turn it off since some user scripts still use it (Lupin's Popups are rumored to be the most popular such), but I'd like to go ahead and plan to kill it.
I'm currently scheduling the Death of query.php for Monday, August 25 -- a little less than 4 weeks from today.
This gives interested parties a chance to either migrate their scripts to the current API ahead of time, or to start work on an adaptor to replace query.php -- transforming queries to send them to the new API and transforming the results back to a format compatible with the old one.
So far, I've found two things query.php does which api.php does not:
- give bit depth of image (not exactly critical for my purposes, though)
- for redirect pages, give the redirect target (this could affect a
tool of mine)
I'll report more as I find them.
Magnus
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Paolo Liberatore schreef:
One thing I think cannot be done directly in api.php is to return the pages that embed a *list* of templates.
So for example if I have template1, template2, template3, with query.php I am able to return all pages embedding any of these, while in api.php I have to make a query for each one.
There's a very good reason for that: queries with dozens of values for eititle become very inefficient very fast.
The problem is that eititle only accepts one title, and that titles= is now ignored.
That change was announced months ago on this list (search for "backlinks" in the subject).
Roan Kattouw (Catrope)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brion Vibber wrote:
During development of the new API, the old query.php was left in place on Wikimedia's sites to provide backwards-compatibility for tools and user scripts using it.
However it's a bit of a burden to keep it around -- being nearly unmaintained it suffers from "bitrot":
[snip]
I'm currently scheduling the Death of query.php for Monday, August 25 -- a little less than 4 weeks from today.
...now done.
query.php is dead! Long live api.php!
This gives interested parties a chance to either migrate their scripts to the current API ahead of time, or to start work on an adaptor to replace query.php -- transforming queries to send them to the new API and transforming the results back to a format compatible with the old one.
Guess nobody wanted an adaptor that badly. :)
- -- brion
mediawiki-api@lists.wikimedia.org