Noticed something today, when someone asked me how to use the API to
login... The docs at http://en.wikipedia.org/w/api.php (just for
instance, I know it generally run the latest) say:
* action=login (lg) *
This module is used to login and get the authentication tokens.
In the event of a successful log-in, a cookie will be attached
to your session. In the event of a failed log-in, you will not
be able to attempt another log-in through this method for 5 seconds.
This is to prevent password guessing by automated password crackers.
Parameters:
lgname - User Name
lgpassword - Password
lgdomain - Domain (optional)
Example:
api.php?action=login&lgname=user&lgpassword=password
Probably should remove the "example" link and specify that it only works
via HTTP POST now :) As:
<?xml version="1.0" encoding="utf-8"?>
<api>
<error code="mustbeposted" info="The login module requires a POST
request">
Thanks!
SQL
I don't know if others run in to this situation, but I'll throw this
idea/request out there and see what folks think.
A lot of what I use the API for is for WikiProjects. As such, I'm often
getting a list of pages by looking for a project template, which is on the
talk page. Then I have to turn that around and get the actual articles from
main-space.
So I was wondering about way to get the "switch" of a page id. The two
possibilities I thought of are:
action=query&prop=info&inprop=talkid&pageids=15580374
action=query&prop=revisions&titles=Talk:Main%20Page&rvprop=mainid
Either one would take a page or set of pages and return either the talk page
id or the mainspace id.
Is this something that's doable? Desired? Thoughts?
--Ian
--
----------------------------
Ian Cabell
RadiantWeb Services
( 877 ) 406 - 6272 [toll free]
ian.cabell(a)gmail.com
http://www.radiantweb.net
"There is more than one right way .. to make it perfect!"
Hi,
This example of API use is given -
api.php?action=query&list=allimages&aisha1=123abc
I couldn't find any documentation on allimage or aisha1 in the
auto-generated documentation or on mediawiki.org . Would anyone in the
know mind writing up a working example? :)
thanks,
Brianna
---------- Forwarded message ----------
From: bugzilla-daemon(a)mail.wikimedia.org <bugzilla-daemon(a)mail.wikimedia.org>
Date: 19 Mar 2008 23:30
Subject: [Bug 1459] search for images/files by hash
To: brianna.laugher(a)gmail.com
https://bugzilla.wikimedia.org/show_bug.cgi?id=1459
Roan Kattouw <roan.kattouw(a)home.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roan.kattouw(a)home.nl
--- Comment #5 from Roan Kattouw <roan.kattouw(a)home.nl> 2008-03-19
12:30:53 UTC ---
(In reply to comment #4)
> I have the vague recollection that there's a way to do lookups
> by hash in the API, but not in the UI at present.
>
api.php?action=query&list=allimages&aisha1=123abc
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are a voter for the bug.
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
There was recently a brief discussion on the enwiki technical village
pump about the following issue, where Tim Starling suggested this should
be fixed in the API [1]. I want to mention it here before filing a bug.
It's already known among the developers that there can be obsolete
entries in the page table. One of these at the moment is pageid 414115
on enwiki, the article [[/.]], which has an illegal title. Unsurprisingly,
when that page was last edited, it was a redirect to [[Slashdot]].
If I fetch the list of backlinks to [[Slashdot]] using the API, I get
that page among the results. If I then try to fetch the page content for
it (using action=query and prop=revisions) the API returns a bad title
error ('invalidtitle'). This is of course a bad situation for people
using the API.
Strangely, I can get the content of that page using a generator query [2].
- Carl
1. http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technic…
2. http://en.wikipedia.org/w/api.php?action=query&generator=backlinks&gblfilte…
The parameters are:
( 'action' => 'query',
'generator' => 'backlinks',
'titles' => 'Slashdot',
'gblfilterredir'=> 'redirects',
'prop' => 'revisions',
'rvprop' => 'ids|user|comment|content' );
In r31865 [1], the section parameter was added to the action=edit API
module. Since its usage is not what you might expect in some cases and
the documentation is grossly out of date (I intend to work on bringing
all of that up to date later), I'll post some usage notes here.
Existing sections can be edited by setting e.g. section=3 . This will
edit the third section from the top (subsections, sub-subsections, etc.
also count). The top section (the part before the first section header)
can be accessed through section=0 . The content of a section cannot be
retrieved from the API right now (I intend to implement rvcontentsection
later), so you have to be careful here: a section consists of:
* the header (don't forget that one, or you'll merge the section with
the one right above it)
* the section content (duh)
** which includes ALL SUBSECTIONS
To clarify the latter: section number 3 in [2] is just the February
section, whereas section number 1 includes sections 2 through 14 (!).
The regular user interface also displays this behavior [3].
New sections can be added by setting section=new . In this case, you
should NOT add a section header, it will be added for you. The section
header text (without the = symbols) should go in the summary parameter.
For example:
api.php?action=edit&title=Talk:Foo§ion=new&summary=Hello&text=Hello%20world
will create a new section called "Hello" with "Hello world" in it.
Compare this interface to the regular section edit form [4] in which you
also have to enter the section title in a separate textbox.
If you set the section parameter when creating a page (editing a
nonexistent page), it'll be ignored unless it's 'new', in which case
it'll behave as if you're adding a section to an empty page (the UI does
that as well). If you set the section parameter to a string other than
'new', you'll get an error message. If you set the section parameter to
a negative integer (e.g. -3), it'll be ignored and you'll end up EDITING
THE ENTIRE PAGE. If you set the section parameter to a number larger
than the number of section on the page, you'll get a successful result
with the 'nochange' attribute set, e.g.:
<edit result="Success" pageid="77" title="Talk:Foo" nochange="" />
which essentially means your edit was ignored because it would change
anything. Of course, this doesn't have to mean you tried to edit a
nonexistent section: someone else could've changed exactly the same
thing, or you could've forgotten to actually change anything.
I hope this clarifies some things that may be unintuitive at first.
Roan Kattouw (Catrope)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31865
[2] http://en.wikipedia.org/w/index.php?title=1984&oldid=197705621
[3]
http://en.wikipedia.org/w/index.php?title=1984&oldid=197705621&action=edit&…
[4]
http://en.wikipedia.org/w/index.php?title=Talk:Main_Page&action=edit§io…
Hi
I've been trying to use the API to get output into YAML format for
processing in Ruby. Seems (see
http://bugzilla.wikimedia.org/show_bug.cgi?id=12120 ) that the API's YAML
output is broken, as it does not escape quotes, colons followed by spaces
etc. This causes output like
title: Job: A Comedy of Justice
when getting the Wikipedia page with that title; due to the unescaped second
colon followed by space, Ruby's YAML.load chokes on this. Seems to me that
this basically means that YAML output is not usable for getting data from
wikipedia, quite a few of whose articles use ": " in titles or other fields.
Any thoughts on how to circumvent this (without using XML as format; I know
I can parse this from Ruby using REXML, but it ain't nearly as easy/clean as
YAML), or on a time horizon for a fix/update?
Any help or suggestions are appreciated,
thanks,
Loek Cleophas
See <http://www.mediawiki.org/wiki/Manual:%24wgAPIModules>: "Extension
modules cannot override the core modules." Why is that? As far as I
understand extension modules can override special pages, so why not
api modules? It would be particularly useful for extension
LuceneSearch. This extension overrides Special:Search and its (not yet
committed) api module should also override list=search.
Bryan