(bug 43251) API prop=pageprops ppprop should accept multiple values

There is no reason for this parameter not to accept multiple values, the
query is structurally exactly the same as for something like
prop=categories&clcategories=....

Unless, of course, we need to support page props with "|" in the name.

Change-Id: I38cd83e213ede8e626d55c079c5c1b6f7e727336
This commit is contained in:
Brad Jorsch 2012-12-31 14:15:50 -05:00
parent 857ffcafd6
commit 0ae0c665f5
2 changed files with 9 additions and 3 deletions

View file

@ -212,6 +212,7 @@ production.
iicontinue).
* Add supports for all pageset capabilities - generators, redirects, converttitles to
action=purge and action=setnotificationtimestamp.
* (bug 43251) prop=pageprops&ppprop= now accepts multiple props to query.
=== API internal changes in 1.21 ===
* For debugging only, a new global $wgDebugAPI removes many API restrictions when true.

View file

@ -60,7 +60,10 @@ class ApiQueryPageProps extends ApiQueryBase {
}
# Force a sort order to ensure that properties are grouped by page
$this->addOption( 'ORDER BY', 'pp_page' );
# But only if pp_page is not constant in the WHERE clause.
if ( count( $pages ) > 1 ) {
$this->addOption( 'ORDER BY', 'pp_page' );
}
$res = $this->select( __METHOD__ );
$currentPage = 0; # Id of the page currently processed
@ -122,14 +125,16 @@ class ApiQueryPageProps extends ApiQueryBase {
public function getAllowedParams() {
return array(
'continue' => null,
'prop' => null,
'prop' => array(
ApiBase::PARAM_ISMULTI => true,
),
);
}
public function getParamDescription() {
return array(
'continue' => 'When more results are available, use this to continue',
'prop' => 'Page prop to look on the page for. Useful for checking whether a certain page uses a certain page prop.'
'prop' => 'Only list these props. Useful for checking whether a certain page uses a certain page prop',
);
}