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)