Mediawiki-api August 2014

mediawiki-api@lists.wikimedia.org

10 participants
13 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) 17 Apr '19

17 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

A question about UPLOAD update
by Liu Chenheng 02 Dec '14

02 Dec '14

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

4 6

[Mediawiki-api-announce] Upcoming changes to token handling (and deprecation of old methods)
by Brad Jorsch (Anomie) 27 Aug '14

27 Aug '14

I've just submitted Gerrit change 153110[1] which will overhaul the token handling in the API, as described on the API Roadmap RFC.[2] The patch is not merged yet, feel free to join in the code review or reply with comments. Follow the Gerrit change for any changes to the information below. A followup to this announcement with deployment dates will be sent once the change is merged. For clients, all the old methods of fetching tokens will continue to work with deprecation warnings. Usage levels of the deprecated methods on queries to WMF wikis will be evaluated once the MediaWiki 1.25 development cycle begins. Changes visible to clients include: * All tokens are available from the new meta=tokens query submodule. ** The "centralauth" token, which was provided by action=tokens but wasn't really a token in the sense of the rest, is now available from action=centralauthtoken. ** Note that it is possible to use meta=tokens along with other query prop, list, and meta modules. * The help for all token parameters clearly indicates which type of token is needed. * The output from action=paraminfo includes the token type as a property on the subobject describing the token parameter. * All tokens may be cached as long as the session is valid; none are dependent on factors such as the page being edited or the user being targeted. * Most token types have been replaced with a single 'csrf' token. This has long been the case in practice (e.g. see [3]), this just makes it official. * The tokens returned for action=rollback and action=userrights (and certain extension modules) are no longer the same tokens used in the corresponding features in the web UI. The web UI tokens are accepted by the API for compatibility, but not vice versa. * Any API query (with a few exceptions, mainly queries to the 'feed' modules) will return the current timestamp when passed the 'curtimestamp' parameter. This may be used to fetch the starttimestamp necessary for action=edit. For extension authors, if your extension uses the core token handling it *will* need updating. I've already submitted patches for the 26 extensions hosted in WMF's Gerrit repository. The necessary changes are: * needsToken() must return a string or false; true will result in an error. Unless there are special security issues that require a custom salt, 'csrf' should be returned. ** Since any truthy string is equivalent to the old behavior of returning boolean true, this will continue to work with older versions of MediaWiki. * If a custom salt is needed, the new 'ApiQueryTokensRegisterTypes' hook must be used to register it. * If web UI will be using a different salt (e.g. because it's included in links rather than posted form fields), a method getWebUITokenSalt() may be overridden to supply this salt for compatibility. * It is no longer necessary to return data for 'token' from getAllowedParams() or getParamDescription(). Any return from getAllowedParams() will be overridden; a string from getParamDescription() will also be overridden with a standard message, while an array will have the standard message prepended. ** Compatibility with older versions of MediaWiki may be maintained by continuing to return data for 'token' from getAllowedParams() and a string for 'token' from getParamDescription(). * getTokenSalt() is no longer called or defined in ApiBase, and may be removed once compatibility with older versions of MediaWiki is no longer needed. [1]: https://gerrit.wikimedia.org/r/#/c/153110/ [2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Token_handl… [3]: https://en.wikipedia.org/w/api.php?format=jsonfm&action=tokens&type=block|d… -- 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 of seldom-used formats, and other deprecation notes
by Brad Jorsch (Anomie) 22 Aug '14

22 Aug '14

With the merge of Gerrit change 154098,[1] various seldom-used API output formats are now deprecated: dbg, dump, txt, wddx, and yaml. Clients using any of these formats should transition to the json format. In addition, any clients still using deprecated parameters to other modules[2] should transition to the non-deprecated replacements. We've begun logging the use of these parameters on WMF wikis, and when usage drops sufficiently they may be removed. Plans are also underway to improve the json format.[2] This may result in the deprecation of format=json in favor of format=json2; if you would like to provide input on the planned changes or on whether the improved format should be "format=json2" or something else, please comment at the linked page. Thanks. [1]: https://gerrit.wikimedia.org/r/#/c/154098/ [2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Removal_of_… [3]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Changes_to_… -- 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

Re: [Mediawiki-api] [Wikitech-l] Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 15 Aug '14

15 Aug '14

Summing up, it seems like "action API" and "api.php" are the two contenders. "api.php" is least likely to be confused with anything (only its own entry point file). But as a name it's somewhat awkward. "action API" might be confused with the Action class and its subclasses, although that doesn't seem like a big deal. As for the rest: Just "API" is already causing confusion. Although it'll certainly continue to be used in many contexts. "MediaWiki API", "Web API", and "MediaWiki web API" are liable to be confused with the proposed REST API, which is also supposed to be web-accessible and will theoretically part of MediaWiki (even though I'd guess it's probably going to be implemented as an -oid). "MediaWiki web APIs" may well grow to encompass the api.php action API, the REST API, and maybe even stuff like Parsoid. "MediaWiki API" and "Core API" are liable to be confused with the various hooks and PHP classes used by extensions. "JSON API" wouldn't be accurate for well into the future, and would likely be confused with other JSON-returning APIs such as Parsoid and maybe REST. "Classic API" makes it sound like there's a full replacement. All the code name suggestions would be making things less clear, not more. If it had started out with a code name there would be historical inertia, but using a code name now would just be silly.

2 1

Help with runtime errors in JWBF bot?
by Frances Hocutt 14 Aug '14

14 Aug '14

I'm trying to write some basic test bots before I start writing patches for the Java Wiki Bot Framework (JWBF). I've been able to get one to compile, but I have persistent runtime errors. I've put the relevant information and things I've already tried in this gist: https://gist.github.com/fhocutt/0221c1a35265ce7cda33 Has anyone had similar problems while getting JWBF set up, or seen similar behavior from other Java projects? -Frances

1 0

Clarification on what is needed for "identifying the bot" in bot user-agent?
by Frances Hocutt 11 Aug '14

11 Aug '14

Hi all, When I wrote the new API client library standard, one of the intended effects was that libraries would make it easy for bot-runners to comply with the user-agent policy found at https://meta.wikimedia.org/wiki/User-agent_policy . However, different people understand the policy to mean different things. As I read it, the relevant parts of the policy are: "If you run a bot, please send a User-Agent header identifying the bot and supplying some way of contacting you, e.g.: `User-Agent: MyCoolTool/1.1 (http://example.com/MyCoolTool/; MyCoolTool(a)example.com) BasedOnSuperLib/1.4`" There's been some discussion in the context of my client library evaluation project here: https://www.mediawiki.org/wiki/API_talk:Client_code/Evaluations/Java_Wiki_B… and here: https://github.com/jpatokal/mediawiki-gateway/issues/65 . As I understood it, the example provided demonstrated the requirements, but it's now clear to me that there's room for ambiguity in the interpretation of the user-agent policy. My question is: what information is essential to "identify" a bot? The example given appears to contain the bot name and version, a link to a page with more information and/or the repository for the bot's code, and the framework that was used to write the bot (SuperLib/1.4, I assume). Does WMF operations want all of these components? What is the minimum necessary to comply with the policy, and what is bonus information? -Frances

4 7

[Mediawiki-api-announce] BREAKING CHANGE: Removal of 'props' and 'errors' from action=paraminfo
by Brad Jorsch (Anomie) 10 Aug '14

10 Aug '14

Gerrit change 152760,[1] likely to be merged in time for 1.24wmf17,[2] will remove the 'props' and 'errors' result properties from the output of action=paraminfo. The format of the former was never clearly specified, and the latter can be extremely difficult to keep updated and will only get worse as more error handling is moved out of the API and into the underlying core code. Further detail and discussion of this change is at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Removal_of_… [1]: https://gerrit.wikimedia.org/r/#/c/152760/ [2]: https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap -- 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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api August 2014