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
Currently, when you specify not titles parameter for queries that
require it, such as http://en.wikipedia.org/w/api.php?action=query&prop=info
you get an empty result set:
<?xml version="1.0" encoding="utf-8"?>
<api />
Wouldn't it be more beneficial to return error in such cases, or at
least to provide a notice that there is noting to query from?
--
Max Semenik ([[User:MaxSem]])
API is intended for bots, not humans. Making it accept anon edits just
allows bots to edit accidentally logged off. And the AssertEdit
extension doesn't seem to work for API. What can be done about this?
Simply adding an AlternateEdit hook call to ApiEditPage leads to ugly
HTML output.
--
Max Semenik ([[User:MaxSem]])
On 25.05.2008, 22:20 Bryan wrote:
>>>> I think I added that hook on the wrong place. It should probably
>>>> somewhere after the title has been set.
>>>>
>>>> Bryan
>>>>
>>> ...or not. It appears that the error occurs because $wgTitle is not
>>> set. It should probably be set to something sensible or $wgOut should
>>> be set to a fake object that does nothing.
>>
>>> Bryan
>>
>> Probably, something like FauxOutputPage should relly be made, but it
>> would add extra time to load it and actual OutputPage from which it
>> will inherit. So my proposed patch modifies AssertEdit's behaviour to
>> depend on entry point and not to output anything if it's called from
>> API.
>>
>> --
>> Best regards,
>> Max Semenik ([[User:MaxSem]])
>>
>>
> Thanks for the patch, but I don't really like how it depends on
> $GLOBAL['processor'] to check whether we are running through the api.
> There should be a more sane way to detect runnage via the API and if
> there is not, it really should be made.
> Bryan
How about define( 'API' ); in api.php just before constructing
ApiMain?
--
Best regards,
Max Semenik ([[User:MaxSem]])
In the spirit of yesterday's breaking change, here's another one. As of
r35140 [1], requesting e.g. a move token while you're not allowed to
move pages* will no longer exit with an error, but throw a warning
instead and give you a result set without the move token. An example:
api.php?action=query&prop=info&intoken=edit|delete|protect|move&titles=Main_Page
(made by an anonymous user)
<?xml version="1.0" encoding="utf-8"?>
<api>
<query>
<normalized>
<n from="Main_Page" to="Main Page" />
</normalized>
<pages>
<page pageid="98" ns="0" title="Main Page" touched="2008-05-09T09:25:47Z" lastrevid="485" counter="6" length="149" edittoken="+\" />
</pages>
</query>
<warnings>
<info>Action 'protect' is not allowed for the current user
Action 'move' is not allowed for the current user
Action 'delete' is not allowed for the current user</info>
</warnings>
</api>
* NOTE: This only applies to the 'move' permission in general, NOT to
limitations on individual pages (immobile namespace, page protected,
etc.). Because of this, the fact that prop=info gives you a move token
just means that you have the 'move' right, NOT that you'll actually be
able to move that particular page.
Roan Kattouw (Catrope)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=35140
As of r35104 [1], the handling of invalid value for multivalue
parameters has changed. If the API encounters an invalid value, it
doesn't exit with an error like it used to, but throws a warning and
ignores the invalid value. Handling of single value parameters hasn't
changed: the API still exists with an error when that happens. Note that
one letter in the associated error message *has* changed, recogniSed has
been changed to recogniZed (shouldn't matter much as you should go by
the error code rather than the info text anyway, it's much shorter).
Also note that multiple warnings may occur for the same module, in which
case the two warnings are separated by a newline (r35107 [2]). This is
also demonstrated in example 1.
This behavior may cause unexpected behavior when misspelling parameters:
rather than an error, you'll get a result which omits an entire element
completely. Your result might even be empty apart from the <warnings>
element. The advantage is that requesting a property that was added in
1.14 won't break on 1.13 (I'll suggest backporting this fix for that
reason).
Two sample requests:
api.php?action=query&meta=siteinfo|foo&siprop=dbrepllag|bar|baz&prop=blah
<?xml version="1.0" encoding="utf-8"?>
<api>
<warnings>
<query>Unrecognized value for parameter 'prop': blah
Unrecognized value for parameter 'meta': foo</query>
<siteinfo>Unrecognized values for parameter 'siprop': bar, baz</siteinfo>
</warnings>
<query>
<dbrepllag>
<db host="" lag="-1" />
</dbrepllag>
</query>
</api>
api.php?action=query&prop=revisions&rvdir=foo
<api>
<error code="rvunknown_rvdir" info="Unrecognized value for parameter
'rvdir': foo"/>
</api>
Roan Kattouw (Catrope)
Hello,
I think we should start to maintain older versions of the API. I have
therefore added a new page on MediaWiki wiki:
<http://www.mediawiki.org/wiki/API:Backporting>. I have started by
adding fixed bugs from RELEASE-NOTES to the page. I will probably
start the backporting once I have time to find out how subversion's
merge functions work. Feel free to add and remove items to that page
or to start backporting yourself.
Bryan