Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Mediawiki-apiAugust 2014

mediawiki-api@lists.wikimedia.org
  • 10 participants
  • 13 discussions
Start a nNew thread

20 Jan '26
Hi there,I'm using the API to extract the raw wiki text from my pages, usingthe "?action=query&titles=Main_Page&export&exportnowrap" syntax. Thatworks perfectly.Now I would like to get the templates expanded out in the result, so Iuse: "?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 tohelp process the wiki text in subsequent steps).Is there a way to expand templates with the API, but leave thecomments intact?Thanks,Kevin
4 5
0 0
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 pagegiven the title of the wikipedia page. I have done some research and foundout that the abstract with be in rvsection=0 So for example if I want the abstract of 'Eiffel Tower" wiki page then I amquerying 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 <revxml:space="preserve"> which represents the abstract of the wikipedia page.But this wiki text also contains the infobox data which I do not need. Iwould like to know if there is anyway in which I can remove the infobox dataand get only the wikitext related to the page's abstract Or if there is anyalternative method by which I can get the abstract of the page directly.Looking forward to your help.Thanks in AdvanceAditya Uppu
4 3
0 0
When list=allusers is used with auactiveusers, a property 'recenteditcount'is returned in the result. In bug 67301[1] it was pointed out that thisproperty is including various other logged actions, and so should really benamed something like "recentactions".Gerrit change 130093,[2] merged today, adds the "recentactions" resultproperty. "recenteditcount" is also returned for backwards compatability,but will be removed at some point during the MediaWiki 1.25 developmentcycle.Any clients using this property should be updated to use the new propertyname. The new property will be available on WMF wikis with 1.24wmf12, seehttps://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 EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 1
0 0
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 withUploadWizard" 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 withUploadWizard" 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
0 0
I've just submitted Gerrit change 153110[1] which will overhaul the tokenhandling in the API, as described on the API Roadmap RFC.[2] The patch isnot merged yet, feel free to join in the code review or reply withcomments. Follow the Gerrit change for any changes to the informationbelow. A followup to this announcement with deployment dates will be sentonce the change is merged.For clients, all the old methods of fetching tokens will continue to workwith deprecation warnings. Usage levels of the deprecated methods onqueries to WMF wikis will be evaluated once the MediaWiki 1.25 developmentcycle 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'treally a token in the sense of the rest, is now available fromaction=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 tokenis needed.* The output from action=paraminfo includes the token type as a property onthe subobject describing the token parameter.* All tokens may be cached as long as the session is valid; none aredependent on factors such as the page being edited or the user beingtargeted.* Most token types have been replaced with a single 'csrf' token. This haslong been the case in practice (e.g. see [3]), this just makes it official.* The tokens returned for action=rollback and action=userrights (andcertain extension modules) are no longer the same tokens used in thecorresponding features in the web UI. The web UI tokens are accepted by theAPI 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 foraction=edit.For extension authors, if your extension uses the core token handling it*will* need updating. I've already submitted patches for the 26 extensionshosted 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 returningboolean true, this will continue to work with older versions of MediaWiki.* If a custom salt is needed, the new 'ApiQueryTokensRegisterTypes' hookmust be used to register it.* If web UI will be using a different salt (e.g. because it's included inlinks rather than posted form fields), a method getWebUITokenSalt() may beoverridden to supply this salt for compatibility.* It is no longer necessary to return data for 'token' fromgetAllowedParams() or getParamDescription(). Any return fromgetAllowedParams() will be overridden; a string from getParamDescription()will also be overridden with a standard message, while an array will havethe standard message prepended.** Compatibility with older versions of MediaWiki may be maintained bycontinuing to return data for 'token' from getAllowedParams() and a stringfor 'token' from getParamDescription().* getTokenSalt() is no longer called or defined in ApiBase, and may beremoved once compatibility with older versions of MediaWiki is no longerneeded. [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 EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 1
0 0
With the merge of Gerrit change 154098,[1] various seldom-used API outputformats are now deprecated: dbg, dump, txt, wddx, and yaml. Clients usingany of these formats should transition to the json format.In addition, any clients still using deprecated parameters to othermodules[2] should transition to the non-deprecated replacements. We'vebegun logging the use of these parameters on WMF wikis, and when usagedrops sufficiently they may be removed.Plans are also underway to improve the json format.[2] This may result inthe deprecation of format=json in favor of format=json2; if you would liketo provide input on the planned changes or on whether the improved formatshould be "format=json2" or something else, please comment at the linkedpage.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 EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 1
0 0
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 entrypoint 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 continueto be used in many contexts."MediaWiki API", "Web API", and "MediaWiki web API" are liable to beconfused with the proposed REST API, which is also supposed to beweb-accessible and will theoretically part of MediaWiki (even though I'dguess it's probably going to be implemented as an -oid). "MediaWiki webAPIs" may well grow to encompass the api.php action API, the REST API, andmaybe even stuff like Parsoid."MediaWiki API" and "Core API" are liable to be confused with the varioushooks and PHP classes used by extensions."JSON API" wouldn't be accurate for well into the future, and would likelybe 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
0 0
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 writingpatches for the Java Wiki Bot Framework (JWBF). I've been able to getone to compile, but I have persistent runtime errors.I've put the relevant information and things I've already tried inthis gist:https://gist.github.com/fhocutt/0221c1a35265ce7cda33Has anyone had similar problems while getting JWBF set up, or seensimilar behavior from other Java projects?-Frances
1 0
0 0
Hi all,When I wrote the new API client library standard, one of the intendedeffects was that libraries would make it easy for bot-runners tocomply with the user-agent policy found athttps://meta.wikimedia.org/wiki/User-agent_policy . However, differentpeople 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 botand 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 libraryevaluation 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 . AsI understood it, the example provided demonstrated the requirements,but it's now clear to me that there's room for ambiguity in theinterpretation of the user-agent policy.My question is: what information is essential to "identify" a bot? Theexample given appears to contain the bot name and version, a link to apage 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, Iassume). Does WMF operations want all of these components? What is theminimum necessary to comply with the policy, and what is bonusinformation?-Frances
4 7
0 0
Gerrit change 152760,[1] likely to be merged in time for 1.24wmf17,[2] willremove the 'props' and 'errors' result properties from the output ofaction=paraminfo. The format of the former was never clearly specified, andthe latter can be extremely difficult to keep updated and will only getworse as more error handling is moved out of the API and into theunderlying core code.Further detail and discussion of this change is athttps://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 EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
2 1
0 0
Results per page:
[8]ページ先頭
©2009-2026 Movatter.jp