Mediawiki-api

mediawiki-api@lists.wikimedia.org

1264 discussions

Full-text search - list=search VS generator=search
by Luigi Assom 28 Jan '16

28 Jan '16

Hello, I would like to better understand the difference in using list=search VS generator=search for full-text search. I've read list=search relies on elastic search: which are the differences in indexing and differences in returned results between list=generator and generator=search ? I also need to query the page_ID of returned articles: I can using a generator=search: page_IDs are related to returned pages (example in sandbox <https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=extracts…> ) But cannot do it with list=search: I tried: list=search + generator=allpages + indexpageids parameter. The pageIDs in query['pageids'] *are not related* to the articles in the query['search'] list - it looks like generator is querying new stuff by itself, instead of taking the list in input. Could you please help to write a query using list=search to fetch also pageIDs of returned pages? My sandbox attempt is: https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&list=search&f… Thank you!

3 2

[Mediawiki-api-announce] Changes and deprecation in login and createaccount tokens
by Brad Jorsch (Anomie) 28 Jan '16

28 Jan '16

With the merge of Gerrit change 264309,[1] there are two changes to the handling of login and createaccount tokens. The changes should be deployed to WMF wikis with 1.27.0-wmf.12, see https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap for the schedule. Neither of these changes should break existing API clients, unless the client is treating API warnings as errors or is doing something unusual with these tokens. The first change is that login and createaccount tokens now use the same token generation mechanism as other CSRF tokens, but not the special case that results in other CSRF tokens always being "+\" when not logged in. This means that login and createaccount tokens will be longer, will end in "+\", and include an embedded timestamp so a potential future change could have them expire after a defined time period rather than lasting for the duration of the session. The second change is that login and createaccount tokens will now be able to be fetched via action=query&meta=tokens, in the same manner as other CSRF tokens. Fetching them by submitting an action=login or action=createaccount request without a token (to receive a NeedToken response) is now deprecated, and a warning will be returned along with the NeedToken response indicating this deprecation. There is no plan to actually remove the NeedToken response from action=login at this time, and any future plan for its removal will be announced separately with appropriate lead time. The NeedToken response will remain in action=createaccount until the previously-announced breaking change to that module,[2] and will be removed from action=createaccount along with that breaking change. [1]: https://gerrit.wikimedia.org/r/#/c/264309/ [2]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0… -- 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] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 25 Jan '16

25 Jan '16

Strainu, On Mon, Jan 25, 2016 at 11:01 AM, Strainu <strainu10(a)gmail.com> wrote: > Hi, > > Does this apply to the Graph extension as well? the graph extension has been using /api/rest_v1/ right from the start, so it's likely that no changes are needed for graphs. Gabriel

1 0

Help for a refrencing linkshere api call
by Sven Anders 22 Jan '16

22 Jan '16

Hi, for the OSM-Validatior of the "Open Diplomatic Map" [1] I would like to a get a list of all ISO 3166-2 Codes (P300) in a "table". In SQL I would do: SELECT p.value, q.label.en, q.id FROM Q q, P p WHERE p='P300' AND p in q That should result in: [{'code':'GB-ENG', 'label-en':'England', 'wikidataId':'Q21'}, {'code':'GB-SCT', 'label-en':'Scotland', 'wikidataId':'Q22'}, ... ] How do I get the data best. I saw that there is an API-call: https://www.wikidata.org/w/api.php?action=query&titles=Property:P300&prop=l… After this I have to call for each result: https://www.wikidata.org/w/api.php?action=wbgetentities&props=labels&ids=Q2… I hope there is a better way to do this? Best Regards Sven 1: https://anders.hamburg/osm/diplomatic/

2 1

[Mediawiki-api-announce] Upcoming BREAKING CHANGES: Changes to interactive login and account creation
by Brad Jorsch (Anomie) 20 Jan '16

20 Jan '16

You may remember the announcement last week about changes for bot login (if you somehow missed it, see https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0…). This is the promised follow-up for clients that do interactive login, and also for anyone doing account creation. AuthManager is going to be changing how some API modules work. For interactive user login, you're going to want to change to using action=clientlogin. The action=createaccount is also going to change to a more interactive flow. The WIP code for the new API modules is in https://gerrit.wikimedia.org/r/#/c/265201/; it's not too late to change stuff in there, but bring good reasons. Our target is to have this rolling out to WMF wikis by the end of February. The general procedure for using both of these will be the same: 1. Fetch the initial field information from the new action=query&meta=authmanagerinfo. Using format=json, the relevant part of the data structure is an object with keys being field names and values being objects that include the data type (string, password, select, multiselect, checkbox, button), localized labels, and such. 2. Convert that field information into UI to display to your users. 3. Take the user input and post it to action=clientlogin or action=createaccount, along with some other information documented in those modules. 4. The response will tell you what to do next: - PASS: You're done, it succeeded. - FAIL: You're done, it failed. There's a localized "message" field to tell you why. - UI: More user input is needed. There's a localized "message", and there's field information like you got in step 1. You'll repeat steps 2–4 with the new fields (and with slightly different module parameters in step 3). The use cases here include requesting the second factor for 2-factor auth, prompting the user to reset their password, informing them that they were renamed from "Example" to "Example~enwiki", etc. - REDIRECT: It wants you to send the user to another website, e.g. pop up a browser or a web view. Once the remote site is done, it'll send the user to a URL you specified in step 3, at which time you'll extract the data from that request and repeat steps 3–4. There's also provision for skipping the redirect if your app knows how to do a non-web authentication against the provider, e.g. a GoogleLogin extension could provide data that an Android app needs to use some internal Android API to authenticate with a Google account and get the needed data. The use case here is for something like "log in with Google", "log in with Facebook", generic "log in with OpenID", and so on where you have to send the user to some other site. - RESTART: This means that the user authenticated ok, but we don't know what user account the credentials belong to. You could treat this response as if it were UI so they can log in with a different mechanism, or as FAIL, or you could start up action=createaccount to create a new account. The use case here is again something like "log in with Google", Google returned success but we don't have any on-wiki account linked with that Google account. Account creation is going to break on day 1, we're not trying to maintain any backwards compatibility there since it wouldn't be likely to work very well anyway and there aren't many account creation clients out there. The old login with action=login will probably continue to work for users who don't have 2-factor auth, a migrated CentralAuth account (i.e. trying to log in as Example when you're now Example~enwiki), or anything else that would make a UI or REDIRECT response be returned, but again we're not guaranteeing that it won't suddenly stop at some point. Also, the old login mechanism will start returning a "Aborted" or "Failed" (with a localized message) rather than "WrongToken", "BadPassword", "Throttled", and so on. _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

[Mediawiki-api-announce] Upcoming BREAKING CHANGE: Changes to login for bots
by Brad Jorsch (Anomie) 14 Jan '16

14 Jan '16

MediaWiki's authentication layer is getting a major overhaul. For more details see the announcement "MediaWiki authentication changes" sent to wikitech-l[1]; this email will repeat the portion relevant to bots. If you maintain an interactive application that uses API login, the details of how this will affect you aren't yet finalized; see the announcement on wikitech-l for more, or wait for a future announcement to this list once the details are available. The "thinks will break" date has not yet been decided, but the goal is to have it ready by the end of February. *TL;DR:* Switch your bot to OAuth if possible, or look at Special:BotPasswords (being deployed next week on WMF wikis) to set up a new username+password for your bot to use with action=login in the future. The new authentication features mean that unattended login might no longer work since the login flow will now natively support user interaction: the account might have 2-factor enabled, or might need a password reset, or some other thing that requires user interaction. We've created two ways to work around this: - If possible, switch to OAuth. This week (1.27.0-wmf.10) "owner-only" consumers are being rolled out to make this easier for bot operators: log into your bot account, go to https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose, and create a consumer with the "This consumer is for use only by MyBotName" checkbox checked.The consumer will be approved for use immediately, no waiting or trying to find someone who can approve the consumer for you. Owner-only consumers also don't tag every edit, since all the edits will be from the one account anyway. - If you need to continue using the existing action=login, next week (1.27.0-wmf.11) we're rolling out Bot Passwords. This is something like OAuth-lite, or Google's application passwords: go to Special:BotPasswords, set one up, and then use new bot-password username and password to login as you've always done (no code changes, just update your bot's configuration). It's already live in Beta Labs if you want to test it out. action=login with the "main" account password might still continue to work after the new AuthManager is deployed, as long as nothing requires user interaction. For bots that run on third-party wikis, Bot Passwords are in core and are enabled by default, but it's possible a wiki could disable them. OAuth is an extension that the wiki may or may not have installed. [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html -- 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] Why does 1.26 API return hash when 1.24 returned array?
by Daniel Barrett 05 Jan '16

05 Jan '16

Brad Jorsch writes: >$result->addArrayType( null, 'array' ). Thank you, Brad. That fixed the problem! (We are feeding the API results to a third-party module that expects an array.) DanB

1 0

Why does 1.26 API return hash when 1.24 returned array?
by Daniel Barrett 05 Jan '16

05 Jan '16

I'm upgrading my site to MediaWiki 1.26 (from 1.24) and noticed a change in API behavior. One of our custom API modules: http://mywiki.com/w/api.php?action=foobar&format=json...... used to return a JSON array, like this: [ {"start":"2015-12-28","end":"2016-01-01", ...} ] and now it returns a numerically indexed hash like this instead: {"0":{"start":"2016-01-18","end":"2016-01-18", ...}} Do we need to do something special in 1.26 to get the array instead of the hash? Or is this a breaking change? Or are we probably doing something wrong? I looked for breaking API changes in 1.25 and 1.26 but don't see anything like this: https://www.mediawiki.org/wiki/MediaWiki_1.25#API_changes https://www.mediawiki.org/wiki/MediaWiki_1.26#API_changes Thanks, DanB

2 1

Dump corrupted ?
by Luigi Assom 23 Dec '15

23 Dec '15

Hello, not sure if this is the proper mail list to notify - I am experiencing problems with data corrupted on wiki dump. I tried three times to download the last english dump (multistream)

3 3

Public service announcement: Clarification of list=prefixsearch semantics
by Brad Jorsch (Anomie) 21 Dec '15

21 Dec '15

If you're also on wikitech-l, you may have seen the recent announcement[1] of some work by WMF's Discovery team to improve the search results popped up by the search box in wiki pages. Assuming it continues to receive positive feedback, it's rather likely that the code behind their temporary "action=cirrus-suggest" API module will become the backing engine behind action=opensearch and list=prefixsearch. This brought to my attention that "list=prefixsearch" has never been particularly well-documented, so Gerrit change 260383[2] was submitted and merged to clarify the issue. Note this isn't a change in behavior, it's a clarification of the existing behavior to avoid future confusion when that behavior is improved. ApiQueryPrefixSearch was added in Gerrit change 123118[3] to be like action=opensearch but usable as a generator. If your client code is using list=prefixsearch in the expectation that it would work like the similarly-named web UI page Special:PrefixIndex, you should review your usage to make sure that it is actually behaving as you intend. If you are really wanting a list of titles with a prefix rather than a *search* for pages "matching" a prefix in some loosely-defined sense, you should be using list=allpages with the apprefix parameter instead. [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084356.html [2]: https://gerrit.wikimedia.org/r/#/c/260383/ [3]: https://gerrit.wikimedia.org/r/#/c/123118/ -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

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