Mediawiki-api January 2016

mediawiki-api@lists.wikimedia.org

7 participants
18 discussions

How to expand templates, but leave comments
by Kevin Dunn 20 Jan '26

20 Jan '26

Hi there, I'm using the API to extract the raw wiki text from my pages, using the "?action=query&titles=Main_Page&export&exportnowrap" syntax. That works perfectly. Now I would like to get the templates expanded out in the result, so I use: "?action=query&titles=Main_Page&prop=revisions&rvlimit=1&rvprop=content&rvexpandtemplates", which does the job, as expected, but it also strips out the comments. My problem is that the comments are meaningful to me (I use them to help process the wiki text in subsequent steps). Is there a way to expand templates with the API, but leave the comments intact? Thanks, Kevin

4 5

Need to extract abstract of a wikipedia page
by aditya srinivas 23 Nov '23

23 Nov '23

Hello, I am writing a Java program to extract the abstract of the wikipedia page given the title of the wikipedia page. I have done some research and found out that the abstract with be in rvsection=0 So for example if I want the abstract of 'Eiffel Tower" wiki page then I am querying using the api in the following way. http://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Eiffel… and parse the XML data which we get and take the wikitext in the tag <rev xml:space="preserve"> which represents the abstract of the wikipedia page. But this wiki text also contains the infobox data which I do not need. I would like to know if there is anyway in which I can remove the infobox data and get only the wikitext related to the page's abstract Or if there is any alternative method by which I can get the abstract of the page directly. Looking forward to your help. Thanks in Advance Aditya Uppu

4 3

[Mediawiki-api-announce] Deprecation of list=allusers 'recenteditcount' result property
by Brad Jorsch (Anomie) 16 Apr '19

16 Apr '19

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

1 1

Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 18 Apr '16

18 Apr '16

We have decided to officially retire the rest.wikimedia.org domain in favor of /api/rest_v1/ at each individual project domain. For example, https://rest.wikimedia.org/en.wikipedia.org/v1/?doc becomes https://en.wikipedia.org/api/rest_v1/?doc Most clients already use the new path, and benefit from better performance from geo-distributed caching, no additional DNS lookups, and sharing of TLS / HTTP2 connections. We intend to shut down the rest.wikimedia.org entry point around March, so please adjust your clients to use /api/rest_v1/ soon. Thank you for your cooperation, Gabriel -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

2 2

RFC: Defining a policy for REST API result format versioning / negotiation
by Gabriel Wicke 25 Feb '16

25 Feb '16

Hi, we are considering a policy for REST API end point result format versioning and negotiation. The background and considerations are spelled out in a task and mw.org page: https://phabricator.wikimedia.org/T124365 https://www.mediawiki.org/wiki/Talk:API_versioning Based on the discussion so far, have come up with the following candidate solution: 1) Clearly advise clients to explicitly request the expected mime type with an Accept header. Support older mime types (with on-the-fly transformations) until usage has fallen below a very low percentage, with an explicit sunset announcement. 2) Always return the latest content type if no explicit Accept header was specified. We are interested in hearing your thoughts on this. Once we have reached rough consensus on the way forward, we intend to apply the newly minted policy to an evolution of the Parsoid HTML format, which will move the data-mw attribute to a separate metadata blob. Gabriel Wicke

1 3

*unclear-"now"-timestamp* (was Re: [Wikitech-l] Bot operators: Please check your configuration)
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

On Fri, Jan 29, 2016 at 1:41 PM, Bináris <wikiposta(a)gmail.com> wrote: > 2016-01-29 18:56 GMT+01:00 Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>: > > > by going to > > https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your > > agent > > (or any useful prefix of it), and looking for "https-expected". > > > > What does *unclear-"now"-timestamp* mean here? > For various API timestamp-typed parameters, you can pass unusual values such as the empty string or "0" and it will be interpreted as meaning "now", which doesn't make very much sense except for the fact that it has always done that. If you really mean "now", you should pass that as the value instead. action=edit even has to hack around this to avoid spurious edit conflicts if you do it for the 'basetimestamp' parameter. Ideally we'd make empty string and '0' be rejected as invalid timestamps, but first people have to stop passing them in. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

1 0

[Mediawiki-api-announce] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 29 Jan '16

29 Jan '16

(+mediawiki-api-announce, 2nd try) ---------- Forwarded message ---------- From: Gabriel Wicke <gwicke(a)wikimedia.org> Date: Mon, Jan 25, 2016 at 11:00 AM Subject: Deprecating rest.wikimedia.org in favor of /api/rest_v1/ We have decided to officially retire the rest.wikimedia.org domain in favor of /api/rest_v1/ at each individual project domain. For example, https://rest.wikimedia.org/en.wikipedia.org/v1/?doc becomes https://en.wikipedia.org/api/rest_v1/?doc Most clients already use the new path, and benefit from better performance from geo-distributed caching, no additional DNS lookups, and sharing of TLS / HTTP2 connections. We intend to shut down the rest.wikimedia.org entry point around March, so please adjust your clients to use /api/rest_v1/ soon. Thank you for your cooperation, Gabriel -- Gabriel Wicke Principal Engineer, Wikimedia Foundation -- Gabriel Wicke Principal Engineer, Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

[FINAL COMMENT PERIOD] [RFC]: Defining a policy for REST API result format versioning / negotiation
by Gabriel Wicke 29 Jan '16

29 Jan '16

This is now entering its final comment period, so please weigh in at https://phabricator.wikimedia.org/T124365. Based on your input, the Parsing, Editing & Services teams will make a decision on this next Wednesday, Feb 2nd. Thanks, Gabriel On Thu, Jan 21, 2016 at 4:29 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > Hi, > > we are considering a policy for REST API end point result format > versioning and negotiation. The background and considerations are > spelled out in a task and mw.org page: > > https://phabricator.wikimedia.org/T124365 > https://www.mediawiki.org/wiki/Talk:API_versioning > > Based on the discussion so far, have come up with the following > candidate solution: > > 1) Clearly advise clients to explicitly request the expected mime type > with an Accept header. Support older mime types (with on-the-fly > transformations) until usage has fallen below a very low percentage, > with an explicit sunset announcement. > > 2) Always return the latest content type if no explicit Accept header > was specified. > > We are interested in hearing your thoughts on this. > > Once we have reached rough consensus on the way forward, we intend to > apply the newly minted policy to an evolution of the Parsoid HTML > format, which will move the data-mw attribute to a separate metadata > blob. > > Gabriel Wicke -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

[Mediawiki-api-announce] Bot operators: Please check your configuration
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

It currently still works to POST to the API via http instead of https. But we'd really like to stop allowing that, see https://phabricator.wikimedia.org/T105794. Thus, the API will now return a warning if https was expected but not used. If you run a bot, please check your configuration to make sure that you're using https rather than http. If you're using a distinctive user agent for your bot (which you all are, right?[1]), you can now check whether your bot is using http by going to https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your agent (or any useful prefix of it), and looking for "https-expected". If for some reason your bot cannot support https, you really should upgrade it to make that happen. [1]: https://meta.wikimedia.org/wiki/User-Agent_policy -- Brad Jorsch (Anomie) Senior 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

1 0

Re: [Mediawiki-api] [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 29 Jan '16

29 Jan '16

On Mon, Jan 25, 2016 at 11:38 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote: > Will it apply to the pageviews API as well? It will, but the canonical URL for this has always been https://wikimedia.org/api/rest_v1/?doc, which will continue to work. Are you aware of any pageview users hitting rest.wikimedia.org? In any case, we'll check the logs for remaining rest.wikimedia.org accesses & make an effort to remind remaining users before decommissioning it. Gabriel

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api January 2016