New Features:
* list=search: Full text search has been added - both titles and
content are now search-able.
* list=allusers: Added groups - can be both filtered by a specific
group, and shown the groups the users belong to. (bug 10684 by
VasilievVV)
Breaking change:
* prop=revisions: I removed the redundant pageid= attribute in the
<rev> tag - pageid is already given as part of the parent <page>
element. (Thx Platonides)
Your help is still needed to improve documentation at
http://www.mediawiki.org/wiki/API - each function and parameter needs
better documentation, with many simple examples. There is a template
to help with the presentation.
As usual, if you notice any bugs -- http://bugzilla.wikimedia.org
Awaiting server sync for changes to go live.
--Yurik
I'm trying to use a single API call to generate information on
multiple revisions of pages that transclude another page.
The parameters I use are as follows:
action=query
prop=revisions
generator=embeddedin
geinamespace=2
geititle=user:Iron_Chicken/ToDo
rvprop=user|ids|comment
The url looks like this:
http://en.wikipedia.org/w/api.php?action=query&prop=revisions&generator=emb…
That's great but it only returns information about the latest revision.
So I look at the documentation for prop=revisions and add rvlimit=5
http://en.wikipedia.org/w/api.php?action=query&prop=revisions&generator=emb…
Oops, now I get the dreaded API documentation message.
Wassup?
The old style MediaWiki API (query.php) let me do
query.php?what=userinfo to see who I was logged in as (or my IP
address if I wasn't logged in).
What's the api.php equivalent of this functionality?
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
Hello,
Is there a way to just ask for the total number of revisions to a
given page, rather than actually retrieve the said revisions?
Maybe it could be part of the "prop=info" - "Get basic page information"?
thanks,
Brianna
Hello.
For the past 2 days I kept looking in the media wiki api, but could not find a solution for what I need.
I would like to use the api for searching articles containing certain word(s) in the title and/or in the body. All I could find is to use the opensearch (which is still a draft and there's no library out there). Can you help, please? for example how do I get an XML list of the articles containing "Europe" in the title? Or containing "tiger" in the body? Is this possible?
Many thanks,
Bogdan
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
After having much difficulty using the API classes from a programmatic
standpoint, I've summarized my complaints into bug 10602:
http://bugzilla.wikimedia.org/show_bug.cgi?id=10602
If you have any thoughts, please feel free to post a comment there. :)
-- Jim R. Wilson (jimbojw)
Hi,
I'm not sure if this idea is even reasonable, but let me try it out anyway.
It would be cool if a wiki's users (probably admins) were able to
define stuff to be part of the API. (Actually I'm thinking more of
being able to define custom RSS feeds, but they're somewhat similar
ideas, I think.)
Two typical examples would be page of the day and image of the day.
Wikimedia wikis already have systems set up so that (e.g.)
[[template:potd]] automatically shows that day's 'picture of the day'
(by parser functions).
Maybe the API could read a page [[MediaWiki:Custom API]], whose
contents could be like this:
---------------
* [[template:potd|dailyimage]]
* [[template:today's featured article|dailyarticle]]
---------------
so then maybe API users would be able to do
api.php?what=customapi&title=dailyimage
and they would get the content of [[template:today's featured article]].
I don't even know if this is even remotely feasible, but it would be
super cool if it was.
cheers
Brianna
A few recent changes, hope it was in time for MediaWiki 1.11 release:
* list=logevents updated - more event type decoding, leprop= allows to
specify exactly what data is needed. log_id is now exposed. Some
result might be different than before. This list needs some feedback
and attention.
* userCanRead() has been removed everywhere - now API will work for
the users that have read permissions for the entire wiki (see
$wgGroupPermissions variable settings at
http://www.mediawiki.org/wiki/Manual:$wgGroupPermissions ).
userCanRead() will still be called when requesting page content.
* API no longer checks for the maximum upper limit restrictions when
calling api internally
* rc_id is exposed in list=recentchanges requests
--Yuri
Hi all,
I'd really like to see a CLI version of the api.php that doesn't have any
limits on volume of output (since it's CLI, it's assumed to be trusted).
This would be incredibly useful for various types of dumps and statistics
gathering. Your thoughts?
-- Jim R. Wilson (jimbojw)
Oups,
sorry for the mess. I thought I'm sending last one to the list.
>> > There probably should be an extra function in main to generate
>> output
>> > for a given format in addition to $api->getResultData() :
>> > $api->getFormattedResult($format)
>>
>> This would be a very usefull method.
>>
>> Or better - let API return a description what has been returned.
>> getResultDescription, twin brother to getParamDescription?
> Why would api describe what it has returned?? The requestor better
> know what it asked for :).
Two scenarios:
- flash widget as a "multi-purpose" client. User can ask for several
things.
- multi api call. User asks for eg. recent changes but from more than
one wiki. If they run different MW codebase results will have
slightly different form.
Btw. api.php?action=query&meta=siteinfo&siprop=apiversion would be
usefull as well as with different MW even calls have different params,
przem.