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/m4021c1a7
And here is my model where the actual API calls are made:
http://pastebin.com/dd7c504c
The 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 list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Since people seem to think the bugs have been pretty well shaken out so
far on test.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.org
iEYEARECAAYFAkizOpUACgkQwRnhpk1wk46pMgCfRRkjRY4vUGAr3OGDzrAgyYN7
G70AoJwZr8RocLqVPiKVKztACTTYpKQ3
=GWoW
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As you may know, the current MediaWiki API was based on an earlier
interface, the BotQuery extension accessed via query.php.
During development of the new API, the old query.php was left in place
on Wikimedia's sites to provide backwards-compatibility for tools and
user scripts using it.
However it's a bit of a burden to keep it around -- being nearly
unmaintained it suffers from "bitrot":
* Queries sometimes break due to backend changes
* Security problems are sometimes discovered and must be patched
We've been reluctant to just turn it off since some user scripts still
use it (Lupin's Popups are rumored to be the most popular such), but I'd
like 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 scripts
to the current API ahead of time, or to start work on an adaptor to
replace query.php -- transforming queries to send them to the new API
and 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.org
iEYEARECAAYFAkiQ760ACgkQwRnhpk1wk46VGwCeOLp5Ynuw48ikLv8YztyB0kIc
eKoAnjPhey51pkojh7mTT4j7BYz95gYZ
=QZC+
-----END PGP SIGNATURE-----
'suppress' is listed as a potential letype for
http://en.wikipedia.org/w/api.php .
Although interestingly (or not) there is no 'suppress' log option at
http://en.wikipedia.org/wiki/Special:Log, and then again
http://en.wikipedia.org/wiki/Special:Log/suppress does give some
results, although it's not obvious what they are.
Also, it seems like api.php can figure out what the list of available
letype values are for each particular wiki, as I went to a different
wiki site's api,php and it correctly listed a different set of
possible values. Is that list accessible via an API call? It seems
like 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 two
revision IDs, get a diff-style output back. This is something that is
available through MediaWiki itself via the history page, but not the
API.
<http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Diff.php?vi…>
doesn't look like it is particularly straightforward to implement, and
rather than doing so, couldn't it be made available via the API?
Also... a 'diff view' would also be much more useful in the page
history feeds. As they stand now they seem quite useless to me.
Thoughts?
cheers
Brianna
--
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 list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
I'm having some problems which are caused by some inconsistent formatting
of results from the API in format JSON. This is making problems for a perl
module 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 is
how 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 pageid
being 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 in
a consistent manner (as with the XML).
Best Regards
Jools
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 errors
For 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…