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
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
With the merge of Gerrit change 324224,[1] action=clearhasmsg will return
an error if used via GET rather than POST. The change should be deployed to
WMF wikis with 1.29.0-wmf.5, see https://www.mediawiki.org/
wiki/MediaWiki_1.29/Roadmap for the schedule.
This should have very low impact: analysis of logs indicates that only
Huggle[2] is using it, and Huggle has already been updated.
[1]: https://gerrit.wikimedia.org/r/#/c/324224/
[2]: https://en.wikipedia.org/wiki/Wikipedia:Huggle
--
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
In Gerrit change 321406[1] and related patches,[2] I've proposed code to
allow the MediaWiki action API to return errors and warnings in languages
other than English. Feedback and code review would be appreciated.
A detailed description of the proposed changes is posted at
https://www.mediawiki.org/wiki/API/Architecture_work/i18n#Warnings_and_erro….
Summary:
- For clients of the API, some error codes will change, particularly
from query submodules. If you're trying to parse the human-readable error
and warning text, these also are likely to change. A few modules that
returned error or warning text in a non-standard manner have been changed.
For the most part, though, client code should not need updating since the
default is backwards-compatible.
- For extension authors, several ApiBase methods are deprecated and
should be replaced. The existing patches[2] may serve as examples.
[1]: https://gerrit.wikimedia.org/r/#/c/321406/
[2]: https://gerrit.wikimedia.org/r/#/q/topic:api-error-i18n/T47843
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hi all!
May I request that some python sample code be posted uploading a local
file, ideally using the requests module (which seems to be relatively
canonical)? I don't think I'm the first to be stymied by mw:API:Upload
(cf. Boxsnake's 18-month old unanswered question at mw:API_talk:Upload
; also
http://stackoverflow.com/questions/33839706/simplest-way-to-upload-a-file-t… where the answer was essentially "give up and use a bot
framework").
Essentially, I cannot seem to avoid getting a "badupload_file"/"File
upload param file is not a file upload; be sure to use
multipart/form-data for your POST and include a filename in the
Content-Disposition header."
I am under the impression I am doing both of those things, my headers are:
{'Content-Type': 'multipart/form-data',
'Content-Disposition': 'form-data; name="file";
filename="storkk_test_upload1.jpg"',
'User-Agent': 'Drudgebane Storkksbot (contact [[C:User:Storkk]]) Based
on python requests/2.11.1',
'Connection': 'keep-alive',
'Content-Length': '93990',
'Cookie': 'forceHTTPS=true; commonswiki_BPsession=...(elided)...',
'Accept-Encoding': 'gzip, deflate',
'Accept': '*/*'}
The full code (with a slightly different filename test), trying a few
different things, is at http://pastebin.com/PxLk85mR
I would greatly appreciate some pointers on where I am going wrong.
Thanks for your time,
storkk
Hi,
This is Eric from Yahoo. My team develops mobile apps for Taiwan and Hong Kong users. We want to provide wiki description on keywords in our contents, and we consider using MediaWiki API:OpenSearch and/or API:Query to achieve this. Our estimated RPS is 900, and we will cache the query result on our side. We would like to know if there is any concern with respect to our RPS, and if so, what is the best practice.
Any comments and suggestions are welcome. Thank you for your time.
Best regards,Eric
I asked:
>Can the MediaWiki API retrieve the HTML of a wiki page, if that page changes its rendering based on the URL query string?
Never mind, I got it working. Just add those URL query parameters to the WebRequest object that's being used:
RequestContext::getMain()->getRequest()->setVal('bar', 1');
Then pass the WebRequest object to the DerivativeRequest (first parameter). Works great!
DanB
Can the MediaWiki API retrieve the HTML of a wiki page, if that page changes its rendering based on the URL query string?
For example, if I have an article “Foo” with the URL:
http://wiki.example.com/wiki/Foo
and it renders *different* HTML if I pass the query parameter “bar”:
http://wiki.example.com/wiki/Foo?bar=1
can the MediaWiki API pass along "bar=1" and retrieve the HTML produced by the second URL?
I know I can retrieve “Foo” using action=’parse’, prop=’text’, page=’Foo’. But I can’t find any way to pass a URL query parameter along with the call and have it take effect.
Thanks for any assistance,
DanB
-----Ursprüngliche Nachricht-----
Von: Mediawiki-api [mailto:mediawiki-api-bounces@lists.wikimedia.org] Im Auftrag von Delia Fernandez
Gesendet: Mittwoch, 02. November 2016 17:32
An: mediawiki-api(a)lists.wikimedia.org
Betreff: [Mediawiki-api] RV: Wikidata API Language not working
Hello,
I'm using the Wikidata api to translate entities ids to its name in English and Spanish. I found out that the language parameter is not working
When I search for the entity id: Q2537 (https://www.wikidata.org/wiki/Q2537)
Search request in English: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Q2537&lan…
Response: {"searchinfo":{"search":"Q2537"},"search":[{"id":"Q2537","concepturi":"http://www.wikidata.org/entity/Q2537","url":"//www.wikidata.org/wiki/Q2537","title":"Q2537","pageid":3505,"label":"natural satellite","description":"celestial body that orbits a planet or smaller body","match":{"type":"entityId","text":"Q2537"},"aliases":["Q2537"]}],"success":1}
Search request in Spanish: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Q2537&lan…
Response: {"searchinfo":{"search":"Q2537"},"search":[{"id":"Q2537","concepturi":"http://www.wikidata.org/entity/Q2537","url":"//www.wikidata.org/wiki/Q2537","title":"Q2537","pageid":3505,"label":"natural satellite","description":"celestial body that orbits a planet or smaller body","match":{"type":"entityId","text":"Q2537"},"aliases":["Q2537"]}],"success":1}
Notice that I'm changing the language parameter, but the results are always in English.
I tried other languages, like fr (French), and the response is also in English.
When I made up a language it gives an error search.
I hope you can attend to this issue,
Thank you.
Dèlia
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Hello,
I'm using the Wikidata api to translate entities ids to its name in English and Spanish. I found out that the language parameter is not working
When I search for the entity id: Q2537 (https://www.wikidata.org/wiki/Q2537)
Search request in English: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Q2537&lan…
Response: {"searchinfo":{"search":"Q2537"},"search":[{"id":"Q2537","concepturi":"http://www.wikidata.org/entity/Q2537","url":"//www.wikidata.org/wiki/Q2537","title":"Q2537","pageid":3505,"label":"natural satellite","description":"celestial body that orbits a planet or smaller body","match":{"type":"entityId","text":"Q2537"},"aliases":["Q2537"]}],"success":1}
Search request in Spanish: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Q2537&lan…
Response: {"searchinfo":{"search":"Q2537"},"search":[{"id":"Q2537","concepturi":"http://www.wikidata.org/entity/Q2537","url":"//www.wikidata.org/wiki/Q2537","title":"Q2537","pageid":3505,"label":"natural satellite","description":"celestial body that orbits a planet or smaller body","match":{"type":"entityId","text":"Q2537"},"aliases":["Q2537"]}],"success":1}
Notice that I'm changing the language parameter, but the results are always in English.
I tried other languages, like fr (French), and the response is also in English.
When I made up a language it gives an error search.
I hope you can attend to this issue,
Thank you.
Dèlia