As of r35104 [1], the handling of invalid value for multivalue parameters has changed. If the API encounters an invalid value, it doesn't exit with an error like it used to, but throws a warning and ignores the invalid value. Handling of single value parameters hasn't changed: the API still exists with an error when that happens. Note that one letter in the associated error message *has* changed, recogniSed has been changed to recogniZed (shouldn't matter much as you should go by the error code rather than the info text anyway, it's much shorter). Also note that multiple warnings may occur for the same module, in which case the two warnings are separated by a newline (r35107 [2]). This is also demonstrated in example 1.

This behavior may cause unexpected behavior when misspelling parameters: rather than an error, you'll get a result which omits an entire element completely. Your result might even be empty apart from the <warnings> element. The advantage is that requesting a property that was added in 1.14 won't break on 1.13 (I'll suggest backporting this fix for that reason).

Two sample requests:

api.php?action=query&meta=siteinfo|foo&siprop=dbrepllag|bar|baz&prop=blah

<?xml version="1.0" encoding="utf-8"?> <api> <warnings> <query>Unrecognized value for parameter 'prop': blah Unrecognized value for parameter 'meta': foo</query> <siteinfo>Unrecognized values for parameter 'siprop': bar, baz</siteinfo> </warnings> <query> <dbrepllag> <db host="" lag="-1" /> </dbrepllag> </query> </api>

api.php?action=query&prop=revisions&rvdir=foo

<api> <error code="rvunknown_rvdir" info="Unrecognized value for parameter 'rvdir': foo"/> </api>

Roan Kattouw (Catrope)