API talk:Main page/Archive 1

Suggested API 27 April 2006
I was not able to find a list of suggested API functions for retrieving Information via SOAP/WHATEVER. If you find one that already exists, please delete this page. If you consider meta inappropriete for this kind of page, please delete it. Or move it to my user name subpage. If you feel offended by the pseudo-syntax or naming of these functions, alter them unless they are beyond repair. Thanks.

Articles

 * article_mw ( string lemma )

article_mw returns a single article from a wiki in the original Mediawiki syntax


 * article_xml ( string lemma )

article_xml returns a single article from a wiki in xml output


 * article_section_mw ( string lemma, int section)

returns a single section from a single article from a wiki in the original mediawiki syntax. section is the same as section in the edit option

Search

 * list of articles that contain string query
 * size of an article (chars, bytes, words)
 * list of authors of an article (ugly to compute when it comes to articles with 1000+ revisions)

API?
What about telling the unfamiliar what API actually is? The page doesn't make much sense without knowing that beforehand… Jon Harald Søby 17:42, 30 October 2006 (UTC)
 * Added links. Feel free to add/change the page to make the information better. Thx. --Yurik 19:38, 31 October 2006 (UTC)

User preferences options
I tried to download User.php in order to view the uioptions, but I cannot locate the file starting from http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/BotQuery/. Is it within svn.mediawiki.org ?

Secondly, I compared the some uioptions identifiers to the WP user preferences identifiers (). They do not match (e.g., timecorrection vs wpHourDiff). It would be nice to use the same identifiers.

Regards, Sherbrooke 12:48, 8 October 2006 (UTC)


 * User.php is located in /phase3/includes. The useroption name is the same as used internally in the database, and is constant across all wikies. --Yurik 19:19, 8 October 2006 (UTC)

Category belonging to an article
Actually query.php can't get category in a redirect but there is sensible use of such categorized redirect e.g. original book's titles is a redirect to the local book's title and can be categorized. It'll nice if api.php solve this problem. Phe 15:37, 18 October 2006 (UTC)
 * Afaics fixing it in query.php seems not difficult, in genPageCategoryLinks use $this->existingPageIds instead of $this->nonRedirPageIds but I'm unsure if it'll break existing bot... Phe 15:42, 18 October 2006 (UTC)
 * Added in the new api. --Yurik 06:32, 14 May 2007 (UTC)

How to retrieve the html format?
I am interested in retrieving a formatted html version of the content of an article, with the links parsed and pointing to wikimedia pages, but without tabs, menu options, etc. The article as you can see it inside wikipedia.--Opinador 11:26, 5 November 2006 (UTC)
 * The easiest way would probably be to add action=render to the regular wiki request: http://en.wikipedia.org/w/index.php?title=Main_Page&action=render. I plan to add it to the API, but it will not happen soon - currently the internal wiki code is not very well suited for this kind of requests. --Yurik 16:17, 6 November 2006 (UTC)
 * Thank you, I think is enough for me at this moment. But probably it will be useful to have in API this aproach, or at least to have a parameter to force expand templates before returning the page results.--Opinador 10:26, 7 November 2006 (UTC)

Formatting bug
When I call the API with "action=opensearch", it will only return results in the JSON format. It doesn't matter what the search term is or what I pass to the format argument. Forgive me if this isn't the proper place to report a bug like this. 68.253.13.166 20:14, 3 February 2007 (UTC)


 * Bug 9143] is tracking this, and has been postponed. It has more details. --Yurik 02:01, 22 May 2007 (UTC)

feedwatchlist bug
Even after successfully logging in with "action=login", if we don't use cookies but rather pass the lgusername, lguserid and lgtoken returned as parameters along with "action=feedwatchlist" then we get a HTTP 500 error ( tried this with http://en.wikipedia.org/w/api.php just now). The documentation says that both parameters and cookies should work. Jyotirmoyb 05:52, 20 February 2007 (UTC)
 * If you are trying to reproduce this bug with a browser, make sure to clear the cookies set by a successful login. Jyotirmoyb 05:55, 20 February 2007 (UTC)
 * Is it normal behaviour that watchlist topics appear approx. 1 day late? Thanks, 84.160.6.41 21:05, 9 March 2007 (UTC)
 * Both issues has been fixed -- Err 500 now returns "not logged in" feed element, 1 days has been fixed. --Yurik 02:02, 22 May 2007 (UTC)

ApiQuery
There should be possibility of registering methods in $mQueryListModules, $mQueryPropModules and $mQueryMetaModules for example by settings variables in LocalSettings.php:

$wgApiQueryListModules["listname"] = "ApiQueryMethodName";

and then in ApiQuery.php something like:

83.12.240.122 15:39, 15 March 2007 (UTC) Krzysztof Krzyżaniak (eloy) 


 * Thanks, done. --Yurik 03:28, 15 May 2007 (UTC)

JSON Callback
It would be really nice if the api had a JSON callback, à la Yahoo Web Services. This way, any website could make an AJAX request to Wikipedia! --Bkkbrad 17:16, 26 February 2007 (UTC)
 * Done. --Yurik 18:45, 15 May 2007 (UTC)
 * Fantastic -- thanks! --Bkkbrad 16:12, 8 November 2007 (UTC)

YAML Formatted Errors
I'm working on writing some methods to access the API, requesting my results in YAML format. It works fine when I send a proper request, which is most of the time, but occasionally I do something wrong and get the helpful error message. However, on having my code process the YAML result, I'm getting an error. Specifically, it reports "ArgumentError: syntax error on line 12, col 2: ` For more details see API'" Is this because the result is not properly formatted YAML, or a Ruby error? I don't know very much about YAML, learning as I go along, but I like the format so far. Is anyone else having this issue, and is it an issue at all? Thanks. Eddie Roger 04:21, 21 February 2007 (UTC)
 * Is it still broken? --Yurik 02:04, 22 May 2007 (UTC)

Broken POST?
I just downloaded 1.9.3 to a new dev box of mine, and my scripts seem to have all broken due to a problem with POST. I've switched to GET to test this, and it works fine, but when POSTing, I get the generic help output and not the YAML results I expect. Did someone change something with the latest release? Eddie Roger 03:04, 21 March 2007 (UTC)


 * Bump? Anyone? I've kept playing with this with no luck. Can anyone at least point me towards the source file that is responsible for returning the results or handling POST requests?


 * Update: Sorry, Ruby was broken, not MediaWiki. Ruby 1.8.4 had a bug in its post method. Upgrading fixed. Hope that helps someone.

external Weblinks
Hi all, API is really practical, but I miss a list of all external weblinks from a page. In de:Spezial:Linksearch all weblinks of a page are probably listed, api could only display the list..?--Luxo 20:42, 20 March 2007 (UTC)
 * done. --Yurik 02:04, 22 May 2007 (UTC)

Watchlist not working any longer?
Hi Yuri. It seems that the watchlist feature of api.php is not working any longer :-( . It is not even listed in the help! I went to svn, but I don't see any recent change that justifies the change. Tizio 14:33, 2 April 2007 (UTC)
 * Ops, just found this: . Sorry for the duplicate. Tizio 14:39, 2 April 2007 (UTC)


 * Domas removed it because it "failed to conform to db standards" and advised developers to "just use Special:Watchlist", which sucks, but sobeit. Unless it is completely rewritten to conform to db standards (not use the master db, but instead use that dedicated to watchlists, etc.), it will be gone. AmiDaniel 18:16, 2 April 2007 (UTC)
 * Nuts, it was soooo useful :-( Especially on a slow connection, the difference is really evident. Tizio 15:04, 3 April 2007 (UTC)


 * I changed the DB group being used. Unless there is another issue with the query, we should get someone to reinstate it. --Yurik 03:29, 15 May 2007 (UTC)


 * Thanks!!!! (as I said, that was really useful; as the rest of the API, btw). Tizio 12:03, 19 May 2007 (UTC)

Changes in revision query
Was there a recent change in the way revision queries are processed? It seems like the revision ids are no longer returned automatically whereas before they were and api.php still claims they are. Also, it seems oldid (i.e. the previous revision's ID) is no longer returned and there's no way to enable that option within the query. Any pointers how I can get that information? Sebmol 05:52, 22 May 2007 (UTC)
 * How can we get the revision ids ? --NicoV 07:49, 22 May 2007 (UTC)
 * Because not everyone needed the IDs, they have been added to the list of available properties. To get them, simply include "ids" as one of the rcprop values |Main%20Page&rvprop=ids|timestamp|user|comment. Both pageid and revid are there. Sorry, but i had to make this change to make it cleaner. --Yurik 21:04, 22 May 2007 (UTC)
 * Ok, thanks. --NicoV 21:36, 22 May 2007 (UTC)

Feature request for links
Would it be possible to have an option on the "links" request to filter out links that are imported by templates ? I am currently working on a tool to help fixing links to disambiguation pages, and I'd be interested in getting only the links that are directly in the page.

This request could probably also be applied to other functions (templates, extlinks, ...).

PS: Thanks for the API --NicoV 21:36, 22 May 2007 (UTC)


 * It might be possible, but I am afraid this might be a bit complex: the api would have to enumerate recursively every template used by the pages, and subtract all links found in templates from those on the page itself. The problem is that all links from the template pages will be found, not just those included in other pages (&lt;includeonly>, etc). Plus some links might appear both on the page and in a template, and doing this will eliminate them.
 * The real solution would be to add a bit flags (short int) field to the pagelinks table to record during page save/update what links are real and what links come from templates. --Yurik 03:11, 23 May 2007 (UTC)

Changes to redirects
Have there been any changes to redirects? Since a few days, querying for content revisions no longer seems to automatically redirect when using &redirects. Thanks for the API! Tom De Smedt
 * Shouldn't be. Please provide an example of the broken URL request. --Yurik 18:47, 25 May 2007 (UTC)
 * Yurik, here is an example request: http://en.wikipedia.org/w/api.php?action=query&redirects&format=xml&prop=revisions&rvprop=content&titles=wolf - this query used to return the content of the "Gray wolf" article, but now returns a redirect page. --Tomdesmedt 18:59, 27 May 2007 (UTC)
 * Thanks, fixed in r22502. --Yurik 08:06, 28 May 2007 (UTC)
 * OK, works fine now! Thanks again for the API --Tomdesmedt 12:00, 29 May 2007 (UTC)

List members of a category (list=categorymembers)
This doesn't seem to be implemented yet, but it works (mostly) in query.php. Is there a ETA for it to move here? I spoke with Yurik this afternoon about a bug in query.php. Carl CBM 22:05, 4 June 2007 (UTC)
 * Considering that Yurik is the only one implementing it, and he is extremely busy with his primary work... Probably soon :) --Yurik 23:50, 4 June 2007 (UTC)
 * I posted here mostly to leave a record of the conversation. I wasn't sure if there is a deployment plan for the new API, but it looks like there isn't. In the meantime, there are still the various libraries that do it by screen scraping. CBM 18:43, 5 June 2007 (UTC)
 * Not sure what you mean by deployment -- it is deployed on all WikiMedia servers, and is part of the normal distribution. It is disabled by default, but can easily be enabled with a small configuration change. Libraries really ought not to do the screenscraping -- simply because HTML changes very often (by far more often than the API specs :)) --Yurik 03:57, 6 June 2007 (UTC)
 * I meant the timeline for the full implementation of API.php, sorry. I agree that screenscraping is a method of last resort. CBM 03:43, 7 June 2007 (UTC)
 * done. --Yurik 10:55, 17 June 2007 (UTC)

Whitespace in front of XML declaration
I've noticed that my mediawiki site has a space in front of the xml declaration (for format=xml) which royally jams up every xml reader there is. This doesn't seem to happen on the wikipedia website, but I can't find a bug for it or where the space comes from. And my version is new (literally a week old). Anyone know of this bug and how to fix it w/o a hack? If not, is there any way to overload the output functions and print where they are coming from?
 * Check LocalSettings.php for byte-order marks and other whitespace at the top of the file (above ). You can remove the ?> at the bottom if present, since it's not needed. Also check extension files. robchurch | talk 00:36, 22 June 2007 (UTC)
 * Yeah I had that problem on our wiki's too and finally tracked it down to whitespace after the ?> on the end of a number of extension's php files. --Nad 10:27, 22 June 2007 (UTC)

namespace select with list=usercontrib
Is it possible to add an option to choose which namespaces to use when list=usercontrib? i.e. that |3 this link will work. Yonidebest 21:00, 30 June 2007 (UTC)
 * Done in r23741. --Catrope 15:17, 5 July 2007 (UTC)
 * Thanks! Yonidebest 15:21, 5 July 2007 (UTC)

Silent normalization of interwiki titles
See Bug 10147.
 * Fixed. --Yurik 07:42, 6 July 2007 (UTC)

InterWiki table
Would it be possible to implement retrieval of the InterWiki table through something like this? api.php?action=query&meta=siteinfo&siprop=interwiki I'm currently working on a Recent Changes enhancement, and need to parse wikicode inside comments. Luckily, comments only allow very little wikicode, but I still need to parse InterWiki links. is not guaranteed to work for all InterWiki bindings (more exactly, it doesn't work if iw_local=0 for that binding), so that's not a good solution. Also, I need to place IW links in a different CSS class, and I can't do that if I can't tell IW from internal links.

Thanks in advance. --Catrope 20:16, 31 May 2007 (UTC)


 * Sounds quite do-able to me -- only problem is that interwiki tables tend to be quite obscenely large, and so we may have to split up the returns. Please add a bug to http://bugzilla.wikimedia.org where it's much more likely to be acted upon :). Thanks. AmiDaniel 08:33, 1 June 2007 (UTC)
 * Posted, thanks for the link. --Catrope 13:29, 1 June 2007 (UTC)
 * done. --Yurik 07:46, 6 July 2007 (UTC)

possible category problem
Hi, using the API on large categories gives me less results than it should, see en:Category:Uncategorized from September 2006 for example. My program using queri API reports 4712 articles, when there are actually over 5000 articles in that category. I have tested my software, and I don't see that it is doing anything wrong, and indeed works perfectly on smaller categories, though I still don't rule out that I am at fault. I would be greatful if someone could use their queri API software on that category and see how many results they are given. thanks Martin 09:57, 17 September 2006 (UTC)


 * Using the C# example from the en user manual gives even less results, so I think something somewhere is going wrong with large cats. Martin 09:51, 18 September 2006 (UTC)


 * Hi Martin, I will take a look in the next few days. Thanks for reporting. --Yurik 13:35, 18 September 2006 (UTC)
 * Yurik fixed a related bug in queryapi.php a few days ago. Phe 15:33, 18 October 2006 (UTC)
 * Tried in api - seems to be working fine. --Yurik 09:37, 8 July 2007 (UTC)