Mediawiki-api

mediawiki-api@lists.wikimedia.org

1 participants
1262 discussions

Fwd: Help with my project!
by Elisa Yelmo 08 May '17

08 May '17

Hi! My name is Elisa and I'm trying to do a project with mediawiki and eclipse. I have some questions about how to get the content of my page. I mean, I'm making a wiki and I want to print the content in my eclipse project when I need it. (It's a wiki about code). How can I make the request? Best, Elisa

1 0

[Mediawiki-api-announce] BREAKING CHANGE: Interpretation of rvstartid and rvendid parameters to prop=revisions
by Brad Jorsch (Anomie) 08 May '17

08 May '17

Most of the time, the ordering implied by revision ID number and the ordering implied by revision timestamp are the same. Differences occur mainly when revisions are imported from another wiki, however there may be other situations that can cause this. The database queries that were formerly used to handle the rvstartid and rvendid parameters were found to be very inefficient.[1] As of Gerrit change 349448,[2] these parameters are now equivalent to using the timestamps of the corresponding revisions for rvstart and rvend. This change should be deployed to WMF wikis with 1.30.0-wmf.1, see https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap for the schedule. [1]: https://phabricator.wikimedia.org/T163495#3200490 [2]: https://gerrit.wikimedia.org/r/#/c/349448/ -- 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

SMW: Askargs w/ comparators
by André Fincato 05 May '17

05 May '17

Hello, I’m currently converting `action=ask&query=[[Category:Event]][[OnDate::<2017/05/03]] + etc` to use `action=askargs`. So far I stripped away the double square brackets around Category:Event, and it gives back results. `action=ask&conditions=Category:Event&printouts=NameOfEvent` If I try to filter Category:Event by today’s date as above though, I get an error back, in all the following combination: * `action=ask&conditions=Category:Event[[OnDate::<2017/05/03]]&printouts=NameOfEvent` * `action=ask&conditions=Category:EventOnDate::<2017/05/03&printouts=NameOfEvent` * `action=ask&conditions=Category:Event|OnDate::<2017/05/03&printouts=NameOfEvent` * `action=ask&conditions=Category:Event&OnDate::<2017/05/03&printouts=NameOfEvent` Is it possible to use any similar syntax and filter upfront pages based on properties? The only reason why I am try to switch to askargs, is that, unlike ask, it has a query-continue-offset. Thanks, André

2 2

Re: [Mediawiki-api] [Mediawiki-api-announce] [ANNOUNCEMENT] REST API page metadata endpoints deprecation
by Marko Obrovac 03 May '17

03 May '17

Hello, This is just a friendly reminder that the page metadata end points mentioned below will be completely removed on 2017-05-08. Please update your clients if you are still using any of them. Cheers, Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation On 23 February 2017 at 18:28, Petr Pchelko <ppchelko(a)wikimedia.org> wrote: > Hello, > > Since the early days of REST API it provides two features that haven’t > been widely used neither internally in the WMF nor by the community. Today > in a clean-up pass over the API we have decided to deprecate and eventually > remove those features to allow some long-needed refactorings and stability > improvements of other, more important, endpoints. > > The first one is the ability to query metadata about the page via the > `/page/title/{title}`~[1] endpoint. The metadata includes properties like > the latest revision number of the page, user who have made the last edit, > whether the page is a redirect and similar. The backend storage model used > to power the feature is quite unique in the system and has a significant > maintenance cost without providing a clear benefit to users. > > Another feature that’s never found it’s audience is the ability to get > listings of revisions, titles and renders stored in RESTBase. These > listings suffer from scaling issues and cannot work reliably with the data > model we have. > > We have, hence, opted to remove these unused and complex endpoints until > there is some actual need for this data in the REST API when we can design > and implement them better. Here’s the list of endpoints that are now > deprecated and will be removed on May, 1st 2017: > > • /page/title/ > • /page/title/{title} > • /page/title/{title}/ > • /page/revision/ > • /page/revision/{revision} > > In case you are using them please switch to using the MediaWiki Action > API. In case you need assistance or have questions, feel free to reply to > this e-mail or contact the Wikimedia Services team~[2]. > > Best regards, > Petr Pchelko > Software Engineer > Wikimedia Foundation > > [1] https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_ > page_title_title > [2] https://www.mediawiki.org/wiki/Wikimedia_Services > > > _______________________________________________ > Mediawiki-api-announce mailing list > Mediawiki-api-announce(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce >

1 0

[ANNOUNCEMENT] REST API /page/mobile-text endpoint deprecation
by Marko Obrovac 03 May '17

03 May '17

Hello, The mobile-text endpoint~[1] was introduced in the REST API as an experiment in the early days of the Mobile-Content-Service~[2] to provide page content optimised for use in very lightweight mobile clients. The route was an experiment towards a new-generation lite app, initially targeted for low-powered, older Android devices. The idea was to use native Android UI components to show the page contents instead of in a WebView; alas, it was quickly surpassed by a new set of mobile-sections endpoints~[3]. The route is not maintained, there are no plans to use it within the WMF and according to our metrics the endpoint is not used by the community. Therefore, as part of the effort to consolidate the useful endpoints and focus on new features, we have decided to deprecate the route and remove it on May, 1st 2017. If you’re using the endpoint, please use the alternative mobile-sections endpoints~[3,4,5] instead. Should you have any questions or concerns, please reply to this e-mail or contact the Wikimedia Services Team~[6]. Cheers, Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation [1] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_text_title [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_ap… [3] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_tit… [4] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_lea… [5] https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_rem… [6] https://www.mediawiki.org/wiki/Wikimedia_Services

1 1

Why are coordinates not listed for some pages in API query?
by Bjoern Hassler 02 May '17

02 May '17

Hi all, not sure whether this is an API issue, or something to do with the way coordinates are stored. If you look at this query, you'll see that for some of the pages coordinates are listed, for others they are not: https://de.wikipedia.org/w/api.php?action=query&prop=coordinates&generator=… However, quite a few pages do have coordinates on the corresponding wikipedia page, e.g. https://de.wikipedia.org/wiki/Cornia_Nou Any ideas what that might be? (As an aside, just in case it's related: How do coordinates end up in Wikidata? I assume it's a bot? Presumably the bot uses the API? Some of the above pages have got coordinates on the page, but not in Wikidata...) Thanks! Bjoern

2 2

Getting wikipedia language links for a set of wikidata items via generator (in a single query)
by Bjoern Hassler 01 May '17

01 May '17

Hi all, I'd like to generate a set of wikidata items via a generator, with the listing containing the various associated wikipedia language pages. I think this would essentially be like using wbgetentities with a generator. I guess it's not possible in a single query? To explain: I can run this query: https://ca.wikipedia.org/w/api.php?action=query&prop=langlinks|pageprops|pa… which gives me the langlinks, as well as the wikidata item. I'd now like run an equivalent query on wikidata, retrieving all language links. However, I cannot see a way in which a query like https://www.wikidata.org/w/api.php?action=query&prop=...&generator=geosearc… can be made to include the language links? It's of course possible to get the ids with the above query, and then the language links with a second query: https://www.wikidata.org/w/api.php?action=wbgetentities&props=sitelinks&ids…. .. Is it possible in one query? I.e. something like https://www.wikidata.org/w/api.php?action=wbgetentities&props=sitelinks&gen… Many thanks! Bjoern

1 0

Re: [Mediawiki-api] [Wikitech-l] Deprecation notice for citoid.wikimedia.org domain
by Marko Obrovac 01 May '17

01 May '17

Hello, We have retired the subdomain citoid.wikimedia.org at 17:00 UTC today. As previously indicated by James, the way to reach Citoid, the citation service, is now exclusively through the REST API~[1]. Cheers, Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation [1] https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation On 8 March 2017 at 11:51, James Forrester <jforrester(a)wikimedia.org> wrote: > Hey all, > > The citoid service, which looks up URLs and similar strings and turns them > into citations, has moved to be accessed via RESTbase as part of > decommissioning the per-service domain system[0]. The old domain will stop > working on *1 May 2017* (just under two months from now). > > In simple terms, this means that requests to citoid via > citoid.wikimedia.org/api?… (*e.g.* [1]) now need to go to {wiki > domain}/api/rest_v1/data/citoid/… (*e.g.* [2]) to work. End-point > documentation is available in the usual place.[3] > > We have already moved the automatic citation feature inside the visual > editor to use the domain. If you are responsible for a script, gadget, or > tool which is using the old domain, please switch over before the deadline. > > [0] https://phabricator.wikimedia.org/T133001 > [1] > https://citoid.wikimedia.org/api?format=mediawiki&search= > http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F11926078_68 > > [2] > https://www.mediawiki.org/api/rest_v1/data/citation/ > mediawiki/http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F11926078_68 > > [3] https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation > > Yours, > > -- > > James D. Forrester > Lead Product Manager, Editing > Wikimedia Foundation, Inc. > jforrester at wikimedia.org > <https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> | > @jdforrester > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Proposal to deprecate parsing and diffs in the action API action=query&prop=revisions
by Brad Jorsch (Anomie) 28 Apr '17

28 Apr '17

TL;DR: I'm proposing deprecating a bunch of parameters. See https://phabricator.wikimedia.org/T164106. In the action API, there are two ways to parse a page/revision: using action=parse, or using the rvparse parameter to action=query&prop=revisions. Similarly, there are two ways to get a diff: using action=compare, or using parameters such as rvdiffto to action=query&prop=revisions. And then there's action=expandtemplates versus the rvexpandtemplates parameter to prop=revisions. This is a somewhat annoying bit of code duplication. Further, the prop=revisions versions of these features have somewhat strange behavior. rvparse forces rvlimit=1. rvdiffto and related parameters will sometimes output "notcached" with no way to directly handle the situation. So, I propose deprecating all of these parameters. The parameters that would be deprecated are the 'rvdifftotext', 'rvdifftotextpst', 'rvdiffto', 'rvexpandtemplates', 'rvgeneratexml', 'rvparse', and 'rvprop=parsetree' parameters to prop=revisions, and the similarly named parameters to prop=deletedrevisions, list=allrevisions, and list=alldeletedrevisions. Following the normal action API deprecation policy, they'd output warnings but would continue to function until usage drops sufficiently or until it becomes too much trouble to fix them, and they wouldn't receive new feature development. If anyone would object to this plan, please reply at https://phabricator.wikimedia.org/T164106, or here if you really hate Phabricator. If there aren't major objections, I'll probably do the deprecation in the next week or two. Thanks. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

1 0

Action=clientLogin issue
by Mujtaba Rafiq 23 Apr '17

23 Apr '17

Hello everyone, I am trying to login using action=clientlogin via javascript Ajax call and backend as well but for some reason I am always getting same error { "code": "badtoken", "info": "Invalid CSRF token.",....} If I use same parameters and call from POSTman it works and I get logged in. What could be wrong? Am I missing something thats not required by call from POSTman. I also posted the same question on API talk <https://www.mediawiki.org/wiki/API_talk:Login#action.3Dclientlogin> This is the link to the code for reference Link to github java code <https://github.com/Institute-Web-Science-and-Technologies/okb-toollabs/blob…> Thank you, Mujtaba Rafiq

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api