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
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
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
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
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
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
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
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
>
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