When list=allusers is used with auactiveusers, a property 'recenteditcount'
is returned in the result. In bug 67301[1] it was pointed out that this
property is including various other logged actions, and so should really be
named something like "recentactions".
Gerrit change 130093,[2] merged today, adds the "recentactions" result
property. "recenteditcount" is also returned for backwards compatability,
but will be removed at some point during the MediaWiki 1.25 development
cycle.
Any clients using this property should be updated to use the new property
name. The new property will be available on WMF wikis with 1.24wmf12, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
[2]: https://gerrit.wikimedia.org/r/#/c/130093/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Hi, All,
I found in some of the UPLOAD update, there is no page id:
<rc type="log" ns="6" title="File:Lucian A. Sperta- Nunez.jpg" rcid="
114549183" pageid="0" revid="0" old_revid="0" user="Azarel63"oldlen="0"
newlen="0" timestamp="2014-01-05T11:09:38Z" comment="User created page with
UploadWizard" logid="77242320" logtype="upload"logaction="upload" img_sha1="
sf9t03wg27tl73nnde3jzfuxncefux9" img_timestamp="2014-01-05T11:09:36Z"/>
<rc type="log" ns="6" title="File:Gingerbread spices (annotated).jpg" rcid="
114549185" pageid="30485540" revid="0" old_revid="0"user="SKopp" oldlen="0"
newlen="0" timestamp="2014-01-05T11:09:37Z" comment="User created page with
UploadWizard" logid="77242318"logtype="upload" logaction="upload" img_sha1="
q84abqjr2n4bmn7o6j4uovpl5ufs2gq" img_timestamp="2014-01-05T11:09:37Z"/>
The first one has no page id but the second one has.
Does anybody can tell me the differences?
Thanks,
Ethan Liu
The API supports two methods for continuing action=query when more results
are available, the simple method[1] and the raw method.[2] The raw method
is currently the default for historical reasons, but as the simple method
is much easier for new users to use *correctly* that really should be the
default.
To make this transition easy for clients, the current plan is to make the
change on the following timetable:
* Starting with 1.24wmf22,[3][4] action=query will recognize a
"rawcontinue" boolean input parameter. Clients that wish to continue using
the raw method for continuation should begin supplying this parameter with
all action=query queries.
* Sometime during the MediaWiki 1.25 development cycle, the API will begin
reporting warnings when neither "continue" nor "rawcontinue" are supplied
with action=query.[5]
* Sometime during the MediaWiki 1.26 development cycle, simplified
continuation will become the default.[6]
Note this is also documented at <
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Simplified_…>.
See other sections on that page for additional planned API changes.
[1]: https://www.mediawiki.org/wiki/API:Query#Continuing_queries
[2]: https://www.mediawiki.org/wiki/API:Raw_Query_Continue
[3]: https://gerrit.wikimedia.org/r/#/c/154092/
[4]: See https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the
schedule of deployments to WMF wikis.
[5]: https://gerrit.wikimedia.org/r/#/c/160222/
[6]: https://gerrit.wikimedia.org/r/#/c/160223/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
With the success of prop=redirects, in Gerrit change 155592[1] I added new
prop modules prop=linkshere, prop=fileusage, and prop=transcludedin, which
are roughly equivalent to list=backlinks, list=imageusage, and
list=embeddedin but can work on a list of titles (including titles from a
generator).
They should be deployed to WMF wikis with 1.25wmf1 (unless we call it
1.24wmf23 after all), see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
I'm considering deprecating list=backlinks, list=imageusage, and
list=embeddedin at some point in favor of these new prop modules. Opinions
on this are welcome.
[1]: https://gerrit.wikimedia.org/r/#/c/155592/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
I am hoping that the mobile app I create that uses your API will sell lots of copies. Could happen. You never know. It’s a fun app.
The only thing I’ve read about quotas indicates that if one is calling the API from a JavaScript page, which I am, then the URL does not have to have an identifier like id=vispo.com or whatever, so that the service is free and there are no limiting quotas.
This seems too good to be true. Can you point me to the appropriate doc, please?
Thanks,
Jim Andrews
http://vispo.com
Do you know if there are any plans to include an article summary in the list=geosearch results? That would be terrific. I’ve been using the geonames.org API for retrieving Wikipedia articles, and it returns a brief (350-400 character?) article summary which seems to be the first 350-400 characters (or so) of the Wikipedia articles. This is very useful in search results, of course. The user can use that information to decide which of the several links to click. The title alone is often rather mysterious. It often does not provide enough info for the user to make a decision as to which link to click, if any.
Currently, the info I get back from your service ( https://www.mediawiki.org/wiki/Extension:GeoData#API ) has these fields:
<gs pageid="167267" ns="0" title="City Lights Bookstore" lat="37.7976" lon="-122.407" dist="1331" primary="" />
I’m suggesting it also include a ‘summary’ field consisting of the first 350-400 characters of the article.
Is that feasible?
What I currently do is use geonames as first choice and if that fails, I use your service. It would be nice to be able to use your service as first choice.
Thanks,
Jim Andrews
The fact that the hex-encoded sortkey must be converted to binary format
for prop=categorymembers cmstartsortkey and cmendsortkey has long been an
odd wart in the API.
Bug 70690[1] showed that the binary values for these parameters is actively
breaking on some wikis. In Gerrit change 159746[2] these parameters have
been deprecated in favor of new parameters cmstarthexsortkey and
cmendhexsortkey which take the sortkey in the same hex-encoded format that
is returned by the API.
This change should be deployed to WMF wikis with 1.24wmf22, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=70690
[2]: https://gerrit.wikimedia.org/r/#/c/159746/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Frances, thank you for your work and for your final report. I wish you well
in your ongoing task ("Finish writing search function for JWBF") and your
future endeavors.
I think Frances's internship went pretty well, and I wrote up a case study
of why it worked out: http://www.harihareswara.net/sumana/2014/08/13/1
(team of mentors, frequent communication, strong relationship, Frances is
great, scope small & cuttable, metacognition). Thanks so much to Tollef Fog
Heen, Brad Jorsch, Merlijn van Deen, and everyone else who helped mentor or
advise this project.
On Wed, Sep 10, 2014 at 2:02 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote:
>
> PS: Good luck with the Growstuff API! I've just signed up, so keep me in
> the loop about any cool applications you develop. :)
>
> Dan
> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
Dan, here's more information on the Growstuff features awaiting funding
for Frances to work on them: https://www.indiegogo.com/projects/growstuff
And I've already pointed one new contributor to
https://www.mediawiki.org/wiki/API:Client_code/Gold_standard -- new folks
who know various programming languages can now follow Frances's lead by
reading the standard, reviewing existing libraries, and writing
evaluations. Which is cool.
best,
Sumana Harihareswara
My (belated) final report for my OPW project is up on my progress
reports page: https://www.mediawiki.org/wiki/Evaluating_and_Improving_MediaWiki_web_API_c…
. Thank you to everyone who has helped me learn as much and contribute
as much as I have this summer, and special thanks to my mentors and
technical advisers. This has been a great experience, and I'm happy to
be leaving API:Client code in better shape than I found it!
I hope to stick around the MediaWiki development community as I move
on in my career as a software developer. I've applied for the January
batch of Hacker School. Until that starts, I'll be working on API
applications for Growstuff (http://growstuff.org): a gardening site
that collects crowdsourced data from local gardeners around the world
and freely licenses the resulting data. Wherever I end up after this,
I'm glad to have gotten my start on MediaWiki.
-Frances
On Sun, Sep 7, 2014 at 8:11 AM, Sean Pringle <springle(a)wikimedia.org> wrote:
>
> On Sun, Sep 7, 2014 at 5:58 AM, Brad Jorsch (Anomie) <
> bjorsch(a)wikimedia.org> wrote:
>
>> The database query for that is simple enough:
>>
>> SELECT /* ApiQueryCategoryMembers::run Anomie */
>> cl_from,cl_sortkey,cl_type,page_namespace,page_title,cl_timestamp FROM
>> `page`,`categorylinks` FORCE INDEX (cl_timestamp) WHERE cl_to =
>> 'Copy_to_Wikimedia_Commons_(bot-assessed)' AND (cl_from=page_id) ORDER BY
>> cl_timestamp,cl_from LIMIT 501;
>>
>> And the PHP code doesn't do anything complicated either. Maybe Sean can
>> give us more insight if there's some subtle database thing going on here.
>>
>
> As Nik noted, the query plan walking cl_timestamp is not ideal. Plus, even
> with the forced index the query requires a filesort since cl_timestamp
> index is on (cl_to,cl_timestamp) and not (cl_timestamp,cl_from).
>
We're including a constant cl_to in the query here, so the index on
(cl_to,cl_timestamp) is exactly what we want.
As for ORDER BY cl_timestamp, cl_from, that's
https://gerrit.wikimedia.org/r/#/c/103589/ taking advantage of InnoDB's
clustered indexes where it silently appends the primary key (or in this
case the first/only UNIQUE key, cl_from) to all other indexes.
When I EXPLAIN this query against enwiki, there's no filesort on master,
db1055, db1051, and db1066.
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => categorylinks
[type] => ref
[possible_keys] => cl_timestamp
[key] => cl_timestamp
[key_len] => 257
[ref] => const
[rows] => 635858
[Extra] => Using index condition; Using where
)
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => page
[type] => eq_ref
[possible_keys] => PRIMARY
[key] => PRIMARY
[key_len] => 4
[ref] => enwiki.categorylinks.cl_from
[rows] => 1
[Extra] =>
)
There is on db1061, db1062, db1065, db1072, and db1073.
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => categorylinks
[type] => ref
[possible_keys] => cl_timestamp
[key] => cl_timestamp
[key_len] => 257
[ref] => const
[rows] => 706656
[Extra] => Using index condition; Using where; Using filesort
)
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => page
[type] => eq_ref
[possible_keys] => PRIMARY
[key] => PRIMARY
[key_len] => 4
[ref] => enwiki.categorylinks.cl_from
[rows] => 1
[Extra] =>
)
My wild guess would be that the latter set of databases were somehow
created differently so that InnoDB is clustering using some index other
than cl_from.
>
> Removing the FORCE INDEX would allow cl_sortkey index to be used, with
> better selectivity.
>
On master, db1055, db1051, and db1066, removing the FORCE INDEX still
reports from EXPLAIN that it chose the cl_timestamp index. It does cause
EXPLAIN to stop saying "Using index condition" though.
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => categorylinks
[type] => ref
[possible_keys] => cl_from,cl_timestamp,cl_sortkey
[key] => cl_timestamp
[key_len] => 257
[ref] => const
[rows] => 525652
[Extra] => Using where
)
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => page
[type] => eq_ref
[possible_keys] => PRIMARY
[key] => PRIMARY
[key_len] => 4
[ref] => enwiki.categorylinks.cl_from
[rows] => 1
[Extra] =>
)
On db1061, db1062, db1065, db1072, and db1073, it does choose cl_sortkey
but it still filesorts.
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => categorylinks
[type] => ref
[possible_keys] => cl_from,cl_timestamp,cl_sortkey
[key] => cl_sortkey
[key_len] => 257
[ref] => const
[rows] => 525652
[Extra] => Using index condition; Using where; Using filesort
)
stdClass Object
(
[id] => 1
[select_type] => SIMPLE
[table] => page
[type] => eq_ref
[possible_keys] => PRIMARY
[key] => PRIMARY
[key_len] => 4
[ref] => enwiki.categorylinks.cl_from
[rows] => 1
[Extra] =>
)
If I also remove the cl_from from the ORDER BY, then all databases return
the same query using the cl_timestamp index. But the API can't do that
without reopening https://bugzilla.wikimedia.org/show_bug.cgi?id=24782.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation