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)
<bjor...@wikimedia.org> wrote:
>
> On Sun, Apr 5, 2020 at 5:24 PM Daniel Kinzler <dkinz...@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+revisions
> reports that rvslots is available then use it, otherwise use back-compat code.
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
