Mediawiki-api September 2016

mediawiki-api@lists.wikimedia.org

4 participants
7 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

[Mediawiki-api-announce] DEPRECATION: Use of action=purge via GET is deprecated
by Brad Jorsch (Anomie) 29 Dec '16

29 Dec '16

To operate correctly, action=purge needs to write to the database, which means it should be done using a POST rather than a GET request. As of Gerrit change 310560,[1] action=purge will begin emitting a warning when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20, see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule. Clients that use action=paraminfo to determine whether to use GET or POST for an action should automatically switch to POST; any others should manually switch to using POST for this action as soon as possible. To check if your client's user agent is detected making such submissions, you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once 1.28.0-wmf.20 is rolled out to wikis your client is using. It is planned that this warning will be changed to an error during 1.29. Let's avoid having a repeat of T142155,[3] update your code ASAP instead of waiting until it breaks. Thanks. [1]: https://gerrit.wikimedia.org/r/#/c/310560/ [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage [3]: https://phabricator.wikimedia.org/T142155 -- 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 2

[Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body
by Brad Jorsch (Anomie) 01 Nov '16

01 Nov '16

For improved safety, passwords and other sensitive fields for authentication should not be included in the request URI during a POST. Instead, they should be in the POST body where they are less likely to be included in log files. With the merge of Gerrit change 305545,[1] the API will now produce a warning if such fields are detected in the URI. This should be deployed to WMF wikis with 1.28.0-wmf.16, see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule. This affects the following modules and fields: * action=login: 'lgpassword' * action=clientlogin, action=createaccount, action=linkaccount, and action=changeauthenticationdata: Any fields reported as "sensitive" by action=query&meta=authmanagerinfo or by UI or REDIRECT responses. Currently, this affects the 'password' and 'retype' fields. The 'lgtoken' field for action=login will now also issue a warning if placed in the request URI. The error code for other tokens being in the request URI has changed from 'mustposttoken' to 'mustpostparams'. To check if your client's user agent is detected making such submissions, you can also use ApiFeatureUsage[2] and look for '<action>-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis your client is logging in to. It is planned that these warnings will be changed to errors during 1.29. Let's avoid having a repeat of T142155,[3] update your code ASAP instead of waiting until it breaks. Thanks. [1]: https://gerrit.wikimedia.org/r/#/c/305545/ [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage [3]: https://phabricator.wikimedia.org/T142155 -- 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 1

Please provide your use cases for pageview data in the action API
by Gergo Tisza 14 Sep '16

14 Sep '16

Hi all, the Wikimedia Foundation's Reading Infrastructure team [1] is preparing to work on exposing pageview data in the action API [2]. Pageview data is already available as a standalone REST API [3] but we are hoping to make access to that information more convenient by including it in the output of other APIs as well. This could include information like daily pageview totals for the wiki for the last X day, monthly unique visitors, list of the most-viewed pages, daily view totals for specific pages (integrated with other page information the API provides). It is important that we understand what use cases to expect when selecting what information to include and making other design decisions; if you might use such an API in the future, please leave a comment on the task [4] and tell us how you would use it and what information you expect from it. Thanks! Gergő https://www.mediawiki.org/wiki/User:Tgr_(WMF) [1] https://www.mediawiki.org/wiki/Wikimedia_Reading_Infrastructure_team [2] a.k.a. api.php or MediaWiki API - the one at https://www.mediawiki.org/wiki/Special:ApiSandbox [3] https://wikitech.wikimedia.org/wiki/Analytics/PageviewAPI [4] https://phabricator.wikimedia.org/T144865

1 0

how to get Internal Broken Links of pages?
by Shiyue Zhang 12 Sep '16

12 Sep '16

Hello, everyone. I have a question: how can I use API to get the number of internal broken links of a page? Cheers, Shiyue -- Zhang Shiyue *Tel*: +86 18801167900 *E-mail*: byryuer(a)gmail.com, yuer3677(a)163.com State Key Laboratory of Networking and Switching Technology No.10 Xitucheng Road, Haidian District Beijing University of Posts and Telecommunications Beijing, China.

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api September 2016