That is interesting.
I guess that's indeed the correct way, and now I noticed (or maybe I
am reading it wrong) that
mediawiki.org doesn't seem to support them?
Or at least I don't see the word rvslot anywhere in the output of that
very query. If that's the case does it mean that rvslots is optional
feature? Or is that this part of result which indicates they are being
supported?
...
"limit": 500,
"deprecatedvalues": [
"parsetree"
]
},
{
"index": 2,
>>> "name":
"slots", <<<<
"type": [
"main"
],
...
On Mon, Apr 6, 2020 at 3:54 PM Brad Jorsch (Anomie)
<bjorsch(a)wikimedia.org> wrote:
On Sun, Apr 5, 2020 at 5:24 PM Daniel Kinzler <dkinzler(a)wikimedia.org> wrote:
Am 05.04.20 um 23:18 schrieb Petr Bena:
But still, I am curious what is the recommended
approach for someone
who wants to develop their application "properly" in a way that it's
backward compatible? First query the MediaWiki version via API, and
based on that decide how to call APIs? I can't think of any other way.
Yes, that's indeed the only way if the client is to be entirely generic. Though
deprecated API behavior tends to stay supported for quite a while, much longer
than deprecated PHP methods. So checking the MediaWiki version first would only
be needed if you wanted your code to work with a wide range of MediaWiki versions.
Rather than checking the MediaWiki version, I'd generally recommend checking against
the action=paraminfo endpoint for the module in question for something like this. If e.g.
https://www.mediawiki.org/w/api.php?action=paraminfo&modules=query+revi… reports
that rvslots is available then use it, otherwise use back-compat code.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation