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.
Hello,
Limited category intersection as part of the API would be extremely
useful for wikis with overlapping categories. I discussed this on IRC
with Simetrical, and it seems that limiting intersection to categories
of 5000 or less members each should not use excess resources for a bot
API (although benchmarks would be needed).
PHP intersection of very large categories took me less that one second
(with longer times to retrieve category members before intersection)
using a PHP script. It should be faster in SQL, since it retrieves and
intersects simultaneously.
The SQL query itself should be relatively simple. The URL query might
look something like the following, which would also make union (list
of all pages in either category) possible by changing &return.
http://en.wikisource.org/w/api.php?action=query&list=categorymembers&cmprop…
Does this seem feasible? I could try my hand at coding it if nobody
else will, but I have only a patchwork knowledge of PHP and SQL.
Yours cordially,
Jesse Martin (Pathoschild)
Hello and welcome to the new API list.
The new version of the API is now up on all WikiMedia sites, e.g.
http://en.wikipedia.org/w/api.php
== Breaking Changes ==
backlinks, embeddedin, and imageusage lists no longer use the global
"titles=" parameter; instead backlinks now uses bltitle=, embeddedin
-- eititle=, and imageusage -- "iutitle=".
For a little while, if you do not supply ...title= parameter,
titles= will still work, but a warning is returned. Soon it will not
work, so please update your code if you use any of this 3 lists.
== New Features ==
* list=categorymembers - list pages/categories belonging to a category
* page protection status
* prop=imageinfo - returns image info including repository, size,
URLs, and upload history
* list=exturlusage - search for URLs used in a wiki
* list=alllinks - list all links, regardless of what page they are on
(allows search for unique links only )
* list=allusers - list of all users registered in a wiki, together
with an edit count
* prop=siteinfo - can now return database servers replication lag
== Other Changes ==
* Documentation has been significantly updated with examples. Please
contribute more :) : http://www.mediawiki.org/wiki/API
* Report bugs & post requests are at
http://bugzilla.wikimedia.org/buglist.cgi?component=API&bug_status=NEW&bug_…
(don't forget to set Component=API when creating new entries)
== Current Issues ==
* Security: If a namespace cannot be read by the current user, some of
the titles in that NS are still shown in various enumerations (e.g. in
the apfrom= continue value)
== Current Efforts ==
* Some core code has been updated to allow Rollback implementation
(thanks Roan).
* API home page needs short coding examples of client access for
Python, PHP, C#, and Java clients (or any other languages if you
prefer). Older examples are at
http://en.wikipedia.org/wiki/User:Yurik/Query_API/User_Manual#Usage
Hi,
What is the format of timestamps and how can ordinary times be
converted to them?
for example
lestart - The timestamp to start enumerating from.
leend - The timestamp to end enumerating.
I tried this:
http://en.wikipedia.org/w/api.php?action=query&list=logevents&lestart=20070…
attempting "200701310001" to mean "2007-01-31, 00:01"
but the results say
<api>
<query-continue>
<logevents lestart="20070709042252" />
</query-continue>
I had a bit of a look at the api code and found reference to TS_UNIX
and TS_MW, and I had a look at wfTimestamp, but it's all a little bit
too terse for me to figure out what's going on.
I took a guess and used this site
http://www.onlineconversion.com/unix_time.htm to convert my time to a
unix timestamp, and lo & behold, the API worked. :)
So are we supposed to convert their timestamps to unix timestamp
format before they use api.php? Or is there a "human readable" way?
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Hi,
IMHO the function that is missing the most in api.php is image
properties (width, height, size, media type, etc); the equivalent of
imageinfo on query.php.
When this is added, it might be nice to get information about the
thumbnail name as well, with a placeholder for the thumbnail width.
Also, one might want to think of making "file" an equivalent to
"image", so that "image" can be abolished later. Finding oggs in your
"image" list can be quite surprising otherwise :-)
So far my list of demands to be solved today ;-)
Cheers,
Magnus