Re: query.php scheduled to die Monday, August 25

One thing I think cannot be done directly in api.php is
to return the pages that embed a *list* of templates.

So for example if I have template1, template2, template3,
with query.php I am able to return all pages embedding any
of these, while in api.php I have to make a query for
each one.

The problem is that eititle only accepts one title, and
that titles= is now ignored.

[[en:User:Tizio]]
Paolo Liberatore

On Thu, 31 Jul 2008, Magnus Manske wrote:

> On Wed, Jul 30, 2008 at 11:48 PM, Brion Vibber <brion@...> wrote:
> > -----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":
> >

Re: query.php scheduled to die Monday, August 25

Paolo Liberatore schreef:
> One thing I think cannot be done directly in api.php is
> to return the pages that embed a *list* of templates.
>
> So for example if I have template1, template2, template3,
> with query.php I am able to return all pages embedding any
> of these, while in api.php I have to make a query for
> each one.
>   
There's a very good reason for that: queries with dozens of values for 
eititle become very inefficient very fast.
> The problem is that eititle only accepts one title, and
> that titles= is now ignored.
That change was announced months ago on this list (search for 
"backlinks" in the subject).

Roan Kattouw (Catrope)

Re: query.php scheduled to die Monday, August 25

Magnus Manske schreef:
> Ah! Thanks.
> I also see that some query.php functions return properties "touched"
> (not the same as timestamp, apparently) and "revid". This is not
> critical AFAIK, and could be replaced with another query; that,
> however, seems inefficient.
Since touched is provided by prop=info and revid by prop=revisions (the 
latter in a slightly different format), you could just use 
generator=whatever&prop=info|revisions here.

Roan Kattouw (Catrope)

Totals of loggable actions?

Hi,

Would it be possible to add to the API, the ability to report totals
of particular log actions over given time periods?
Actions: un/protect, un/block, file upload, page creation,
un/deletion, un/assigning user rights, move, user creation, user
rename.
It could be fixed time periods (eg days, weeks, months) if constantly
calculating them for arbitrary time periods was considered too
intensive.

I often only want totals and having to page through results with heaps
of detail I don't care about is a drag.

For example, I would like to see the user creation totals on Commons,
to see the effect of SUL.

cheers
Brianna

--

-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

Re: Totals of loggable actions?

---- Brianna Laugher <brianna.laugher@...> schrijft: 
> Hi,
> 
> Would it be possible to add to the API, the ability to report totals
> of particular log actions over given time periods?
> Actions: un/protect, un/block, file upload, page creation,
> un/deletion, un/assigning user rights, move, user creation, user
> rename.
> It could be fixed time periods (eg days, weeks, months) if constantly
> calculating them for arbitrary time periods was considered too
> intensive.
> 
I'm sorry, but you're just gonna have to use the old-fashioned way of paging through list=logevents's
output and counting stuff. Use lelimit=max and a bot/sysop account and you'll get 5000 entries per request.

> I often only want totals and having to page through results with heaps
> of detail I don't care about is a drag.
There are two things you can do about this. To prevent having to throw away lots of entries that don't match
your criteria, use filtering parameters like letype. To get only the details you're interested in (saves
bandwidth), use leprop. You can't set leprop to empty, unfortunately, but you can do something like
leprop=ids to get very little data.

Roan Kattouw (Catrope)

Is it possible to add my own rvprop=... for prop=revisions?

I know a MediaWiki extension can add its own api.php action=... but
can I add my own rvprop=... for action=query&prop=revisions?

I'd like to experient with creating some Wiktionary-specific APIs that
can parse the article format and return grammatical information on
words.

Andrew Dunbar (hippietrail)

Re: Totals of loggable actions?

2008/8/11  <roan.kattouw@...>:
> I'm sorry, but you're just gonna have to use the old-fashioned way of paging through list=logevents's
output and counting stuff. Use lelimit=max and a bot/sysop account and you'll get 5000 entries per request.

Is it particularly annoying if I ask why?

Brianna

--

-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

Search query returns missing pages

Hello list,

I am wondering if the search module should return pages that don't
exist. If I am searching for something, I probably want to find
something that already exists, especially if I use srwhat=text. I don't
even know where the API gets the text to search in, for a page that
doesn't even exist.

Just look at the example:

http://en.wikipedia.org/w/api.php?format=xml&action=query&gsrsearch=Does
%20not%20exist&generator=search&gsrnamespace=0

Besides that, it also seems to find stuff that doesn't even belong into
the main namespace, even if it existed, like:

 - Http://en.wikipedia.org/wiki/Talk:State-sponsored terrorism by the
United States/Archive 9 (This isn't even a valid title)

 - User tаIk:Jj137/Archivе 5

Is this desired behaviour or is it a bug?

Simon Lehmann

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...

Re: Search query returns missing pages

Those are all pages that have been deleted. Deleted pages remain in
the database so they can be undeleted. (I'm not sure if they get
purged eventually or not.)

Your examples are, in fact, all in the main namespace, since the
namespaces Http: and User taIk: (note: that's a capital "i", not a
lowercase "L") do not currently exist.

I don't think the search should be returning deleted pages.

-Ran
(User:Ruakh)

On Mon, Aug 11, 2008 at 7:46 AM, Simon Lehmann <simon.lehmann <at> gmx.de> wrote:
> Hello list,
>
> I am wondering if the search module should return pages that don't
> exist. If I am searching for something, I probably want to find
> something that already exists, especially if I use srwhat=text. I don't
> even know where the API gets the text to search in, for a page that
> doesn't even exist.
>
> Just look at the example:
>
> http://en.wikipedia.org/w/api.php?format=xml&action=query&gsrsearch=Does
> %20not%20exist&generator=search&gsrnamespace=0
>
> Besides that, it also seems to find stuff that doesn't even belong into
> the main namespace, even if it existed, like:
>

Re: Search query returns missing pages

On Mon, Aug 11, 2008 at 9:46 PM, Simon Lehmann <simon.lehmann@...> wrote:
>
> I am wondering if the search module should return pages that don't
> exist. If I am searching for something, I probably want to find
> something that already exists, especially if I use srwhat=text. I don't
> even know where the API gets the text to search in, for a page that
> doesn't even exist.
>
> Just look at the example:
>
> http://en.wikipedia.org/w/api.php?format=xml&action=query&gsrsearch=Does
> %20not%20exist&generator=search&gsrnamespace=0

The first few in the results there have been deleted. No "pageid"
attribute and the presence of the "missing" attribute indicates a
deleted page. The question of whether such entries should be returned
by default, as seems to follow from your observation, is still open,
but the software didn't make this up, it's just from a deleted
revision.

> Besides that, it also seems to find stuff that doesn't even belong into
> the main namespace, even if it existed, like:
...

The ones that look like user talk pages had been moved, and the move
destination was misspelled ("User taIk", with a capital I instead of a
lowercase l - you may need a serif font to see the difference). If the
software doesn't recognise the namespace, then it treats it as if
there is simply a colon in the title and puts it in the mainspace.