Mediawiki-api February 2008

mediawiki-api@lists.wikimedia.org

12 participants
12 discussions

new bug in category members query?
by Minh Lê Ngọc 28 Feb '08

28 Feb '08

I'm having trouble with querying English pronunciation from commons by my bots. Take a look at queries below: - title=<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…>Category:English pronunciation<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…> - title=Category:English pronunciation&cmcontinue=used to.ogg|<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…> There are 4 items appear twice in these 2 queries: wherewithal, wires, wire, wired and items are sorted in no order. What's up?

5 9

blredirect
by Roan Kattouw 25 Feb '08

25 Feb '08

As of r31260 [1], the blredirect, eiredirect and iuredirect parameters, for the backlinks, embeddedin and imageusage modules respectively, are now available. Setting these parameters will make the API list links through redirects as well, à la Special:Whatlinkshere. Since this is not really useful for embeddedin (redirects hardly ever embed pages) or for imageusage (image redirects haven't been implemented yet), I'll use blredirect in the example below. api.php?action=query&list=backlinks&bltitle=Foo&blredirect&bllimit=3 will generate the following output: <?xml version="1.0" encoding="utf-8"?> <api> <query-continue> <backlinks blcontinue="0|Foo|44|72" /> </query-continue> <query> <backlinks> <bl pageid="36" ns="0" title="Test" /> <bl pageid="44" ns="0" title="Redir" redirect=""> <redirlinks> <bl pageid="34" ns="0" title="Bar" /> <bl pageid="45" ns="0" title="Blah" /> <bl pageid="54" ns="0" title="Main Page" /> </redirlinks> </bl> <bl pageid="57" ns="0" title="New page" /> </backlinks> </query> </api> This means [[Test]] and [[New page]] link to [[Foo]], while [[Bar]], [[Blah]] and [[Main Page]] link to [[Redir]], which in turn redirects to [[Foo]]. Note that bllimit=3 applies both to the first level (three pages linking to [[Foo]] are listed) and the second level (three pages linking to redirects to [[Foo]] are listed) separately. Because of this, bllimit is capped at 250 (2500 for bots and sysops) if blredirect is set. We continue the request with: api.php?action=query&list=backlinks&blcontinue=0|Foo|44|72&blredirect&bllimit=3 <?xml version="1.0" encoding="utf-8"?> <api> <query> <backlinks> <bl pageid="44" ns="0" title="Redir" redirect=""> <redirlinks> <bl pageid="72" ns="0" title="Dummy1" /> </redirlinks> </bl> <bl pageid="57" ns="0" title="New page" /> <bl pageid="71" ns="0" title="Redir2" redirect=""> <redirlinks> <bl pageid="72" ns="0" title="Dummy1" /> </redirlinks> </bl> </backlinks> </query> </api> Because the list of links to [[Redir]] wasn't finished yet, the continued request starts there, and lists [[New page]] again. Of course, list=backlinks behaves exactly the way it used to when blredirect is not set, so this is not a breaking change. Roan Kattouw (Catrope) [1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31260

2 1

BREAKING CHANGE in limit=max handling
by Roan Kattouw 25 Feb '08

25 Feb '08

In r31258 [1], the output for limit=max was changed. The previous implementation returned <limits limit="500" /> when limit=max was used. However, a request like api.php?action=query&list=logevents&prop=revisions&lelimit=max&rvlimit=max&rvprop=content&titles=Foo caused the following problems: * The code would try to overwrite the already set <limits> tag, causing a fatal error * prop=revisions&rvprop=content enforces a stricter limit (200) than list=logevents (500) These issues have been resolved by changing the output format to: <limits logevents="500" revisions="200" /> This change is expected to be included in the upcoming 1.12 release (unless Brion throws it out). Roan Kattouw (Catrope) [1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31258

1 0

Partnerships FAQ: question about subscribing to content
by Platonides 24 Feb '08

24 Feb '08

I don't think it can be done. The RSS of the wiki is for general changes only (Special:Recentchanges). You could query the category via the api, as in http://en.wikipedia.org/w/api.php?action=query&list=categorymembers&generat… but a) The output format is not the one of RSS and b) the sorting won't be the most appropiate. However, i think it's a quite interesting option, so i'm CCing to the mediawiki-api list for input about that. Another option is to create an account and use the rss of your watchlist. This gives you the maximum liberty about which articles to include/exclude. Once you have one of such feeds, you can see them with your preferred news aggregator, include on a web using a custom system, a plugin... Specifically, mediawiki has several extensions able to include content from external RSS feeds: http://www.mediawiki.org/wiki/Category:RSS_Extensions Cary Bass wrote: > Hey, can someone take this one on? Thanks. > - > > Cary Bass > Volunteer Coordinator > Your continued donations keep Wikipedia running! Support the Wikimedia > Foundation today: http://donate.wikimedia.org > > Wikimedia Foundation, Inc. > Phone: 727.231.0101 > Fax: 727.258.0207 > E-Mail: cbass(a)wikimedia.org > > > -----Original Message----- > From: Sue Gardner [mailto:sgardner@wikimedia.org] > Sent: Friday, February 22, 2008 5:14 PM > To: Cary Bass > Subject: Partnerships FAQ: question about subscribing to content > > Is there a way for me to subscribe to particular kinds of content out of > Wikipedia (e.g., articles about folk music, or articles about Canada), so > that my encyclopedia benefits automatically from the ongoing contributions > of Wikipedia contributors? > > Cary, could you try to find someone to answer this question on the > partnerships FAQ? (I am assuming the answer is no, but I'm not sure.) No > rush, anytime :-) > > Thanks, > Sue

2 1

user_id from revision
by Ian Pye 20 Feb '08

20 Feb '08

Is it possible to retrieve the user_id of the user who made a given revision? I see that there is a ids element to rvprop, and a user element, but neither of these give me the user_id. Alternatively, is there a way I'm not seeing to map a user name to user_id? Thanks for your help, Ian

3 4

Gzip Compression
by Ian Pye 13 Feb '08

13 Feb '08

Hi, I apologize if this has been mentioned earlier and I missed it, but: I infer that GZip compression is available when making api calls, but I can't find any documentation on it. Can someone point me in the right direction to get started? Thanks, Ian

2 1

APIEdit and hooks
by Bryan Tong Minh 13 Feb '08

13 Feb '08

Hello, I was looking at hooks, in particular ArticleDeleteComplete, and noticed that they are called from a function that is quite in the front end 'doDelete'. When an article is deleted via the API, it calls the backend function 'doDeleteArticle'. This means that the hooks related to article deletion are never called. Is this intended? Bryan

2 3

BREAKING CHANGE to list=categorymembers
by Roan Kattouw 07 Feb '08

07 Feb '08

Great, sent this e-mail to the wrong address and didn't notice until three days later... In r30533 [1], the following changes were made to list=categorymembers: * The cmtitle parameter was added, which is intended to replace cmcategory in the long run. The difference is that cmtitle requires the Category: prefix, whereas cmcategory does not. (Example: cmtitle=Category:Living_people and cmcategory=Living_people) * The cmcategory parameter is now deprecated, and WILL BE REMOVED in early March (probably around March 3rd) * A few error messages have been changed: ** <error code="cmparam_category" info="Category parameter is required"> was changed to <error code="cmnotitle" info="Either the cmcategory or the cmtitle parameter is required"> *** The message will be changed to "The cmtitle parameter is required" in early March (when cmcategory has been removed). The error code (cmnotitle) won't change. ** <error code="cmparam_category" info="Category name $1 is not valid"> was changed to <error code="cminvalidcategory" info="The category name you entered is invalid"> *** This error will also be thrown if cmtitle is a valid title but not in the Category: namespace. ** <error code="cmtitleandcategory" info="The cmcategory and cmtitle parameters can't be used together"> *** This error will be removed once cmcategory has been removed (in early March), because it won't make sense anymore at that time For extra clarity: this doesn't break any code *yet*. Users of list=categorymembers have until *early March* to update their code, after that code using the cmcategory will break. Roan Kattouw (Catrope) [1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=30533

1 0

Re: [Mediawiki-api] ATTENTION: query.php will be removed soon
by Yuri Astrakhan 04 Feb '08

04 Feb '08

Agree, backwards compatibility is important, but it has to be balanced with efforts required to maintain query.php.. Every db schema change must be looked at to see if query.php must be updated. Internal api changes may also impact its functions and performance. IIRC, there are already some queries not working as intended. At the very least, we can analyze web logs to see which query.php functions are being used, and disable the rest. There was logging functionality built into query.php, and the server should have an alternative log that could be grep-ed. Can a server admin look at that? Thx! On 2/2/08, Tim Starling <tstarling(a)wikimedia.org> wrote: > Yuri Astrakhan wrote: > > For those who use old query.php API interface: > > > > Per http://bugzilla.wikimedia.org/show_bug.cgi?id=12881 , query.php has > > been fully ported to the api.php, and thus no longer needed. Unless > > there are significant reasons to keep it around, it will be removed both > > from the extensions and from the mediawiki sites fairly soon. > > > > Isn't backwards compatibility enough of a reason? Surely it's a lot easier > to keep it around than to rewrite everything that uses it. > > -- Tim Starling > > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)lists.wikimedia.org > http://lists.wikimedia.org/mailman/listinfo/mediawiki-l >

2 1

PROPOSED BREAKING CHANGE: [Bug 12898] imageusage and categorymembers lack consistency
by Bryan Tong Minh 04 Feb '08

04 Feb '08

This change will break backwards compatibility, so I'm forwarding it to this mailing list. Bryan ---------- Forwarded message ---------- From: bugzilla-daemon(a)mail.wikimedia.org <bugzilla-daemon(a)mail.wikimedia.org> Date: Feb 3, 2008 9:47 PM Subject: [Bug 12898] imageusage and categorymembers lack consistency To: wikibugs-l(a)lists.wikimedia.org http://bugzilla.wikimedia.org/show_bug.cgi?id=12898 Roan Kattouw <roan.kattouw(a)home.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roan.kattouw(a)home.nl Status|NEW |ASSIGNED Summary|imageusage and |imageusage and |categorymembers lacks |categorymembers lack |consistency |consistency --- Comment #1 from Roan Kattouw <roan.kattouw(a)home.nl> 2008-02-03 20:47:51 UTC --- To clarify what might seem unclear to some: list=imageusage currently takes its iutitle parameter as Image:Example.jpg, while list=categorymembers takes its cmcategory parameter as Living_people (as opposed to Category:Living_people). The suggestion is that cmcategory be renamed to cmtitle and require the Category: prefix. I'll implement this when I get around to it. -- Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list Wikibugs-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikibugs-l

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api February 2008