I need some help - I've implemented the API using CodeIgniter for a clients site and everything works on the site except for the wiki pages, which are sluggish.Here is my controller which lists the function calls being made and in what order:http://pastebin.com/m4021c1a7And here is my model where the actual API calls are made:http://pastebin.com/dd7c504cThe api.php file exists on the same server that is making the calls, so it should be instant but the pages are so very slow, and only in the instance of using the MW API.Any help or insight anybody could give would be MUCH appreciated.- Mark
For consistency, prop=categories&clprop=timestamp now returns timestamps in ISO 8601 format (e.g. 2008-08-23T18:05:46Z) rather than MediaWiki's internal timestamp format (e.g. 20080823180546) as of r40161 [1]. All timestamps that the API outputs are now in ISO 8601 format.Roan Kattouw (Catrope)[1]http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=40161_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1Since people seem to think the bugs have been pretty well shaken out sofar ontest.wikipedia.org, I've gone ahead and turned on$wgEnableWriteAPI on all public Wikimedia wikis.Let's see how well stuff works! :D- -- brion-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.8 (Darwin)Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.orgiEYEARECAAYFAkizOpUACgkQwRnhpk1wk46pMgCfRRkjRY4vUGAr3OGDzrAgyYN7G70AoJwZr8RocLqVPiKVKztACTTYpKQ3=GWoW-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1As you may know, the current MediaWiki API was based on an earlierinterface, the BotQuery extension accessed via query.php.During development of the new API, the old query.php was left in placeon Wikimedia's sites to provide backwards-compatibility for tools anduser scripts using it.However it's a bit of a burden to keep it around -- being nearlyunmaintained it suffers from "bitrot":* Queries sometimes break due to backend changes* Security problems are sometimes discovered and must be patchedWe've been reluctant to just turn it off since some user scripts stilluse it (Lupin's Popups are rumored to be the most popular such), but I'dlike 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 scriptsto the current API ahead of time, or to start work on an adaptor toreplace query.php -- transforming queries to send them to the new APIand transforming the results back to a format compatible with the old one.- -- brion vibber (brion @wikimedia.org)-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.8 (Darwin)Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.orgiEYEARECAAYFAkiQ760ACgkQwRnhpk1wk46VGwCeOLp5Ynuw48ikLv8YztyB0kIceKoAnjPhey51pkojh7mTT4j7BYz95gYZ=QZC+-----END PGP SIGNATURE-----
'suppress' is listed as a potential letype forhttp://en.wikipedia.org/w/api.php .Although interestingly (or not) there is no 'suppress' log option athttp://en.wikipedia.org/wiki/Special:Log, and then againhttp://en.wikipedia.org/wiki/Special:Log/suppress does give someresults, although it's not obvious what they are.Also, it seems like api.php can figure out what the list of availableletype values are for each particular wiki, as I went to a differentwiki site's api,php and it correctly listed a different set ofpossible values. Is that list accessible via an API call? It seemslike something that would fit under "siteinfo".thanks,Brianna-- They've just been waiting in a mountain for the right moment:http://modernthings.org/
Hi,Is it possible the API could provide diffs? Ie you provide tworevision IDs, get a diff-style output back. This is something that isavailable through MediaWiki itself via the history page, but not theAPI.<http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Diff.php?vi…>doesn't look like it is particularly straightforward to implement, andrather than doing so, couldn't it be made available via the API?Also... a 'diff view' would also be much more useful in the pagehistory feeds. As they stand now they seem quite useless to me.Thoughts?cheersBrianna-- They've just been waiting in a mountain for the right moment:http://modernthings.org/
This change only affects clients using the JSON, PHP, WDDX, PHP, TXT and DBG formats. If you're using the XML or YAML formats, nothing will change for you.The list=backlinks, list=embeddedin and list=imageusage used to return arrays with pageIDs as keys, duplicating information (those arrays also contain the pageID). An example (in JSON):{"query": {"backlinks": {"1024": {"pageid": "1024","ns": 1,"title": "Talk:Anarcho-capitalism"},"1236": {"pageid": "1236","ns": 1,"title": "Talk:Algorithm"}}}}After a complaint [1] about this behavior, it was changed in r39645 [2]. Like all other list= modules, backlinks and friends now return arrays with 0, 1, 2, etc. as keys. In JSON this looks like:{"query": {"backlinks": [{"pageid": "1024","ns": 1,"title": "Talk:Anarcho-capitalism"},{"pageid": "1236","ns": 1,"title": "Talk:Algorithm"}]}}Roan Kattouw (Catrope)[1]http://lists.wikimedia.org/pipermail/mediawiki-api/2008-August/000657.html[2]http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=39645_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
I'm having some problems which are caused by some inconsistent formattingof results from the API in format JSON. This is making problems for a perlmodule I made.Take this example:http://en.wikipedia.org/w/api.php?action=query&list=categorymembers&cmtitle…results are returned in an array and so are easy to loop through. This ishow most of the results are formatted from the "list" query types.now take this one:http://en.wikipedia.org/w/api.php?action=query&list=backlinks&bltitle=Main%…the results are not in an array but a hashref of hashrefs with the pageidbeing the key (and the page id is also in the hashref too)Is this a bug, or could this be changed so that the api returns results ina consistent manner (as with the XML).Best RegardsJools
MediaWiki 1.13.0 is now available [1].Selected changes to the API since 1.12.0:* action=edit has been added. Note that $wgEnableWriteAPI = true; is required for this.* list=allimages and prop=categoryinfo have been added.* The blredirect, eiredirect and iuredirect (for list=backlinks, list=embeddedin and list=imageusage) have finally been implemented. Setting these parameters will list links through redirects as well.* Paging (i.e. limit and continue parameters) have been added to prop=links, prop=templatelinks, prop=langlinks, prop=extlinks, prop=categories and prop=images. These modules no longer return all results by default, but only the first 10 (like list= modules do).* Invalid titles no longer throw errors but are listed as invalid instead.* Invalid values for multivalue parameters now throw warnings instead of errorsFor a full list of changes to the API, see the section "API changes in 1.13" in the MediaWiki 1.13.0 release notes [2].Roan Kattouw (Catrope)[1]http://lists.wikimedia.org/pipermail/mediawiki-announce/2008-August/000076.…[2]http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_13_0/phase3/RELEASE-NO…