wiki.techinc.nl/includes/api/ApiQueryBase.php

628 lines
19 KiB
PHP
Raw Normal View History

<?php
/**
* Copyright © 2006 Yuri Astrakhan "<Firstname><Lastname>@gmail.com"
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
*/
use MediaWiki\MediaWikiServices;
use MediaWiki\Title\Title;
use Wikimedia\Rdbms\IDatabase;
use Wikimedia\Rdbms\IReadableDatabase;
use Wikimedia\Rdbms\IResultWrapper;
use Wikimedia\Rdbms\SelectQueryBuilder;
/**
2007-05-20 23:31:44 +00:00
* This is a base class for all Query modules.
* It provides some common functionality such as constructing various SQL
* queries.
*
* @stable to extend
*
* @ingroup API
*/
abstract class ApiQueryBase extends ApiBase {
use ApiQueryBlockInfoTrait;
private $mQueryModule, $mDb;
/**
* @var SelectQueryBuilder|null
*/
private $queryBuilder;
/**
* @stable to call
* @param ApiQuery $queryModule
* @param string $moduleName
* @param string $paramPrefix
*/
public function __construct( ApiQuery $queryModule, $moduleName, $paramPrefix = '' ) {
parent::__construct( $queryModule->getMain(), $moduleName, $paramPrefix );
$this->mQueryModule = $queryModule;
$this->mDb = null;
$this->resetQueryParams();
}
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
/***************************************************************************/
// region Methods to implement
/** @name Methods to implement */
/**
* Get the cache mode for the data generated by this module. Override
* this in the module subclass. For possible return values and other
* details about cache modes, see ApiMain::setCacheMode()
*
* Public caching will only be allowed if *all* the modules that supply
* data for a given request return a cache mode of public.
*
* @stable to override
* @param array $params
* @return string
*/
public function getCacheMode( $params ) {
return 'private';
}
/**
* Override this method to request extra fields from the pageSet
* using $pageSet->requestField('fieldName')
*
* Note this only makes sense for 'prop' modules, as 'list' and 'meta'
* modules should not be using the pageset.
*
* @stable to override
* @param ApiPageSet $pageSet
*/
public function requestExtraData( $pageSet ) {
}
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
// endregion -- end of methods to implement
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
/***************************************************************************/
// region Data access
/** @name Data access */
/**
* Get the main Query module
* @return ApiQuery
*/
public function getQuery() {
return $this->mQueryModule;
}
/** @inheritDoc */
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
public function getParent() {
return $this->getQuery();
}
/**
* Get the Query database connection (read-only)
* @stable to override
* @return IReadableDatabase
*/
protected function getDB() {
$this->mDb ??= $this->getQuery()->getDB();
return $this->mDb;
}
/**
* Get the PageSet object to work on
* @stable to override
* @return ApiPageSet
*/
protected function getPageSet() {
return $this->getQuery()->getPageSet();
}
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
// endregion -- end of data access
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
/***************************************************************************/
// region Querying
/** @name Querying */
/**
* Blank the internal arrays with query parameters
*/
protected function resetQueryParams() {
$this->queryBuilder = null;
}
/**
* Get the SelectQueryBuilder.
*
* This is lazy initialised since getDB() fails in ApiQueryAllImages if it
* is called before the constructor completes.
*
* @return SelectQueryBuilder
*/
protected function getQueryBuilder() {
$this->queryBuilder ??= $this->getDB()->newSelectQueryBuilder();
return $this->queryBuilder;
}
/**
* Add a set of tables to the internal array
* @param string|array $tables Table name or array of table names
* or nested arrays for joins using parentheses for grouping
* @param string|null $alias Table alias, or null for no alias. Cannot be
* used with multiple tables
*/
protected function addTables( $tables, $alias = null ) {
if ( is_array( $tables ) ) {
if ( $alias !== null ) {
ApiBase::dieDebug( __METHOD__, 'Multiple table aliases not supported' );
}
$this->getQueryBuilder()->rawTables( $tables );
} else {
$this->getQueryBuilder()->table( $tables, $alias );
}
}
/**
* Add a set of JOIN conditions to the internal array
*
* JOIN conditions are formatted as [ tablename => [ jointype, conditions ] ]
* e.g. [ 'page' => [ 'LEFT JOIN', 'page_id=rev_page' ] ].
* Conditions may be a string or an addWhere()-style array.
* @param array $join_conds JOIN conditions
*/
protected function addJoinConds( $join_conds ) {
if ( !is_array( $join_conds ) ) {
ApiBase::dieDebug( __METHOD__, 'Join conditions have to be arrays' );
}
$this->getQueryBuilder()->joinConds( $join_conds );
}
/**
* Add a set of fields to select to the internal array
* @param array|string $value Field name or array of field names
*/
protected function addFields( $value ) {
$this->getQueryBuilder()->fields( $value );
}
/**
* Same as addFields(), but add the fields only if a condition is met
* @param array|string $value See addFields()
* @param bool $condition If false, do nothing
* @return bool
*/
protected function addFieldsIf( $value, $condition ) {
if ( $condition ) {
$this->addFields( $value );
return true;
}
return false;
}
/**
* Add a set of WHERE clauses to the internal array.
*
* The array should be appropriate for passing as $conds to
* IDatabase::select(). Arrays from multiple calls are merged with
* array_merge(). A string is treated as a single-element array.
*
* When passing `'field' => $arrayOfIDs` where the IDs are taken from user
* input, consider using addWhereIDsFld() instead.
*
* @see IDatabase::select()
* @param string|array $value
*/
protected function addWhere( $value ) {
if ( is_array( $value ) ) {
// Double check: don't insert empty arrays,
// Database::makeList() chokes on them
if ( count( $value ) ) {
$this->getQueryBuilder()->where( $value );
}
} else {
$this->getQueryBuilder()->where( $value );
}
}
/**
* Same as addWhere(), but add the WHERE clauses only if a condition is met
* @param string|array $value
* @param bool $condition If false, do nothing
* @return bool
*/
protected function addWhereIf( $value, $condition ) {
if ( $condition ) {
$this->addWhere( $value );
return true;
}
return false;
}
/**
* Equivalent to addWhere( [ $field => $value ] )
*
* When $value is an array of integer IDs taken from user input,
* consider using addWhereIDsFld() instead.
*
* @param string $field Field name
* @param int|string|(string|int|null)[] $value Value; ignored if null or empty array
*/
protected function addWhereFld( $field, $value ) {
if ( $value !== null && !( is_array( $value ) && !$value ) ) {
$this->getQueryBuilder()->where( [ $field => $value ] );
}
}
/**
* Like addWhereFld for an integer list of IDs
*
* When passed wildly out-of-range values for integer comparison,
* the database may choose a poor query plan. This method validates the
* passed IDs against the range of values in the database to omit
* out-of-range values.
*
* This should be used when the IDs are derived from arbitrary user input;
* it is not necessary if the IDs are already known to be within a sensible
* range.
*
* This should not be used when there is not a suitable index on $field to
* quickly retrieve the minimum and maximum values.
*
* @since 1.33
* @param string $table Table name
* @param string $field Field name
* @param int[] $ids
* @return int Count of IDs actually included
*/
protected function addWhereIDsFld( $table, $field, $ids ) {
// Use count() to its full documented capabilities to simultaneously
// test for null, empty array or empty countable object
if ( count( $ids ) ) {
$ids = $this->filterIDs( [ [ $table, $field ] ], $ids );
if ( $ids === [] ) {
// Return nothing, no IDs are valid
$this->getQueryBuilder()->where( '0 = 1' );
} else {
$this->getQueryBuilder()->where( [ $field => $ids ] );
}
}
return count( $ids );
}
/**
* Add a WHERE clause corresponding to a range, and an ORDER BY
* clause to sort in the right direction
* @param string $field Field name
* @param string $dir If 'newer', sort in ascending order, otherwise
* sort in descending order
* @param string|int|null $start Value to start the list at. If $dir == 'newer'
* this is the lower boundary, otherwise it's the upper boundary
* @param string|int|null $end Value to end the list at. If $dir == 'newer' this
* is the upper boundary, otherwise it's the lower boundary
* @param bool $sort If false, don't add an ORDER BY clause
*/
protected function addWhereRange( $field, $dir, $start, $end, $sort = true ) {
$isDirNewer = ( $dir === 'newer' );
$after = ( $isDirNewer ? '>=' : '<=' );
$before = ( $isDirNewer ? '<=' : '>=' );
Prevent the following strict-standards warnings - i.e. when running with error_logging(E_ALL | E_STRICT); - which seems to disable the yucky "@" operator, as well as maxing out the pedantry of warnings. Nothing major found, just nice to be as explicit and as forward-compatible as possible. * Strict Standards: Undefined index: switch in includes/Parser.php on line 3849 * Strict Standards: Undefined index: ref in includes/Parser.php on line 3818 * Strict Standards: Non-static method OutputPage::setEncodings() should not be called statically in index.php on line 11 * Strict Standards: Only variables should be assigned by reference in includes/Skin.php on line 888 * Strict Standards: Non-static method Title::newFromURL() should not be called statically in includes/SpecialContributions.php on line 178 * Strict Standards: Only variables should be assigned by reference in includes/GlobalFunctions.php on line 2054 * Strict Standards: Undefined index: contributions-summary in languages/Language.php on line 764 * Strict Standards: Undefined index: trackbackhtml in skins/MonoBook.php on line 86 * Strict Standards: Undefined index: blockip in skins/MonoBook.php on line 204 * Strict Standards: Undefined index: tagline in skins/MonoBook.php on line 261 * Strict Standards: Undefined index: uselang in includes/SkinTemplate.php on line 1159 * Strict Standards: Non-static method CoreParserFunctions::plural() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Undefined offset: 0 in includes/SkinTemplate.php on line 196 * Strict Standards: Undefined index: USE INDEX in includes/Database.php on line 1015 * Strict Standards: Undefined index: image_tests in includes/Parser.php on line 3488 * Strict Standards: Undefined offset: 0 in includes/Parser.php on line 3507 * Strict Standards: Non-static method ChangesList::newFromUser() should not be called statically in includes/SpecialWatchlist.php on line 361 * Strict Standards: Non-static method RecentChange::newFromCurRow() should not be called statically in includes/SpecialWatchlist.php on line 367 * Strict Standards: is_a(): Deprecated. Please use the instanceof operator in includes/Exception.php on line 168 * Strict Standards: Non-static method LogPage::logName() should not be called statically in includes/SpecialContributions.php on line 325 * Strict Standards: ob_end_flush(): failed to delete and flush buffer. No buffer to delete or flush. in maintenance/commandLine.inc on line 191 * Strict Standards: Undefined index: meatball in languages/Language.php on line 234 * Strict Standards: rmdir(/tmp/mwParser-2108164586-images/thumb): Directory not empty in maintenance/parserTests.inc on line 605 * Cleaning out some new temp files left over by parserTests (there were one or two straggler dirs/files that would persist after the test run ended, due to new tests being added over time) * Strict Standards: Non-static method CoreParserFunctions::special() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Declaration of ListUsersPage::preprocessResults() should be compatible with that of QueryPage::preprocessResults() in includes/SpecialListusers.php on line 38 * Strict Standards: Only variables should be passed by reference in includes/SpecialBlockip.php on line 175 * Strict Standards: Skin::include_once(skins/Standard.deps.php) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory in includes/Skin.php on line 121 * Strict Standards: Declaration of ApiMain::getResult() should be compatible with that of ApiBase::getResult() in includes/api/ApiMain.php on line 35 * Strict Standards: is_a(): Deprecated. Please use the instanceof operator in includes/WikiError.php on line 63 * Strict Standards: Non-static method WikiError::isError() should not be called statically in includes/SpecialImport.php on line 64 * Strict Standards: Non-static method ImportStreamSource::newFromInterwiki() should not be called statically in includes/SpecialImport.php on line 58<b * Strict Standards: Only variables should be assigned by reference in includes/SpecialUndelete.php on line 501 * Strict Standards: Non-static method Image::newFromName() should not be called statically in thumb.php on line 56 * Strict Standards: Non-static method CoreParserFunctions::numberoffiles() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Non-static method CoreParserFunctions::statisticsFunction() should not be called statically in includes/CoreParserFunctions.php on line 139 * Strict Standards: Non-static method CoreParserFunctions::isRaw() should not be called statically in includes/CoreParserFunctions.php on line 128 * Strict Standards: Non-static method CoreParserFunctions::grammar() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Undefined offset: 1 in includes/SpecialMIMEsearch.php on line 130 * Strict Standards: Undefined index: recentchangeslinked in skins/MonoBook.php on line 184 * Strict Standards: Declaration of DumpNotalkFilter::pass() should be compatible with that of DumpFilter::pass() in includes/Export.php on line 612 * Strict Standards: Declaration of DumpNamespaceFilter::pass() should be compatible with that of DumpFilter::pass() in includes/Export.php on line 665 * Strict Standards: Non-static method ImportStreamSource::newFromUpload() should not be called statically in includes/SpecialImport.php on line 46 * Strict Standards: Undefined offset: 5 in includes/Sanitizer.php on line 396 * Strict Standards: Undefined index: wikidbUserName in includes/SpecialUserlogin.php on line 562 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryBase.php on line 95 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryBase.php on line 116 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryWatchlist.php on line 128 * Strict Standards: Undefined property: stdClass::$rc_id in includes/api/ApiQueryBase.php on line 131 * Strict Standards: Undefined property: stdClass::$rc_last_oldid in includes/api/ApiQueryBase.php on line 164 * Strict Standards: Undefined property: stdClass::$rc_moved_to_ns in includes/api/ApiQueryBase.php on line 285 * Strict Standards: Undefined property: stdClass::$rc_patrolled in includes/api/ApiQueryBase.php on line 176 * Strict Standards: Undefined index: comment in includes/api/ApiFeedWatchlist.php on line 85 * Strict Standards: Undefined offset: 0 in includes/Skin.php on line 302 * Strict Standards: Non-static method User::SetupSession() should not be called statically in includes/SpecialUserlogin.php on line 15 ... There are certain to be other things too, so this is not intended to be comprehensive, rather the above just stops most of the notifications I observed.
2006-11-29 05:45:03 +00:00
$db = $this->getDB();
if ( $start !== null ) {
$this->addWhere( $field . $after . $db->addQuotes( $start ) );
}
if ( $end !== null ) {
$this->addWhere( $field . $before . $db->addQuotes( $end ) );
}
if ( $sort ) {
$this->getQueryBuilder()->orderBy( $field, $isDirNewer ? null : 'DESC' );
}
}
/**
* Add a WHERE clause corresponding to a range, similar to addWhereRange,
* but converts $start and $end to database timestamps.
* @see addWhereRange
* @param string $field
* @param string $dir
* @param string|int|null $start
* @param string|int|null $end
* @param bool $sort
*/
protected function addTimestampWhereRange( $field, $dir, $start, $end, $sort = true ) {
$db = $this->getDB();
$this->addWhereRange( $field, $dir,
2011-10-07 19:11:08 +00:00
$db->timestampOrNull( $start ), $db->timestampOrNull( $end ), $sort );
}
/**
* Add an option such as LIMIT or USE INDEX. If an option was set
* before, the old value will be overwritten
* @param string $name Option name
* @param mixed $value The option value, or null for a boolean option
*/
protected function addOption( $name, $value = null ) {
$this->getQueryBuilder()->option( $name, $value );
}
/**
* Execute a SELECT query based on the values in the internal arrays
* @param string $method Function the query should be attributed to.
* You should usually use __METHOD__ here
* @param array $extraQuery Query data to add but not store in the object
* Format is [
* 'tables' => ...,
* 'fields' => ...,
* 'where' => ...,
* 'options' => ...,
* 'join_conds' => ...
* ]
* @param array|null &$hookData If set, the ApiQueryBaseBeforeQuery and
* ApiQueryBaseAfterQuery hooks will be called, and the
* ApiQueryBaseProcessRow hook will be expected.
* @return IResultWrapper
*/
protected function select( $method, $extraQuery = [], array &$hookData = null ) {
$queryBuilder = clone $this->getQueryBuilder();
if ( isset( $extraQuery['tables'] ) ) {
$queryBuilder->rawTables( (array)$extraQuery['tables'] );
}
if ( isset( $extraQuery['fields'] ) ) {
$queryBuilder->fields( (array)$extraQuery['fields'] );
}
if ( isset( $extraQuery['where'] ) ) {
$queryBuilder->where( (array)$extraQuery['where'] );
}
if ( isset( $extraQuery['options'] ) ) {
$queryBuilder->options( (array)$extraQuery['options'] );
}
if ( isset( $extraQuery['join_conds'] ) ) {
$queryBuilder->joinConds( (array)$extraQuery['join_conds'] );
}
if ( $hookData !== null && $this->getHookContainer()->isRegistered( 'ApiQueryBaseBeforeQuery' ) ) {
$info = $queryBuilder->getQueryInfo();
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
$this->getHookRunner()->onApiQueryBaseBeforeQuery(
$this, $info['tables'], $info['fields'], $info['conds'],
$info['options'], $info['join_conds'], $hookData
);
$queryBuilder = $this->getDB()->newSelectQueryBuilder()->queryInfo( $info );
}
$queryBuilder->caller( $method );
$res = $queryBuilder->fetchResultSet();
if ( $hookData !== null ) {
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
$this->getHookRunner()->onApiQueryBaseAfterQuery( $this, $res, $hookData );
}
return $res;
}
/**
* Call the ApiQueryBaseProcessRow hook
*
* Generally, a module that passed $hookData to self::select() will call
* this just before calling ApiResult::addValue(), and treat a false return
* here in the same way it treats a false return from addValue().
*
* @since 1.28
* @param stdClass $row Database row
* @param array &$data Data to be added to the result
* @param array &$hookData Hook data from ApiQueryBase::select() @phan-output-reference
* @return bool Return false if row processing should end with continuation
*/
protected function processRow( $row, array &$data, array &$hookData ) {
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
return $this->getHookRunner()->onApiQueryBaseProcessRow( $this, $row, $data, $hookData );
}
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
// endregion -- end of querying
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
/***************************************************************************/
// region Utility methods
/** @name Utility methods */
/**
* Add information (title and namespace) about a Title object to a
* result array
* @param array &$arr Result array à la ApiResult
* @param Title $title
* @param string $prefix Module prefix
*/
public static function addTitleInfo( &$arr, $title, $prefix = '' ) {
$arr[$prefix . 'ns'] = $title->getNamespace();
$arr[$prefix . 'title'] = $title->getPrefixedText();
}
/**
* Add a sub-element under the page element with the given page ID
* @param int $pageId
* @param array $data Data array à la ApiResult
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
* @return bool Whether the element fit in the result
*/
protected function addPageSubItems( $pageId, $data ) {
$result = $this->getResult();
API: Overhaul ApiResult, make format=xml not throw, and add json formatversion ApiResult was a mess: some methods could only be used with an array reference instead of manipulating the stored data, methods that had both array-ref and internal-data versions had names that didn't at all correspond, some methods that worked on an array reference were annoyingly non-static, and then the whole mess with setIndexedTagName. ApiFormatXml is also entirely annoying to deal with, as it liked to throw exceptions if certain metadata wasn't provided that no other formatter required. Its legacy also means we have this silly convention of using empty-string rather than boolean true, annoying restrictions on keys (leading to things that should be hashes being arrays of key-value object instead), '*' used as a key all over the place, and so on. So, changes here: * ApiResult is no longer an ApiBase or a ContextSource. * Wherever sensible, ApiResult provides a static method working on an arrayref and a non-static method working on internal data. * Metadata is now always added to ApiResult's internal data structure. Formatters are responsible for stripping it if necessary. "raw mode" is deprecated. * New metadata to replace the '*' key, solve the array() => '[]' vs '{}' question, and so on. * New class for formatting warnings and errors using i18n messages, and support for multiple errors and a more machine-readable format for warnings. For the moment, though, the actual output will not be changing yet (see T47843 for future plans). * New formatversion parameter for format=json and format=php, to select between BC mode and the modern output. * In BC mode, booleans will be converted to empty-string presence style; modules currently returning booleans will need to use ApiResult::META_BC_BOOLS to preserve their current output. Actual changes to the API modules' output (e.g. actually returning booleans for the new formatversion) beyond the use of ApiResult::setContentValue() are left for a future change. Bug: T76728 Bug: T57371 Bug: T33629 Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
2014-12-03 22:14:22 +00:00
ApiResult::setIndexedTagName( $data, $this->getModulePrefix() );
return $result->addValue( [ 'query', 'pages', (int)$pageId ],
$this->getModuleName(),
$data );
}
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
/**
* Same as addPageSubItems(), but one element of $data at a time
* @param int $pageId
* @param mixed $item Data à la ApiResult
* @param string|null $elemname XML element name. If null, getModuleName()
* is used
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
* @return bool Whether the element fit in the result
*/
protected function addPageSubItem( $pageId, $item, $elemname = null ) {
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
$result = $this->getResult();
$fit = $result->addValue( [ 'query', 'pages', $pageId,
$this->getModuleName() ], null, $item );
if ( !$fit ) {
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
return false;
}
$result->addIndexedTagName(
[ 'query', 'pages', $pageId, $this->getModuleName() ],
$elemname ?? $this->getModulePrefix()
);
* API: BREAKING CHANGE: (bug 11430) Return fewer results than the limit in some cases to prevent running out of memory * This means queries could possibly return fewer results than the limit and still set a query-continue * Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules * Implemented by blocking additions to the ApiResult object if they would make it too large ** Important things like query-continue values and warnings are exempt from this check ** RSS feeds and exported XML are also exempted (size-checking them would be too messy) ** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB For those who really care, per-file details follow: ApiResult.php: * Introduced ApiResult::$mSize which keeps track of the result size. * Introduced ApiResult::size() which calculates an array's size (which is the sum of the strlen()s of its elements). * ApiResult::addValue() now checks that the result size stays below $wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue() will return false. Callers should check the return value and set a query-continue if it's false. * Closed the back door that is ApiResult::getData(): callers can't manipulate the data array directly anymore so they can't bypass the result size limit. * Added ApiResult::setIndexedTagName_internal() which will call setIndexedTagName() on an array already in the result. This is needed for the 'new' order of adding results, which means addValue()ing one result at a time until you hit the limit or run out, then calling this function to set the tag name. * Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and enable size checking in addValue(). This is used for stuff like query-continue elements and warnings which shouldn't count towards the result size. * Added ApiResult::unsetValue() which removes an element from the result and decreases $mSize. ApiBase.php: * Like ApiResult::getData(), ApiBase::getResultData() no longer returns a reference. * Use ApiResult::disableSizeCheck() in ApiBase::setWarning() ApiQueryBase.php: * Added ApiQueryBase::addPageSubItem(), which adds page subitems one item at a time. * addPageSubItem() and addPageSubItems() now return whether the subitem fit in the result. * Use ApiResult::disableSizeCheck() in setContinueEnumParameter() ApiMain.php: * Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError() * Use getParameter() rather than $mRequest to obtain requestid DefaultSettings.php: * Added $wgAPIMaxResultSize, with a default value of 8 MB ApiQuery*.php: * Added results one at a time, and set a query-continue if the result is full. ApiQueryLangLinks.php and friends: * Migrated from addPageSubItems() to addPageSubItem(). This eliminates the need for $lastId. ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php: * Renamed $data to something more appropriate ($pageids, $ids or $titles) ApiQuerySiteinfo.php: * Abuse siprop as a query-continue parameter and set it to all props that couldn't be processed. ApiQueryRandom.php: * Doesn't do continuations, because the result is supposed to be random. * Be smart enough to not run the second query if the results of the first didn't fit. ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php: * Added continue parameter which basically skips the first so many items ApiQueryBacklinks.php: * Throw the result in a big array first and addValue() that one element at a time if necessary ** This is necessary because the results aren't retrieved in order * Introduced $this->pageMap to map namespace and title to page ID * Rewritten extractRowInfo() and extractRedirRowInfo() a little * Declared all private member variables explicitly ApiQueryDeletedrevs.php: * Use a pagemap just like in Backlinks * Introduce fake page IDs and keep track of them so we know where to add what ** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive ApiQueryAllmessages.php: * Add amfrom to facilitate query-continue ApiQueryUsers.php: * Rewrite: put the getOtherUsersInfo() code in execute()
2009-02-05 14:30:59 +00:00
return true;
}
/**
* Set a query-continue value
* @param string $paramName Parameter name
* @param int|string|array $paramValue Parameter value
*/
protected function setContinueEnumParameter( $paramName, $paramValue ) {
API: Overhaul ApiResult, make format=xml not throw, and add json formatversion ApiResult was a mess: some methods could only be used with an array reference instead of manipulating the stored data, methods that had both array-ref and internal-data versions had names that didn't at all correspond, some methods that worked on an array reference were annoyingly non-static, and then the whole mess with setIndexedTagName. ApiFormatXml is also entirely annoying to deal with, as it liked to throw exceptions if certain metadata wasn't provided that no other formatter required. Its legacy also means we have this silly convention of using empty-string rather than boolean true, annoying restrictions on keys (leading to things that should be hashes being arrays of key-value object instead), '*' used as a key all over the place, and so on. So, changes here: * ApiResult is no longer an ApiBase or a ContextSource. * Wherever sensible, ApiResult provides a static method working on an arrayref and a non-static method working on internal data. * Metadata is now always added to ApiResult's internal data structure. Formatters are responsible for stripping it if necessary. "raw mode" is deprecated. * New metadata to replace the '*' key, solve the array() => '[]' vs '{}' question, and so on. * New class for formatting warnings and errors using i18n messages, and support for multiple errors and a more machine-readable format for warnings. For the moment, though, the actual output will not be changing yet (see T47843 for future plans). * New formatversion parameter for format=json and format=php, to select between BC mode and the modern output. * In BC mode, booleans will be converted to empty-string presence style; modules currently returning booleans will need to use ApiResult::META_BC_BOOLS to preserve their current output. Actual changes to the API modules' output (e.g. actually returning booleans for the new formatversion) beyond the use of ApiResult::setContentValue() are left for a future change. Bug: T76728 Bug: T57371 Bug: T33629 Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
2014-12-03 22:14:22 +00:00
$this->getContinuationManager()->addContinueParam( $this, $paramName, $paramValue );
}
/**
* Convert an input title or title prefix into a dbkey.
*
* $namespace should always be specified in order to handle per-namespace
* capitalization settings.
*
* @param string $titlePart
* @param int $namespace Namespace of the title
* @return string DBkey (no namespace prefix)
*/
public function titlePartToKey( $titlePart, $namespace = NS_MAIN ) {
$t = Title::makeTitleSafe( $namespace, $titlePart . 'x' );
if ( !$t || $t->hasFragment() ) {
// Invalid title (e.g. bad chars) or contained a '#'.
$this->dieWithError( [ 'apierror-invalidtitle', wfEscapeWikiText( $titlePart ) ] );
}
if ( $namespace != $t->getNamespace() || $t->isExternal() ) {
// This can happen in two cases. First, if you call titlePartToKey with a title part
// that looks like a namespace, but with $defaultNamespace = NS_MAIN. It would be very
// difficult to handle such a case. Such cases cannot exist and are therefore treated
// as invalid user input. The second case is when somebody specifies a title interwiki
// prefix.
$this->dieWithError( [ 'apierror-invalidtitle', wfEscapeWikiText( $titlePart ) ] );
}
return substr( $t->getDBkey(), 0, -1 );
}
/**
* Convert an input title or title prefix into a TitleValue.
*
* @since 1.35
* @param string $titlePart
* @param int $defaultNamespace Default namespace if none is given
* @return TitleValue
*/
protected function parsePrefixedTitlePart( $titlePart, $defaultNamespace = NS_MAIN ) {
try {
$titleParser = MediaWikiServices::getInstance()->getTitleParser();
$t = $titleParser->parseTitle( $titlePart . 'X', $defaultNamespace );
} catch ( MalformedTitleException $e ) {
$t = null;
}
if ( !$t || $t->hasFragment() || $t->isExternal() || $t->getDBkey() === 'X' ) {
// Invalid title (e.g. bad chars) or contained a '#'.
$this->dieWithError( [ 'apierror-invalidtitle', wfEscapeWikiText( $titlePart ) ] );
}
return new TitleValue( $t->getNamespace(), substr( $t->getDBkey(), 0, -1 ) );
}
/**
* @param string $hash
* @return bool
*/
public function validateSha1Hash( $hash ) {
return (bool)preg_match( '/^[a-f0-9]{40}$/', $hash );
}
/**
* @param string $hash
* @return bool
*/
public function validateSha1Base36Hash( $hash ) {
return (bool)preg_match( '/^[a-z0-9]{31}$/', $hash );
}
Improve API query RevDel handling * ApiQueryDeletedrevs, ApiQueryFilearchive, ApiQueryRecentChanges, and ApiQueryWatchlist will now return entires where fields have been revision-deleted. "Hidden" indicators will be provided as appropriate. * ApiQueryImageInfo, ApiQueryLogEvents, ApiQueryRevisions, ApiQueryContributions will now return field values in addition to the "hidden" indicators when the requesting user has the necessary rights. * Modules that return "hidden" indicators will now also return a "suppressed" indicator. * ApiQueryImageInfo will now return info for DELETED_FILE file revisions if the requesting user has the 'deletedtext' right. * ApiQueryLogEvents, when searching by user or title, will now return entries where the user or action are revision-deleted if the requesting user has the 'deletedhistory' right. * ApiQueryContributions now uses the correct user rights rather than 'hideuser' to determine when to show contributions where the username was revision-deleted. * ApiQueryContributions will now indicate when the revision text is hidden. * Fix a bug in ApiQueryDeletedrevs found during testing where specifying the "content" prop along with the "tags" prop or "drtag" parameter would cause an SQL error. * Fix various PHP warnings in ApiQueryFilearchive caused by the lack of ArchivedFile::selectFields() fields. * ApiQueryImageInfo::getInfo's $metadataOpts parameter has been renamed $opts, and now may have an option to indicate the user to use for RevDel visibility checks. * ApiQueryWatchlist now properly uses the actual user's rights for checking whether wlprop=patrol is allowed, rather than using the wlowner's rights. Bug: 27747 Bug: 27748 Bug: 28261 Bug: 34926 Bug: 48966 Change-Id: Idec2199976f460e1c73a26d0717e9fc4ab8042bb
2013-12-18 21:58:39 +00:00
/**
* Check whether the current user has permission to view revision-deleted
* fields.
* @return bool
*/
public function userCanSeeRevDel() {
return $this->getAuthority()->isAllowedAny(
'deletedhistory',
'deletedtext',
'deleterevision',
'suppressrevision',
'viewsuppressed'
);
Improve API query RevDel handling * ApiQueryDeletedrevs, ApiQueryFilearchive, ApiQueryRecentChanges, and ApiQueryWatchlist will now return entires where fields have been revision-deleted. "Hidden" indicators will be provided as appropriate. * ApiQueryImageInfo, ApiQueryLogEvents, ApiQueryRevisions, ApiQueryContributions will now return field values in addition to the "hidden" indicators when the requesting user has the necessary rights. * Modules that return "hidden" indicators will now also return a "suppressed" indicator. * ApiQueryImageInfo will now return info for DELETED_FILE file revisions if the requesting user has the 'deletedtext' right. * ApiQueryLogEvents, when searching by user or title, will now return entries where the user or action are revision-deleted if the requesting user has the 'deletedhistory' right. * ApiQueryContributions now uses the correct user rights rather than 'hideuser' to determine when to show contributions where the username was revision-deleted. * ApiQueryContributions will now indicate when the revision text is hidden. * Fix a bug in ApiQueryDeletedrevs found during testing where specifying the "content" prop along with the "tags" prop or "drtag" parameter would cause an SQL error. * Fix various PHP warnings in ApiQueryFilearchive caused by the lack of ArchivedFile::selectFields() fields. * ApiQueryImageInfo::getInfo's $metadataOpts parameter has been renamed $opts, and now may have an option to indicate the user to use for RevDel visibility checks. * ApiQueryWatchlist now properly uses the actual user's rights for checking whether wlprop=patrol is allowed, rather than using the wlowner's rights. Bug: 27747 Bug: 27748 Bug: 28261 Bug: 34926 Bug: 48966 Change-Id: Idec2199976f460e1c73a26d0717e9fc4ab8042bb
2013-12-18 21:58:39 +00:00
}
/**
* Preprocess the result set to fill the GenderCache with the necessary information
* before using self::addTitleInfo
*
* @param IResultWrapper $res Result set to work on.
* The result set must have _namespace and _title fields with the provided field prefix
* @param string $fname The caller function name, always use __METHOD__
* @param string $fieldPrefix Prefix for fields to check gender for
*/
protected function executeGenderCacheFromResultWrapper(
IResultWrapper $res, $fname = __METHOD__, $fieldPrefix = 'page'
) {
if ( !$res->numRows() ) {
return;
}
$services = MediaWikiServices::getInstance();
if ( !$services->getContentLanguage()->needsGenderDistinction() ) {
return;
}
$nsInfo = $services->getNamespaceInfo();
$namespaceField = $fieldPrefix . '_namespace';
$titleField = $fieldPrefix . '_title';
$usernames = [];
foreach ( $res as $row ) {
if ( $nsInfo->hasGenderDistinction( $row->$namespaceField ) ) {
$usernames[] = $row->$titleField;
}
}
if ( $usernames === [] ) {
return;
}
$genderCache = $services->getGenderCache();
$genderCache->doQuery( $usernames, $fname );
}
Improve custom folding and grouping PHPStorm can use custom folding regions defined in either the VisualStudio style or the NetBeans style. The VisualStudio style is more pleasing to the eye and also works as a vim foldmarker. So get rid of the previous vim foldmarkers, and use region/endregion. region/endregion need to be in a single-line comment which is not a doc comment, and the rest of the comment is used as a region heading (by both PHPStorm and vim). So to retain Doxygen @name tags, it is necessary to repeat the section heading, once in a @name and once in a region. Establish a standard style for this, with a divider and three spaces before the heading, to better set off the heading name in plain text. Besides being the previous vim foldmarker, @{ is also a Doxygen grouping command. However, almost all prior usages of @{ ... @} in this sense were broken for one reason or another. It's necessary for the @{ to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of the individual members in the group are separately documented. @name alone is sufficient to create a Doxygen section when the sections are adjacent, but if there is ungrouped content after the section, it is necessary to use @{ ... @} to avoid having the Doxygen group run on. So I retained, fixed or added @{ ... @} in certain cases. I wasn't able to test the changes to the trait documentation in Doxygen since trait syntax is not recognised and the output is badly broken. Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
// endregion -- end of utility methods
}