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
Hello! Sorry for my bad English.
Through the implementation of the current API impossible to get a random
article in category. This greatly reduces the potential of education
like API, and Wikipedia as a whole.
This is usually not a problem withcategories in which less than 500
catmembers, but to select a random article in categories, wich have more
than hundreds of thousands of catmembers becomes impossible!
Special: RandomInKategory is not a convenient solution for the
developer, since it does not allow to receive pageid and makes writing a
lot of redundant code to get things that are otherwise easily accessible
via the api.
Can we expect that this feature will be available through the API?
Greetings, Wikimeida API Colleagues,
I am working on the application for finding geo-locations of articles of
different language versions of Wikipedia, including articles which need
an illustration: http://ausleuchtung.ch/geo_wiki/ , either by the
coordinates in the articles themselves, or by the wikipedia tag of the
OSM map.
While searching by the coordinates contained in Wikipedia articles the
application basically uses the query:
https://fr.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=700…
Is it possible to modify this query so that it shows only the Wikipedia
articles which do not have any image illustration without looping via
all "pageid"s?
But even with looping, even by checking by each "pageid", I encounter a
problem. For example, these articles have got no illustration:
https://fr.wikipedia.org/?curid=9754525
or
https://fr.wikipedia.org/?curid=8578447
(in this article there is even "image missing" banner).
Still, the following queries show the results with numerous auxiliary
JPG, SVG, and PNG images:
https://fr.wikipedia.org/w/api.php?action=parse&pageid=9754525&prop=imageshttps://fr.wikipedia.org/w/api.php?action=parse&pageid=8578447&prop=images
The application displays geo-locations of articles around the click on
the map, but then I have to open each article by clicking on the link in
the corresponding geo-marker in order to find an article without an
illustration. It is quite time consuming and fault-prone as often there
are dozens of geo-markers, dozens of articles to open.
With best regards,
Oleksiy
We have decided to officially retire the rest.wikimedia.org domain in
favor of /api/rest_v1/ at each individual project domain. For example,
https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
becomes
https://en.wikipedia.org/api/rest_v1/?doc
Most clients already use the new path, and benefit from better
performance from geo-distributed caching, no additional DNS lookups,
and sharing of TLS / HTTP2 connections.
We intend to shut down the rest.wikimedia.org entry point around
March, so please adjust your clients to use /api/rest_v1/ soon.
Thank you for your cooperation,
Gabriel
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
We are planning to enable automatic redirect following in all REST API
[1] HTML entry points on April 25th. When responding to a request for
a redirected title [2], the response headers will contain:
Status: 302
Location: <path-to-redirect-target>
For most clients, this means that their HTTP client will automatically
follow redirects, simplifying common use cases. The few clients with a
need to retrieve the redirect page content itself have two options:
1) Disable following redirects in the client. For HTML and
data-parsoid entry points, the response still includes the HTML body &
regular response headers like the ETag.
2) Send a `?redirect=false` query string parameter. This option is
recommended for browsers, which lack control over redirect behavior
for historical security reasons.
If you do have a need to avoid following redirects, you can make these
changes before the feature is enabled. Internally, we have already
done so for VisualEditor and the Mobile Content Service. See also
https://phabricator.wikimedia.org/T118548 for background & related
discussion.
Let us know if you have any concerns or questions about this.
Thanks,
Gabriel Wicke for the Wikimedia Services Team
[1]: https://en.wikipedia.org/api/rest_v1/?doc (using en.wikipedia.org
as an example)
[2]: https://www.mediawiki.org/wiki/Help:Redirects
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Is it possible to obtain the full HTML of a wiki page via the Mediawiki API? I’m looking for the API equivalent of:
wget https://en.wikipedia.org/wiki/Example
Reason: Our wiki requires a login in order to read articles. So "wget" produces only a "Login required" page. I can log in via API, but can't figure out how to obtain the HTML, just the wikitext (action=query, prop=revisions, rvprop = content).
Other solutions are welcome too....
Thanks,
DanB