2006-10-01 04:38:31 +00:00
|
|
|
<?php
|
2010-02-20 19:39:51 +00:00
|
|
|
/**
|
2012-07-15 20:13:02 +00:00
|
|
|
* Copyright © 2006, 2010 Yuri Astrakhan "<Firstname><Lastname>@gmail.com"
|
2006-10-01 04:38:31 +00:00
|
|
|
*
|
|
|
|
|
* 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.,
|
2010-06-21 13:13:32 +00:00
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2006-10-01 04:38:31 +00:00
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
2010-08-07 19:59:42 +00:00
|
|
|
*
|
|
|
|
|
* @file
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
|
|
|
|
|
2019-08-21 19:53:53 +00:00
|
|
|
use MediaWiki\Api\Validator\SubmoduleDef;
|
Separate Block into AbstractBlock, Block and SystemBlock
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
2019-03-18 22:09:49 +00:00
|
|
|
use MediaWiki\Block\AbstractBlock;
|
2019-05-13 14:18:07 +00:00
|
|
|
use MediaWiki\Block\DatabaseBlock;
|
2019-05-18 16:58:24 +00:00
|
|
|
use MediaWiki\Linker\LinkTarget;
|
2018-08-05 17:58:51 +00:00
|
|
|
use MediaWiki\MediaWikiServices;
|
2019-08-21 19:53:53 +00:00
|
|
|
use MediaWiki\ParamValidator\TypeDef\NamespaceDef;
|
2019-05-18 16:58:24 +00:00
|
|
|
use MediaWiki\Permissions\PermissionManager;
|
2019-08-21 19:53:53 +00:00
|
|
|
use Wikimedia\ParamValidator\ParamValidator;
|
|
|
|
|
use Wikimedia\ParamValidator\TypeDef\EnumDef;
|
|
|
|
|
use Wikimedia\ParamValidator\TypeDef\IntegerDef;
|
|
|
|
|
use Wikimedia\ParamValidator\TypeDef\StringDef;
|
2017-02-10 18:09:05 +00:00
|
|
|
use Wikimedia\Rdbms\IDatabase;
|
|
|
|
|
|
2007-04-04 05:22:37 +00:00
|
|
|
/**
|
2009-02-11 19:25:25 +00:00
|
|
|
* This abstract class implements many basic API functions, and is the base of
|
|
|
|
|
* all API classes.
|
2007-05-19 06:42:08 +00:00
|
|
|
* The class functions are divided into several areas of functionality:
|
2008-04-14 07:45:50 +00:00
|
|
|
*
|
2009-02-11 19:25:25 +00:00
|
|
|
* Module parameters: Derived classes can define getAllowedParams() to specify
|
2013-11-14 12:40:22 +00:00
|
|
|
* which parameters to expect, how to parse and validate them.
|
2008-04-14 07:45:50 +00:00
|
|
|
*
|
2009-02-11 19:25:25 +00:00
|
|
|
* Self-documentation: code to allow the API to document its own state
|
2008-04-14 07:45:50 +00:00
|
|
|
*
|
WARNING: HUGE COMMIT
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
2008-05-20 17:13:28 +00:00
|
|
|
* @ingroup API
|
2007-04-04 05:22:37 +00:00
|
|
|
*/
|
2011-10-26 23:27:01 +00:00
|
|
|
abstract class ApiBase extends ContextSource {
|
2006-10-01 04:38:31 +00:00
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
use ApiBlockInfoTrait;
|
|
|
|
|
|
2015-11-25 16:32:14 +00:00
|
|
|
/**
|
2019-08-21 19:53:53 +00:00
|
|
|
* @name Old constants for ::getAllowedParams() arrays
|
|
|
|
|
* @deprecated since 1.35, use the equivalent ParamValidator or TypeDef constants instead.
|
2015-11-25 16:32:14 +00:00
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_DFLT = ParamValidator::PARAM_DEFAULT;
|
|
|
|
|
public const PARAM_ISMULTI = ParamValidator::PARAM_ISMULTI;
|
|
|
|
|
public const PARAM_TYPE = ParamValidator::PARAM_TYPE;
|
|
|
|
|
public const PARAM_MAX = IntegerDef::PARAM_MAX;
|
|
|
|
|
public const PARAM_MAX2 = IntegerDef::PARAM_MAX2;
|
|
|
|
|
public const PARAM_MIN = IntegerDef::PARAM_MIN;
|
|
|
|
|
public const PARAM_ALLOW_DUPLICATES = ParamValidator::PARAM_ALLOW_DUPLICATES;
|
|
|
|
|
public const PARAM_DEPRECATED = ParamValidator::PARAM_DEPRECATED;
|
|
|
|
|
public const PARAM_REQUIRED = ParamValidator::PARAM_REQUIRED;
|
|
|
|
|
public const PARAM_SUBMODULE_MAP = SubmoduleDef::PARAM_SUBMODULE_MAP;
|
|
|
|
|
public const PARAM_SUBMODULE_PARAM_PREFIX = SubmoduleDef::PARAM_SUBMODULE_PARAM_PREFIX;
|
|
|
|
|
public const PARAM_ALL = ParamValidator::PARAM_ALL;
|
|
|
|
|
public const PARAM_EXTRA_NAMESPACES = NamespaceDef::PARAM_EXTRA_NAMESPACES;
|
|
|
|
|
public const PARAM_SENSITIVE = ParamValidator::PARAM_SENSITIVE;
|
|
|
|
|
public const PARAM_DEPRECATED_VALUES = EnumDef::PARAM_DEPRECATED_VALUES;
|
|
|
|
|
public const PARAM_ISMULTI_LIMIT1 = ParamValidator::PARAM_ISMULTI_LIMIT1;
|
|
|
|
|
public const PARAM_ISMULTI_LIMIT2 = ParamValidator::PARAM_ISMULTI_LIMIT2;
|
|
|
|
|
public const PARAM_MAX_BYTES = StringDef::PARAM_MAX_BYTES;
|
|
|
|
|
public const PARAM_MAX_CHARS = StringDef::PARAM_MAX_CHARS;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* (boolean) Inverse of IntegerDef::PARAM_IGNORE_RANGE
|
|
|
|
|
* @deprecated since 1.35
|
|
|
|
|
*/
|
|
|
|
|
public const PARAM_RANGE_ENFORCE = 'api-param-range-enforce';
|
2015-11-25 16:32:14 +00:00
|
|
|
|
2019-08-21 19:53:53 +00:00
|
|
|
/** @} */
|
2015-11-25 16:32:14 +00:00
|
|
|
|
|
|
|
|
/**
|
2019-08-21 19:53:53 +00:00
|
|
|
* @name API-specific constants for ::getAllowedParams() arrays
|
|
|
|
|
* @{
|
2015-11-25 16:32:14 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* (string|array|Message) Specify an alternative i18n documentation message
|
|
|
|
|
* for this parameter. Default is apihelp-{$path}-param-{$param}.
|
|
|
|
|
* @since 1.25
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_HELP_MSG = 'api-param-help-msg';
|
2015-11-25 16:32:14 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ((string|array|Message)[]) Specify additional i18n messages to append to
|
|
|
|
|
* the normal message for this parameter.
|
|
|
|
|
* @since 1.25
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_HELP_MSG_APPEND = 'api-param-help-msg-append';
|
2015-11-25 16:32:14 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* (array) Specify additional information tags for the parameter. Value is
|
|
|
|
|
* an array of arrays, with the first member being the 'tag' for the info
|
|
|
|
|
* and the remaining members being the values. In the help, this is
|
|
|
|
|
* formatted using apihelp-{$path}-paraminfo-{$tag}, which is passed
|
|
|
|
|
* $1 = count, $2 = comma-joined list of values, $3 = module prefix.
|
|
|
|
|
* @since 1.25
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_HELP_MSG_INFO = 'api-param-help-msg-info';
|
2015-11-25 16:32:14 +00:00
|
|
|
|
|
|
|
|
/**
|
2019-08-21 19:53:53 +00:00
|
|
|
* Deprecated and unused.
|
2015-11-25 16:32:14 +00:00
|
|
|
* @since 1.25
|
2019-08-21 19:53:53 +00:00
|
|
|
* @deprecated since 1.35
|
2015-11-25 16:32:14 +00:00
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_VALUE_LINKS = 'api-param-value-links';
|
2015-11-25 16:32:14 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ((string|array|Message)[]) When PARAM_TYPE is an array, this is an array
|
|
|
|
|
* mapping those values to $msg for ApiBase::makeMessage(). Any value not
|
|
|
|
|
* having a mapping will use apihelp-{$path}-paramvalue-{$param}-{$value}.
|
2018-01-11 17:02:04 +00:00
|
|
|
* Specify an empty array to use the default message key for all values.
|
2015-11-25 16:32:14 +00:00
|
|
|
* @since 1.25
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_HELP_MSG_PER_VALUE = 'api-param-help-msg-per-value';
|
2017-11-12 09:51:34 +00:00
|
|
|
|
2018-04-04 20:22:01 +00:00
|
|
|
/**
|
|
|
|
|
* (array) Indicate that this is a templated parameter, and specify replacements. Keys are the
|
|
|
|
|
* placeholders in the parameter name and values are the names of (unprefixed) parameters from
|
|
|
|
|
* which the replacement values are taken.
|
|
|
|
|
*
|
|
|
|
|
* For example, a parameter "foo-{ns}-{title}" could be defined with
|
|
|
|
|
* PARAM_TEMPLATE_VARS => [ 'ns' => 'namespaces', 'title' => 'titles' ]. Then a query for
|
|
|
|
|
* namespaces=0|1&titles=X|Y would support parameters foo-0-X, foo-0-Y, foo-1-X, and foo-1-Y.
|
|
|
|
|
*
|
|
|
|
|
* All placeholders must be present in the parameter's name. Each target parameter must have
|
|
|
|
|
* PARAM_ISMULTI true. If a target is itself a templated parameter, its PARAM_TEMPLATE_VARS must
|
|
|
|
|
* be a subset of the referring parameter's, mapping the same placeholders to the same targets.
|
|
|
|
|
* A parameter cannot target itself.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.32
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public const PARAM_TEMPLATE_VARS = 'param-template-vars';
|
2018-04-04 20:22:01 +00:00
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2015-11-25 16:32:14 +00:00
|
|
|
|
2019-10-15 23:59:45 +00:00
|
|
|
public const ALL_DEFAULT_STRING = '*';
|
2016-06-03 05:40:25 +00:00
|
|
|
|
2015-11-25 16:32:14 +00:00
|
|
|
/** Fast query, standard limit. */
|
2019-10-15 23:59:45 +00:00
|
|
|
public const LIMIT_BIG1 = 500;
|
2015-11-25 16:32:14 +00:00
|
|
|
/** Fast query, apihighlimits limit. */
|
2019-10-15 23:59:45 +00:00
|
|
|
public const LIMIT_BIG2 = 5000;
|
2015-11-25 16:32:14 +00:00
|
|
|
/** Slow query, standard limit. */
|
2019-10-15 23:59:45 +00:00
|
|
|
public const LIMIT_SML1 = 50;
|
2015-11-25 16:32:14 +00:00
|
|
|
/** Slow query, apihighlimits limit. */
|
2019-10-15 23:59:45 +00:00
|
|
|
public const LIMIT_SML2 = 500;
|
2006-10-17 02:01:20 +00:00
|
|
|
|
2013-02-08 20:39:40 +00:00
|
|
|
/**
|
|
|
|
|
* getAllowedParams() flag: When set, the result could take longer to generate,
|
|
|
|
|
* but should be more thorough. E.g. get the list of generators for ApiSandBox extension
|
|
|
|
|
* @since 1.21
|
|
|
|
|
*/
|
2019-10-15 23:59:45 +00:00
|
|
|
public const GET_VALUES_FOR_HELP = 1;
|
2013-02-08 20:39:40 +00:00
|
|
|
|
2015-03-27 21:10:31 +00:00
|
|
|
/** @var array Maps extension paths to info arrays */
|
|
|
|
|
private static $extensionInfo = null;
|
|
|
|
|
|
2019-08-30 16:01:28 +00:00
|
|
|
/** @var stdClass[][] Cache for self::filterIDs() */
|
2016-07-14 18:55:22 +00:00
|
|
|
private static $filterIDsCache = [];
|
|
|
|
|
|
2019-02-18 20:30:41 +00:00
|
|
|
/** $var array Map of web UI block messages to corresponding API messages and codes */
|
|
|
|
|
private static $blockMsgMap = [
|
|
|
|
|
'blockedtext' => [ 'apierror-blocked', 'blocked' ],
|
2019-07-03 06:47:01 +00:00
|
|
|
'blockedtext-partial' => [ 'apierror-blocked-partial', 'blocked' ],
|
2019-02-18 20:30:41 +00:00
|
|
|
'autoblockedtext' => [ 'apierror-autoblocked', 'autoblocked' ],
|
|
|
|
|
'systemblockedtext' => [ 'apierror-systemblocked', 'blocked' ],
|
2019-07-03 06:47:01 +00:00
|
|
|
'blockedtext-composite' => [ 'apierror-blocked', 'blocked' ],
|
2019-02-18 20:30:41 +00:00
|
|
|
];
|
|
|
|
|
|
2014-05-16 15:11:55 +00:00
|
|
|
/** @var ApiMain */
|
|
|
|
|
private $mMainModule;
|
|
|
|
|
/** @var string */
|
|
|
|
|
private $mModuleName, $mModulePrefix;
|
2018-10-31 17:36:48 +00:00
|
|
|
private $mReplicaDB = null;
|
2019-09-15 15:12:06 +00:00
|
|
|
/**
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
private $mParamCache = [];
|
2015-03-27 21:10:31 +00:00
|
|
|
/** @var array|null|bool */
|
|
|
|
|
private $mModuleSource = false;
|
2006-10-01 04:38:31 +00:00
|
|
|
|
|
|
|
|
/**
|
2014-04-15 18:12:09 +00:00
|
|
|
* @param ApiMain $mainModule
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param string $moduleName Name of this module
|
|
|
|
|
* @param string $modulePrefix Prefix to use for parameter names
|
2009-02-11 19:25:25 +00:00
|
|
|
*/
|
2014-05-16 15:11:55 +00:00
|
|
|
public function __construct( ApiMain $mainModule, $moduleName, $modulePrefix = '' ) {
|
2006-10-01 04:38:31 +00:00
|
|
|
$this->mMainModule = $mainModule;
|
2006-10-17 02:01:20 +00:00
|
|
|
$this->mModuleName = $moduleName;
|
2007-07-07 03:05:09 +00:00
|
|
|
$this->mModulePrefix = $modulePrefix;
|
2011-10-26 23:27:01 +00:00
|
|
|
|
|
|
|
|
if ( !$this->isMain() ) {
|
2011-10-27 18:46:40 +00:00
|
|
|
$this->setContext( $mainModule->getContext() );
|
2011-10-26 23:27:01 +00:00
|
|
|
}
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Methods to implement
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
2008-01-12 07:08:17 +00:00
|
|
|
|
|
|
|
|
/**
|
2009-02-11 19:25:25 +00:00
|
|
|
* Evaluates the parameters, performs the requested query, and sets up
|
|
|
|
|
* the result. Concrete implementations of ApiBase must override this
|
|
|
|
|
* method to provide whatever functionality their module offers.
|
|
|
|
|
* Implementations must not produce any output on their own and are not
|
|
|
|
|
* expected to handle any errors.
|
2008-01-12 07:08:17 +00:00
|
|
|
*
|
2009-02-11 19:25:25 +00:00
|
|
|
* The execute() method will be invoked directly by ApiMain immediately
|
|
|
|
|
* before the result of the module is output. Aside from the
|
|
|
|
|
* constructor, implementations should assume that no other methods
|
|
|
|
|
* will be called externally on the module before the result is
|
|
|
|
|
* processed.
|
2008-01-12 07:08:17 +00:00
|
|
|
*
|
2009-02-11 19:25:25 +00:00
|
|
|
* The result data should be stored in the ApiResult object available
|
|
|
|
|
* through getResult().
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
2013-01-26 19:00:09 +00:00
|
|
|
abstract public function execute();
|
2006-10-01 04:38:31 +00:00
|
|
|
|
2008-01-12 07:08:17 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Get the module manager, or null if this module has no sub-modules
|
|
|
|
|
* @since 1.21
|
|
|
|
|
* @return ApiModuleManager
|
2008-01-12 07:08:17 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
public function getModuleManager() {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
2013-11-14 12:40:22 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* If the module may only be used with a certain format module,
|
|
|
|
|
* it should override this method to return an instance of that formatter.
|
|
|
|
|
* A value of null means the default format will be used.
|
2015-03-03 21:46:14 +00:00
|
|
|
* @note Do not use this just because you don't want to support non-json
|
|
|
|
|
* formats. This should be used only when there is a fundamental
|
|
|
|
|
* requirement for a specific format.
|
2014-08-27 19:41:05 +00:00
|
|
|
* @return mixed Instance of a derived class of ApiFormatBase, or null
|
|
|
|
|
*/
|
|
|
|
|
public function getCustomPrinter() {
|
|
|
|
|
return null;
|
2013-01-14 22:01:42 +00:00
|
|
|
}
|
2008-01-12 07:08:17 +00:00
|
|
|
|
2006-10-17 02:01:20 +00:00
|
|
|
/**
|
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
|
|
|
* Returns usage examples for this module.
|
|
|
|
|
*
|
|
|
|
|
* Return value has query strings as keys, with values being either strings
|
|
|
|
|
* (message key), arrays (message key + parameter), or Message objects.
|
|
|
|
|
*
|
|
|
|
|
* Do not call this base class implementation when overriding this method.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @return array
|
2006-10-17 02:01:20 +00:00
|
|
|
*/
|
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
|
|
|
protected function getExamplesMessages() {
|
2018-10-10 17:14:13 +00:00
|
|
|
return [];
|
2013-02-05 06:52:55 +00:00
|
|
|
}
|
|
|
|
|
|
2007-05-21 06:32:32 +00:00
|
|
|
/**
|
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
|
|
|
* Return links to more detailed help pages about the module.
|
|
|
|
|
* @since 1.25, returning boolean false is deprecated
|
|
|
|
|
* @return string|array
|
2007-05-21 06:32:32 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
public function getHelpUrls() {
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2008-04-14 07:45:50 +00:00
|
|
|
}
|
2007-05-21 06:32:32 +00:00
|
|
|
|
2006-10-17 02:01:20 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Returns an array of allowed parameters (parameter name) => (default
|
|
|
|
|
* value) or (parameter name) => (array with PARAM_* constants as keys)
|
|
|
|
|
* Don't call this function directly: use getFinalParams() to allow
|
|
|
|
|
* hooks to modify parameters as needed.
|
2011-05-08 16:48:30 +00:00
|
|
|
*
|
2014-08-27 19:41:05 +00:00
|
|
|
* Some derived classes may choose to handle an integer $flags parameter
|
|
|
|
|
* in the overriding methods. Callers of this method can pass zero or
|
|
|
|
|
* more OR-ed flags like GET_VALUES_FOR_HELP.
|
|
|
|
|
*
|
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
|
|
|
* @return array
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
|
|
|
|
protected function getAllowedParams( /* $flags = 0 */ ) {
|
|
|
|
|
// int $flags is not declared because it causes "Strict standards"
|
|
|
|
|
// warning. Most derived classes do not implement it.
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Indicates if this module needs maxlag to be checked
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function shouldCheckMaxlag() {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Indicates whether this module requires read rights
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function isReadMode() {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Indicates whether this module requires write mode
|
2017-04-12 23:17:00 +00:00
|
|
|
*
|
|
|
|
|
* This should return true for modules that may require synchronous database writes.
|
|
|
|
|
* Modules that do not need such writes should also not rely on master database access,
|
|
|
|
|
* since only read queries are needed and each master DB is a single point of failure.
|
|
|
|
|
* Additionally, requests that only need replica DBs can be efficiently routed to any
|
|
|
|
|
* datacenter via the Promise-Non-Write-API-Action header.
|
|
|
|
|
*
|
2014-08-27 19:41:05 +00:00
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function isWriteMode() {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Indicates whether this module must be called with a POST request
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function mustBePosted() {
|
|
|
|
|
return $this->needsToken() !== false;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Indicates whether this module is deprecated
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function isDeprecated() {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2014-11-24 22:19:09 +00:00
|
|
|
* Indicates whether this module is "internal"
|
|
|
|
|
* Internal API modules are not (yet) intended for 3rd party use and may be unstable.
|
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
|
|
|
* @since 1.25
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function isInternal() {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Returns the token type this module requires in order to execute.
|
|
|
|
|
*
|
|
|
|
|
* Modules are strongly encouraged to use the core 'csrf' type unless they
|
|
|
|
|
* have specialized security needs. If the token type is not one of the
|
|
|
|
|
* core types, you must use the ApiQueryTokensRegisterTypes hook to
|
|
|
|
|
* register it.
|
|
|
|
|
*
|
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
|
|
|
* Returning a non-falsey value here will force the addition of an
|
|
|
|
|
* appropriate 'token' parameter in self::getFinalParams(). Also,
|
|
|
|
|
* self::mustBePosted() must return true when tokens are used.
|
2014-08-27 19:41:05 +00:00
|
|
|
*
|
|
|
|
|
* In previous versions of MediaWiki, true was a valid return value.
|
|
|
|
|
* Returning true will generate errors indicating that the API module needs
|
|
|
|
|
* updating.
|
|
|
|
|
*
|
|
|
|
|
* @return string|false
|
|
|
|
|
*/
|
|
|
|
|
public function needsToken() {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Fetch the salt used in the Web UI corresponding to this module.
|
2011-05-08 16:48:30 +00:00
|
|
|
*
|
2014-08-27 19:41:05 +00:00
|
|
|
* Only override this if the Web UI uses a token with a non-constant salt.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.24
|
|
|
|
|
* @param array $params All supplied parameters for the module
|
|
|
|
|
* @return string|array|null
|
|
|
|
|
*/
|
|
|
|
|
protected function getWebUITokenSalt( array $params ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-17 20:52:09 +00:00
|
|
|
/**
|
|
|
|
|
* Returns data for HTTP conditional request mechanisms.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.26
|
|
|
|
|
* @param string $condition Condition being queried:
|
|
|
|
|
* - last-modified: Return a timestamp representing the maximum of the
|
|
|
|
|
* last-modified dates for all resources involved in the request. See
|
|
|
|
|
* RFC 7232 § 2.2 for semantics.
|
|
|
|
|
* - etag: Return an entity-tag representing the state of all resources involved
|
|
|
|
|
* in the request. Quotes must be included. See RFC 7232 § 2.3 for semantics.
|
2016-03-24 08:44:09 +00:00
|
|
|
* @return string|bool|null As described above, or null if no value is available.
|
2015-08-17 20:52:09 +00:00
|
|
|
*/
|
|
|
|
|
public function getConditionalRequestData( $condition ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Data access methods
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get the name of the module being executed by this instance
|
2009-02-11 19:25:25 +00:00
|
|
|
* @return string
|
2006-10-17 02:01:20 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
public function getModuleName() {
|
|
|
|
|
return $this->mModuleName;
|
|
|
|
|
}
|
2013-11-17 19:54:11 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Get parameter prefix (usually two letters or an empty string).
|
|
|
|
|
* @return string
|
|
|
|
|
*/
|
|
|
|
|
public function getModulePrefix() {
|
|
|
|
|
return $this->mModulePrefix;
|
2006-10-17 02:01:20 +00:00
|
|
|
}
|
2006-10-16 23:25:51 +00:00
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
/**
|
2009-02-11 19:25:25 +00:00
|
|
|
* Get the main module
|
2014-04-15 18:12:09 +00:00
|
|
|
* @return ApiMain
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
|
|
|
|
public function getMain() {
|
|
|
|
|
return $this->mMainModule;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2008-04-14 07:45:50 +00:00
|
|
|
* Returns true if this module is the main module ($this === $this->mMainModule),
|
2008-01-12 07:08:17 +00:00
|
|
|
* false otherwise.
|
2009-02-11 19:25:25 +00:00
|
|
|
* @return bool
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
|
|
|
|
public function isMain() {
|
|
|
|
|
return $this === $this->mMainModule;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Get the parent of this module
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @return ApiBase|null
|
|
|
|
|
*/
|
|
|
|
|
public function getParent() {
|
|
|
|
|
return $this->isMain() ? null : $this->getMain();
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-17 11:09:04 +00:00
|
|
|
/**
|
|
|
|
|
* Returns true if the current request breaks the same-origin policy.
|
|
|
|
|
*
|
|
|
|
|
* For example, json with callbacks.
|
|
|
|
|
*
|
|
|
|
|
* https://en.wikipedia.org/wiki/Same-origin_policy
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function lacksSameOriginSecurity() {
|
2015-05-08 14:20:30 +00:00
|
|
|
// Main module has this method overridden
|
|
|
|
|
// Safety - avoid infinite loop:
|
|
|
|
|
if ( $this->isMain() ) {
|
2017-07-23 01:24:09 +00:00
|
|
|
self::dieDebug( __METHOD__, 'base method was called on main module.' );
|
2015-05-08 14:20:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $this->getMain()->lacksSameOriginSecurity();
|
2014-12-17 11:09:04 +00:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Get the path to this module
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @return string
|
|
|
|
|
*/
|
|
|
|
|
public function getModulePath() {
|
|
|
|
|
if ( $this->isMain() ) {
|
|
|
|
|
return 'main';
|
|
|
|
|
} elseif ( $this->getParent()->isMain() ) {
|
|
|
|
|
return $this->getModuleName();
|
|
|
|
|
} else {
|
|
|
|
|
return $this->getParent()->getModulePath() . '+' . $this->getModuleName();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get a module from its module path
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @return ApiBase|null
|
2016-10-19 16:54:25 +00:00
|
|
|
* @throws ApiUsageException
|
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 getModuleFromPath( $path ) {
|
|
|
|
|
$module = $this->getMain();
|
|
|
|
|
if ( $path === 'main' ) {
|
|
|
|
|
return $module;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$parts = explode( '+', $path );
|
|
|
|
|
if ( count( $parts ) === 1 ) {
|
|
|
|
|
// In case the '+' was typed into URL, it resolves as a space
|
|
|
|
|
$parts = explode( ' ', $path );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$count = count( $parts );
|
|
|
|
|
for ( $i = 0; $i < $count; $i++ ) {
|
|
|
|
|
$parent = $module;
|
|
|
|
|
$manager = $parent->getModuleManager();
|
|
|
|
|
if ( $manager === null ) {
|
2016-03-08 08:13:12 +00:00
|
|
|
$errorPath = implode( '+', array_slice( $parts, 0, $i ) );
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [ 'apierror-badmodule-nosubmodules', $errorPath ], 'badmodule' );
|
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
|
|
|
}
|
|
|
|
|
$module = $manager->getModule( $parts[$i] );
|
|
|
|
|
|
|
|
|
|
if ( $module === null ) {
|
2016-03-08 08:13:12 +00:00
|
|
|
$errorPath = $i ? implode( '+', array_slice( $parts, 0, $i ) ) : $parent->getModuleName();
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
|
|
|
|
[ 'apierror-badmodule-badsubmodule', $errorPath, wfEscapeWikiText( $parts[$i] ) ],
|
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
|
|
|
'badmodule'
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $module;
|
|
|
|
|
}
|
|
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
/**
|
2009-02-11 19:25:25 +00:00
|
|
|
* Get the result object
|
|
|
|
|
* @return ApiResult
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
|
|
|
|
public function getResult() {
|
2013-03-11 03:45:51 +00:00
|
|
|
// Main module has getResult() method overridden
|
2006-10-01 04:38:31 +00:00
|
|
|
// Safety - avoid infinite loop:
|
2010-02-20 19:39:51 +00:00
|
|
|
if ( $this->isMain() ) {
|
2017-07-23 01:24:09 +00:00
|
|
|
self::dieDebug( __METHOD__, 'base method was called on main module. ' );
|
2010-02-20 19:39:51 +00:00
|
|
|
}
|
2013-11-14 12:40:22 +00:00
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
return $this->getMain()->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
|
|
|
* Get the error formatter
|
|
|
|
|
* @return ApiErrorFormatter
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
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
|
|
|
public function getErrorFormatter() {
|
|
|
|
|
// Main module has getErrorFormatter() method overridden
|
|
|
|
|
// Safety - avoid infinite loop:
|
|
|
|
|
if ( $this->isMain() ) {
|
2017-07-23 01:24:09 +00:00
|
|
|
self::dieDebug( __METHOD__, 'base method was called on main module. ' );
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $this->getMain()->getErrorFormatter();
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
|
|
|
|
|
2007-07-06 07:16:38 +00:00
|
|
|
/**
|
2016-09-05 20:21:26 +00:00
|
|
|
* Gets a default replica DB connection object
|
2017-02-07 04:49:57 +00:00
|
|
|
* @return IDatabase
|
2007-07-06 07:16:38 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
protected function getDB() {
|
2018-10-31 17:36:48 +00:00
|
|
|
if ( !isset( $this->mReplicaDB ) ) {
|
|
|
|
|
$this->mReplicaDB = wfGetDB( DB_REPLICA, 'api' );
|
2008-05-20 19:43:50 +00:00
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
|
2018-10-31 17:36:48 +00:00
|
|
|
return $this->mReplicaDB;
|
2007-07-06 07:16:38 +00:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Get the continuation manager
|
|
|
|
|
* @return ApiContinuationManager|null
|
|
|
|
|
*/
|
|
|
|
|
public function getContinuationManager() {
|
|
|
|
|
// Main module has getContinuationManager() method overridden
|
|
|
|
|
// Safety - avoid infinite loop:
|
|
|
|
|
if ( $this->isMain() ) {
|
2017-07-23 01:24:09 +00:00
|
|
|
self::dieDebug( __METHOD__, 'base method was called on main module. ' );
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $this->getMain()->getContinuationManager();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the continuation manager
|
2017-08-11 16:09:41 +00:00
|
|
|
* @param ApiContinuationManager|null $manager
|
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
|
|
|
*/
|
2018-03-26 14:38:41 +00:00
|
|
|
public function setContinuationManager( ApiContinuationManager $manager = null ) {
|
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
|
|
|
// Main module has setContinuationManager() method overridden
|
|
|
|
|
// Safety - avoid infinite loop:
|
|
|
|
|
if ( $this->isMain() ) {
|
2017-07-23 01:24:09 +00:00
|
|
|
self::dieDebug( __METHOD__, 'base method was called on main module. ' );
|
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->getMain()->setContinuationManager( $manager );
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-18 16:58:24 +00:00
|
|
|
/**
|
|
|
|
|
* Obtain a PermissionManager instance that subclasses may use in their authorization checks.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.34
|
|
|
|
|
* @return PermissionManager
|
|
|
|
|
*/
|
|
|
|
|
protected function getPermissionManager(): PermissionManager {
|
|
|
|
|
return MediaWikiServices::getInstance()->getPermissionManager();
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Parameter handling
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
2016-01-15 21:38:31 +00:00
|
|
|
/**
|
|
|
|
|
* Indicate if the module supports dynamically-determined parameters that
|
|
|
|
|
* cannot be included in self::getAllowedParams().
|
|
|
|
|
* @return string|array|Message|null Return null if the module does not
|
|
|
|
|
* support additional dynamic parameters, otherwise return a message
|
|
|
|
|
* describing them.
|
|
|
|
|
*/
|
|
|
|
|
public function dynamicParameterDocumentation() {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* This method mangles parameter name based on the prefix supplied to the constructor.
|
|
|
|
|
* Override this method to change parameter name during runtime
|
2016-10-19 16:54:25 +00:00
|
|
|
* @param string|string[] $paramName Parameter name
|
|
|
|
|
* @return string|string[] Prefixed parameter name
|
|
|
|
|
* @since 1.29 accepts an array of strings
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
|
|
|
|
public function encodeParamName( $paramName ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
if ( is_array( $paramName ) ) {
|
|
|
|
|
return array_map( function ( $name ) {
|
|
|
|
|
return $this->mModulePrefix . $name;
|
|
|
|
|
}, $paramName );
|
|
|
|
|
} else {
|
|
|
|
|
return $this->mModulePrefix . $paramName;
|
|
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Using getAllowedParams(), this function makes an array of the values
|
|
|
|
|
* provided by the user, with key being the name of the variable, and
|
|
|
|
|
* value - validated value from user or default. limits will not be
|
|
|
|
|
* parsed if $parseLimit is set to false; use this when the max
|
|
|
|
|
* limit is not definitive yet, e.g. when getting revisions.
|
2018-05-28 22:45:24 +00:00
|
|
|
* @param bool|array $options If a boolean, uses that as the value for 'parseLimit'
|
|
|
|
|
* - parseLimit: (bool, default true) Whether to parse the 'max' value for limit types
|
|
|
|
|
* - safeMode: (bool, default false) If true, avoid throwing for parameter validation errors.
|
|
|
|
|
* Returned parameter values might be ApiUsageException instances.
|
2014-08-27 19:41:05 +00:00
|
|
|
* @return array
|
|
|
|
|
*/
|
2018-05-28 22:45:24 +00:00
|
|
|
public function extractRequestParams( $options = [] ) {
|
|
|
|
|
if ( is_bool( $options ) ) {
|
|
|
|
|
$options = [ 'parseLimit' => $options ];
|
|
|
|
|
}
|
|
|
|
|
$options += [
|
|
|
|
|
'parseLimit' => true,
|
|
|
|
|
'safeMode' => false,
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
$parseLimit = (bool)$options['parseLimit'];
|
2019-09-15 15:12:06 +00:00
|
|
|
$cacheKey = (int)$parseLimit;
|
2018-05-28 22:45:24 +00:00
|
|
|
|
2017-02-20 22:28:10 +00:00
|
|
|
// Cache parameters, for performance and to avoid T26564.
|
2019-09-15 15:12:06 +00:00
|
|
|
if ( !isset( $this->mParamCache[$cacheKey] ) ) {
|
2018-04-04 20:22:01 +00:00
|
|
|
$params = $this->getFinalParams() ?: [];
|
2016-02-17 09:09:32 +00:00
|
|
|
$results = [];
|
2018-04-04 20:22:01 +00:00
|
|
|
$warned = [];
|
|
|
|
|
|
|
|
|
|
// Process all non-templates and save templates for secondary
|
|
|
|
|
// processing.
|
|
|
|
|
$toProcess = [];
|
|
|
|
|
foreach ( $params as $paramName => $paramSettings ) {
|
|
|
|
|
if ( isset( $paramSettings[self::PARAM_TEMPLATE_VARS] ) ) {
|
|
|
|
|
$toProcess[] = [ $paramName, $paramSettings[self::PARAM_TEMPLATE_VARS], $paramSettings ];
|
|
|
|
|
} else {
|
2018-05-28 22:45:24 +00:00
|
|
|
try {
|
|
|
|
|
$results[$paramName] = $this->getParameterFromSettings(
|
|
|
|
|
$paramName, $paramSettings, $parseLimit
|
|
|
|
|
);
|
|
|
|
|
} catch ( ApiUsageException $ex ) {
|
|
|
|
|
$results[$paramName] = $ex;
|
|
|
|
|
}
|
2011-12-27 16:22:35 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-04-04 20:22:01 +00:00
|
|
|
|
|
|
|
|
// Now process all the templates by successively replacing the
|
|
|
|
|
// placeholders with all client-supplied values.
|
|
|
|
|
// This bit duplicates JavaScript logic in
|
|
|
|
|
// ApiSandbox.PageLayout.prototype.updateTemplatedParams().
|
|
|
|
|
// If you update this, see if that needs updating too.
|
|
|
|
|
while ( $toProcess ) {
|
|
|
|
|
list( $name, $targets, $settings ) = array_shift( $toProcess );
|
|
|
|
|
|
|
|
|
|
foreach ( $targets as $placeholder => $target ) {
|
|
|
|
|
if ( !array_key_exists( $target, $results ) ) {
|
|
|
|
|
// The target wasn't processed yet, try the next one.
|
|
|
|
|
// If all hit this case, the parameter has no expansions.
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if ( !is_array( $results[$target] ) || !$results[$target] ) {
|
|
|
|
|
// The target was processed but has no (valid) values.
|
|
|
|
|
// That means it has no expansions.
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Expand this target in the name and all other targets,
|
|
|
|
|
// then requeue if there are more targets left or put in
|
|
|
|
|
// $results if all are done.
|
|
|
|
|
unset( $targets[$placeholder] );
|
|
|
|
|
$placeholder = '{' . $placeholder . '}';
|
2019-03-22 06:11:04 +00:00
|
|
|
// @phan-suppress-next-line PhanTypeNoAccessiblePropertiesForeach
|
2018-04-04 20:22:01 +00:00
|
|
|
foreach ( $results[$target] as $value ) {
|
|
|
|
|
if ( !preg_match( '/^[^{}]*$/', $value ) ) {
|
|
|
|
|
// Skip values that make invalid parameter names.
|
|
|
|
|
$encTargetName = $this->encodeParamName( $target );
|
|
|
|
|
if ( !isset( $warned[$encTargetName][$value] ) ) {
|
|
|
|
|
$warned[$encTargetName][$value] = true;
|
|
|
|
|
$this->addWarning( [
|
|
|
|
|
'apiwarn-ignoring-invalid-templated-value',
|
|
|
|
|
wfEscapeWikiText( $encTargetName ),
|
|
|
|
|
wfEscapeWikiText( $value ),
|
|
|
|
|
] );
|
|
|
|
|
}
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$newName = str_replace( $placeholder, $value, $name );
|
|
|
|
|
if ( !$targets ) {
|
2018-05-28 22:45:24 +00:00
|
|
|
try {
|
2020-03-13 00:55:30 +00:00
|
|
|
$results[$newName] = $this->getParameterFromSettings(
|
|
|
|
|
$newName,
|
|
|
|
|
$settings,
|
|
|
|
|
$parseLimit
|
|
|
|
|
);
|
2018-05-28 22:45:24 +00:00
|
|
|
} catch ( ApiUsageException $ex ) {
|
|
|
|
|
$results[$newName] = $ex;
|
|
|
|
|
}
|
2018-04-04 20:22:01 +00:00
|
|
|
} else {
|
|
|
|
|
$newTargets = [];
|
|
|
|
|
foreach ( $targets as $k => $v ) {
|
|
|
|
|
$newTargets[$k] = str_replace( $placeholder, $value, $v );
|
|
|
|
|
}
|
|
|
|
|
$toProcess[] = [ $newName, $newTargets, $settings ];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-15 15:12:06 +00:00
|
|
|
$this->mParamCache[$cacheKey] = $results;
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
|
|
|
|
|
2019-09-15 15:12:06 +00:00
|
|
|
$ret = $this->mParamCache[$cacheKey];
|
2018-05-28 22:45:24 +00:00
|
|
|
if ( !$options['safeMode'] ) {
|
|
|
|
|
foreach ( $ret as $v ) {
|
|
|
|
|
if ( $v instanceof ApiUsageException ) {
|
|
|
|
|
throw $v;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-15 15:12:06 +00:00
|
|
|
return $this->mParamCache[$cacheKey];
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
|
|
|
|
|
2011-12-27 16:22:35 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Get a value for the given parameter
|
|
|
|
|
* @param string $paramName Parameter name
|
|
|
|
|
* @param bool $parseLimit See extractRequestParams()
|
|
|
|
|
* @return mixed Parameter value
|
2011-12-27 16:22:35 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
protected function getParameter( $paramName, $parseLimit = true ) {
|
2018-05-28 22:45:24 +00:00
|
|
|
$ret = $this->extractRequestParams( [
|
|
|
|
|
'parseLimit' => $parseLimit,
|
|
|
|
|
'safeMode' => true,
|
|
|
|
|
] )[$paramName];
|
|
|
|
|
if ( $ret instanceof ApiUsageException ) {
|
|
|
|
|
throw $ret;
|
|
|
|
|
}
|
|
|
|
|
return $ret;
|
2011-12-27 16:22:35 +00:00
|
|
|
}
|
|
|
|
|
|
2011-07-17 16:18:09 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Die if none or more than one of a certain set of parameters is set and not false.
|
|
|
|
|
*
|
|
|
|
|
* @param array $params User provided set of parameters, as from $this->extractRequestParams()
|
2019-10-11 18:11:59 +00:00
|
|
|
* @param string ...$required Names of parameters of which exactly one must be set
|
2011-07-17 16:18:09 +00:00
|
|
|
*/
|
2019-10-11 18:11:59 +00:00
|
|
|
public function requireOnlyOneParameter( $params, ...$required ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
$intersection = array_intersect( array_keys( array_filter( $params,
|
2016-03-08 08:04:45 +00:00
|
|
|
[ $this, 'parameterNotEmpty' ] ) ), $required );
|
2013-11-14 12:40:22 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
if ( count( $intersection ) > 1 ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [
|
|
|
|
|
'apierror-invalidparammix',
|
|
|
|
|
Message::listParam( array_map(
|
|
|
|
|
function ( $p ) {
|
|
|
|
|
return '<var>' . $this->encodeParamName( $p ) . '</var>';
|
|
|
|
|
},
|
|
|
|
|
array_values( $intersection )
|
|
|
|
|
) ),
|
|
|
|
|
count( $intersection ),
|
|
|
|
|
] );
|
2014-08-27 19:41:05 +00:00
|
|
|
} elseif ( count( $intersection ) == 0 ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [
|
|
|
|
|
'apierror-missingparam-one-of',
|
|
|
|
|
Message::listParam( array_map(
|
|
|
|
|
function ( $p ) {
|
|
|
|
|
return '<var>' . $this->encodeParamName( $p ) . '</var>';
|
|
|
|
|
},
|
2019-12-07 18:32:45 +00:00
|
|
|
$required
|
2016-10-19 16:54:25 +00:00
|
|
|
) ),
|
|
|
|
|
count( $required ),
|
|
|
|
|
], 'missingparam' );
|
2011-07-17 16:18:09 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-14 07:45:50 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Die if more than one of a certain set of parameters is set and not false.
|
|
|
|
|
*
|
|
|
|
|
* @param array $params User provided set of parameters, as from $this->extractRequestParams()
|
2019-10-11 18:11:59 +00:00
|
|
|
* @param string ...$required Names of parameters of which at most one must be set
|
2008-01-12 07:08:17 +00:00
|
|
|
*/
|
2019-10-11 18:11:59 +00:00
|
|
|
public function requireMaxOneParameter( $params, ...$required ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
$intersection = array_intersect( array_keys( array_filter( $params,
|
2016-03-08 08:04:45 +00:00
|
|
|
[ $this, 'parameterNotEmpty' ] ) ), $required );
|
2006-10-30 00:18:05 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
if ( count( $intersection ) > 1 ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [
|
|
|
|
|
'apierror-invalidparammix',
|
|
|
|
|
Message::listParam( array_map(
|
|
|
|
|
function ( $p ) {
|
|
|
|
|
return '<var>' . $this->encodeParamName( $p ) . '</var>';
|
|
|
|
|
},
|
|
|
|
|
array_values( $intersection )
|
|
|
|
|
) ),
|
|
|
|
|
count( $intersection ),
|
|
|
|
|
] );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
2010-06-18 09:30:38 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Die if none of a certain set of parameters is set and not false.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.23
|
|
|
|
|
* @param array $params User provided set of parameters, as from $this->extractRequestParams()
|
2019-10-11 18:11:59 +00:00
|
|
|
* @param string ...$required Names of parameters of which at least one must be set
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
2019-10-11 18:11:59 +00:00
|
|
|
public function requireAtLeastOneParameter( $params, ...$required ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
$intersection = array_intersect(
|
2016-03-08 08:04:45 +00:00
|
|
|
array_keys( array_filter( $params, [ $this, 'parameterNotEmpty' ] ) ),
|
2014-08-27 19:41:05 +00:00
|
|
|
$required
|
|
|
|
|
);
|
2010-08-05 07:02:09 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
if ( count( $intersection ) == 0 ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [
|
|
|
|
|
'apierror-missingparam-at-least-one-of',
|
|
|
|
|
Message::listParam( array_map(
|
|
|
|
|
function ( $p ) {
|
|
|
|
|
return '<var>' . $this->encodeParamName( $p ) . '</var>';
|
|
|
|
|
},
|
2019-12-07 18:32:45 +00:00
|
|
|
$required
|
2016-10-19 16:54:25 +00:00
|
|
|
) ),
|
|
|
|
|
count( $required ),
|
|
|
|
|
], 'missingparam' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-10-28 00:56:07 +00:00
|
|
|
|
2016-08-18 17:36:11 +00:00
|
|
|
/**
|
|
|
|
|
* Die if any of the specified parameters were found in the query part of
|
|
|
|
|
* the URL rather than the post body.
|
|
|
|
|
* @since 1.28
|
|
|
|
|
* @param string[] $params Parameters to check
|
|
|
|
|
* @param string $prefix Set to 'noprefix' to skip calling $this->encodeParamName()
|
|
|
|
|
*/
|
|
|
|
|
public function requirePostedParameters( $params, $prefix = 'prefix' ) {
|
|
|
|
|
// Skip if $wgDebugAPI is set or we're in internal mode
|
|
|
|
|
if ( $this->getConfig()->get( 'DebugAPI' ) || $this->getMain()->isInternalMode() ) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-03 00:25:19 +00:00
|
|
|
$queryValues = $this->getRequest()->getQueryValuesOnly();
|
2016-08-18 17:36:11 +00:00
|
|
|
$badParams = [];
|
|
|
|
|
foreach ( $params as $param ) {
|
|
|
|
|
if ( $prefix !== 'noprefix' ) {
|
|
|
|
|
$param = $this->encodeParamName( $param );
|
|
|
|
|
}
|
|
|
|
|
if ( array_key_exists( $param, $queryValues ) ) {
|
|
|
|
|
$badParams[] = $param;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( $badParams ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
2018-02-17 12:29:13 +00:00
|
|
|
[ 'apierror-mustpostparams', implode( ', ', $badParams ), count( $badParams ) ]
|
2016-08-18 17:36:11 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Callback function used in requireOnlyOneParameter to check whether required parameters are set
|
|
|
|
|
*
|
|
|
|
|
* @param object $x Parameter to check is not null/false
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
private function parameterNotEmpty( $x ) {
|
2020-01-09 23:48:34 +00:00
|
|
|
return $x !== null && $x !== false;
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
2006-11-03 06:53:47 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Get a WikiPage object from a title or pageid param, if possible.
|
|
|
|
|
* Can die, if no param is set or if the title or page id is not valid.
|
|
|
|
|
*
|
2017-07-07 00:01:30 +00:00
|
|
|
* @param array $params User provided set of parameters, as from $this->extractRequestParams()
|
2014-08-27 19:41:05 +00:00
|
|
|
* @param bool|string $load Whether load the object's state from the database:
|
|
|
|
|
* - false: don't load (if the pageid is given, it will still be loaded)
|
2016-09-05 20:21:26 +00:00
|
|
|
* - 'fromdb': load from a replica DB
|
2014-08-27 19:41:05 +00:00
|
|
|
* - 'fromdbmaster': load from the master database
|
|
|
|
|
* @return WikiPage
|
|
|
|
|
*/
|
|
|
|
|
public function getTitleOrPageId( $params, $load = false ) {
|
|
|
|
|
$this->requireOnlyOneParameter( $params, 'title', 'pageid' );
|
2006-10-17 02:01:20 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
$pageObj = null;
|
|
|
|
|
if ( isset( $params['title'] ) ) {
|
|
|
|
|
$titleObj = Title::newFromText( $params['title'] );
|
|
|
|
|
if ( !$titleObj || $titleObj->isExternal() ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [ 'apierror-invalidtitle', wfEscapeWikiText( $params['title'] ) ] );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
if ( !$titleObj->canExist() ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( 'apierror-pagecannotexist' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
$pageObj = WikiPage::factory( $titleObj );
|
|
|
|
|
if ( $load !== false ) {
|
|
|
|
|
$pageObj->loadPageData( $load );
|
|
|
|
|
}
|
|
|
|
|
} elseif ( isset( $params['pageid'] ) ) {
|
|
|
|
|
if ( $load === false ) {
|
|
|
|
|
$load = 'fromdb';
|
|
|
|
|
}
|
|
|
|
|
$pageObj = WikiPage::newFromID( $params['pageid'], $load );
|
|
|
|
|
if ( !$pageObj ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [ 'apierror-nosuchpageid', $params['pageid'] ] );
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
2010-02-20 19:39:51 +00:00
|
|
|
}
|
2013-11-17 19:54:11 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
return $pageObj;
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
2010-02-09 08:37:38 +00:00
|
|
|
|
API: Allow finding log events and links to special pages
Log events are sometimes attributed to a special page; it should be
allowed to use rcnamespace or lenamespace to filter for these.
It's also possible for special pages to be the targets of redirects, so
list=allredirects and prop=redirects should find them.
Maybe someday we'll record links to and transclusions of special pages
too (see T19597), so we may as well make it possible to query for those
as well via list=alllinks, list=alltransclusions, list=backlinks,
list=embeddedin, prop=linkshere, prop=transcludedin, prop=links, and
prop=templates.
NS_MEDIA has similar considerations: although we currently "normalize"
page links to the corresponding File and I don't think anything logs the
Media title rather than the File, transclusions and redirects do show
up in those tables.
Bug: T154319
Change-Id: I00348f83855c6c703b6bd6015f6d3bedc5bfd1c5
2017-01-06 17:49:27 +00:00
|
|
|
/**
|
|
|
|
|
* Get a Title object from a title or pageid param, if possible.
|
|
|
|
|
* Can die, if no param is set or if the title or page id is not valid.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.29
|
2017-07-07 00:01:30 +00:00
|
|
|
* @param array $params User provided set of parameters, as from $this->extractRequestParams()
|
API: Allow finding log events and links to special pages
Log events are sometimes attributed to a special page; it should be
allowed to use rcnamespace or lenamespace to filter for these.
It's also possible for special pages to be the targets of redirects, so
list=allredirects and prop=redirects should find them.
Maybe someday we'll record links to and transclusions of special pages
too (see T19597), so we may as well make it possible to query for those
as well via list=alllinks, list=alltransclusions, list=backlinks,
list=embeddedin, prop=linkshere, prop=transcludedin, prop=links, and
prop=templates.
NS_MEDIA has similar considerations: although we currently "normalize"
page links to the corresponding File and I don't think anything logs the
Media title rather than the File, transclusions and redirects do show
up in those tables.
Bug: T154319
Change-Id: I00348f83855c6c703b6bd6015f6d3bedc5bfd1c5
2017-01-06 17:49:27 +00:00
|
|
|
* @return Title
|
|
|
|
|
*/
|
|
|
|
|
public function getTitleFromTitleOrPageId( $params ) {
|
|
|
|
|
$this->requireOnlyOneParameter( $params, 'title', 'pageid' );
|
|
|
|
|
|
|
|
|
|
$titleObj = null;
|
|
|
|
|
if ( isset( $params['title'] ) ) {
|
|
|
|
|
$titleObj = Title::newFromText( $params['title'] );
|
|
|
|
|
if ( !$titleObj || $titleObj->isExternal() ) {
|
|
|
|
|
$this->dieWithError( [ 'apierror-invalidtitle', wfEscapeWikiText( $params['title'] ) ] );
|
|
|
|
|
}
|
|
|
|
|
return $titleObj;
|
|
|
|
|
} elseif ( isset( $params['pageid'] ) ) {
|
|
|
|
|
$titleObj = Title::newFromID( $params['pageid'] );
|
|
|
|
|
if ( !$titleObj ) {
|
|
|
|
|
$this->dieWithError( [ 'apierror-nosuchpageid', $params['pageid'] ] );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $titleObj;
|
|
|
|
|
}
|
|
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Return true if we're to watch the page, false if not, null if no change.
|
|
|
|
|
* @param string $watchlist Valid values: 'watch', 'unwatch', 'preferences', 'nochange'
|
|
|
|
|
* @param Title $titleObj The page under consideration
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $userOption The user option to consider when $watchlist=preferences.
|
2014-08-27 19:41:05 +00:00
|
|
|
* If not set will use watchdefault always and watchcreations if $titleObj doesn't exist.
|
|
|
|
|
* @return bool
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
protected function getWatchlistValue( $watchlist, $titleObj, $userOption = null ) {
|
2016-02-01 11:53:01 +00:00
|
|
|
$userWatching = $this->getUser()->isWatched( $titleObj, User::IGNORE_USER_RIGHTS );
|
2006-10-01 04:38:31 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
switch ( $watchlist ) {
|
|
|
|
|
case 'watch':
|
|
|
|
|
return true;
|
2006-10-01 04:38:31 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
case 'unwatch':
|
|
|
|
|
return false;
|
2010-02-09 08:37:38 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
case 'preferences':
|
|
|
|
|
# If the user is already watching, don't bother checking
|
|
|
|
|
if ( $userWatching ) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
# If no user option was passed, use watchdefault and watchcreations
|
2020-01-09 23:48:34 +00:00
|
|
|
if ( $userOption === null ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
return $this->getUser()->getBoolOption( 'watchdefault' ) ||
|
|
|
|
|
$this->getUser()->getBoolOption( 'watchcreations' ) && !$titleObj->exists();
|
|
|
|
|
}
|
2014-08-08 16:56:07 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
# Watch the article based on the user preference
|
|
|
|
|
return $this->getUser()->getBoolOption( $userOption );
|
2014-08-08 16:56:07 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
case 'nochange':
|
|
|
|
|
return $userWatching;
|
2013-11-14 12:40:22 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
default:
|
|
|
|
|
return $userWatching;
|
|
|
|
|
}
|
2008-09-07 19:04:51 +00:00
|
|
|
}
|
2009-02-11 19:25:25 +00:00
|
|
|
|
|
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Using the settings determine the value for the given parameter
|
2011-11-28 15:33:28 +00:00
|
|
|
*
|
2019-08-21 19:53:53 +00:00
|
|
|
* @param string $name Parameter name
|
|
|
|
|
* @param array|mixed $settings Default value or an array of settings
|
2014-08-27 19:41:05 +00:00
|
|
|
* using PARAM_* constants.
|
2017-12-28 15:06:10 +00:00
|
|
|
* @param bool $parseLimit Whether to parse and validate 'limit' parameters
|
2014-08-27 19:41:05 +00:00
|
|
|
* @return mixed Parameter value
|
2009-02-11 19:25:25 +00:00
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
protected function getParameterFromSettings( $name, $settings, $parseLimit ) {
|
|
|
|
|
$validator = $this->getMain()->getParamValidator();
|
|
|
|
|
$value = $validator->getValue( $this, $name, $settings, [
|
|
|
|
|
'parse-limit' => $parseLimit,
|
|
|
|
|
] );
|
2017-05-25 20:07:25 +00:00
|
|
|
|
2019-08-21 19:53:53 +00:00
|
|
|
// @todo Deprecate and remove this, if possible.
|
|
|
|
|
if ( $parseLimit && isset( $settings[ParamValidator::PARAM_TYPE] ) &&
|
|
|
|
|
$settings[ParamValidator::PARAM_TYPE] === 'limit' &&
|
|
|
|
|
$this->getMain()->getVal( $this->encodeParamName( $name ) ) === 'max'
|
|
|
|
|
) {
|
|
|
|
|
$this->getResult()->addParsedLimit( $this->getModuleName(), $value );
|
2006-10-21 08:26:32 +00:00
|
|
|
}
|
2006-10-17 02:01:20 +00:00
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
return $value;
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-24 18:07:43 +00:00
|
|
|
/**
|
|
|
|
|
* Handle when a parameter was Unicode-normalized
|
|
|
|
|
* @since 1.28
|
2019-08-21 19:53:53 +00:00
|
|
|
* @since 1.35 $paramName is prefixed
|
|
|
|
|
* @internal For overriding by subclasses and use by ApiParamValidatorCallbacks only.
|
|
|
|
|
* @param string $paramName Prefixed parameter name
|
2016-08-24 18:07:43 +00:00
|
|
|
* @param string $value Input that will be used.
|
|
|
|
|
* @param string $rawValue Input before normalization.
|
|
|
|
|
*/
|
2019-08-21 19:53:53 +00:00
|
|
|
public function handleParamNormalization( $paramName, $value, $rawValue ) {
|
|
|
|
|
$this->addWarning( [ 'apiwarn-badutf8', $paramName ] );
|
2011-06-05 23:18:22 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Validate the supplied token.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.24
|
|
|
|
|
* @param string $token Supplied token
|
|
|
|
|
* @param array $params All supplied parameters for the module
|
|
|
|
|
* @return bool
|
2014-12-24 13:49:20 +00:00
|
|
|
* @throws MWException
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
2014-10-30 16:54:07 +00:00
|
|
|
final public function validateToken( $token, array $params ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
$tokenType = $this->needsToken();
|
|
|
|
|
$salts = ApiQueryTokens::getTokenTypeSalts();
|
|
|
|
|
if ( !isset( $salts[$tokenType] ) ) {
|
|
|
|
|
throw new MWException(
|
|
|
|
|
"Module '{$this->getModuleName()}' tried to use token type '$tokenType' " .
|
|
|
|
|
'without registering it'
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-01 20:44:03 +00:00
|
|
|
$tokenObj = ApiQueryTokens::getToken(
|
|
|
|
|
$this->getUser(), $this->getRequest()->getSession(), $salts[$tokenType]
|
|
|
|
|
);
|
|
|
|
|
if ( $tokenObj->match( $token ) ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$webUiSalt = $this->getWebUITokenSalt( $params );
|
|
|
|
|
if ( $webUiSalt !== null && $this->getUser()->matchEditToken(
|
|
|
|
|
$token,
|
|
|
|
|
$webUiSalt,
|
|
|
|
|
$this->getRequest()
|
|
|
|
|
) ) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Utility methods
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
2010-10-03 20:07:23 +00:00
|
|
|
/**
|
2014-08-27 19:41:05 +00:00
|
|
|
* Set a watch (or unwatch) based the based on a watchlist parameter.
|
|
|
|
|
* @param string $watch Valid values: 'watch', 'unwatch', 'preferences', 'nochange'
|
|
|
|
|
* @param Title $titleObj The article's title to change
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $userOption The user option to consider when $watch=preferences
|
2010-10-03 20:07:23 +00:00
|
|
|
*/
|
2014-08-27 19:41:05 +00:00
|
|
|
protected function setWatch( $watch, $titleObj, $userOption = null ) {
|
|
|
|
|
$value = $this->getWatchlistValue( $watch, $titleObj, $userOption );
|
|
|
|
|
if ( $value === null ) {
|
|
|
|
|
return;
|
2010-10-03 20:07:23 +00:00
|
|
|
}
|
2013-11-17 19:54:11 +00:00
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
WatchAction::doWatchOrUnwatch( $value, $titleObj, $this->getUser() );
|
2010-10-03 20:07:23 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
|
|
|
|
* Gets the user for whom to get the watchlist
|
|
|
|
|
*
|
|
|
|
|
* @param array $params
|
|
|
|
|
* @return User
|
|
|
|
|
*/
|
|
|
|
|
public function getWatchlistUser( $params ) {
|
2020-01-09 23:48:34 +00:00
|
|
|
if ( $params['owner'] !== null && $params['token'] !== null ) {
|
2014-08-27 19:41:05 +00:00
|
|
|
$user = User::newFromName( $params['owner'], false );
|
|
|
|
|
if ( !( $user && $user->getId() ) ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
|
|
|
|
[ 'nosuchusershort', wfEscapeWikiText( $params['owner'] ) ], 'bad_wlowner'
|
|
|
|
|
);
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
$token = $user->getOption( 'watchlisttoken' );
|
2015-03-27 15:49:58 +00:00
|
|
|
if ( $token == '' || !hash_equals( $token, $params['token'] ) ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( 'apierror-bad-watchlist-token', 'bad_wltoken' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if ( !$this->getUser()->isLoggedIn() ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( 'watchlistanontext', 'notloggedin' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->checkUserRightsAny( 'viewmywatchlist' );
|
2014-08-27 19:41:05 +00:00
|
|
|
$user = $this->getUser();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $user;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Create a Message from a string or array
|
|
|
|
|
*
|
|
|
|
|
* A string is used as a message key. An array has the message key as the
|
|
|
|
|
* first value and message parameters as subsequent values.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25
|
|
|
|
|
* @param string|array|Message $msg
|
|
|
|
|
* @param IContextSource $context
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param array|null $params
|
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
|
|
|
* @return Message|null
|
|
|
|
|
*/
|
|
|
|
|
public static function makeMessage( $msg, IContextSource $context, array $params = null ) {
|
|
|
|
|
if ( is_string( $msg ) ) {
|
|
|
|
|
$msg = wfMessage( $msg );
|
|
|
|
|
} elseif ( is_array( $msg ) ) {
|
2018-06-05 06:24:34 +00:00
|
|
|
$msg = wfMessage( ...$msg );
|
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
|
|
|
}
|
|
|
|
|
if ( !$msg instanceof Message ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$msg->setContext( $context );
|
|
|
|
|
if ( $params ) {
|
|
|
|
|
$msg->params( $params );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $msg;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
/**
|
|
|
|
|
* Turn an array of message keys or key+param arrays into a Status
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param array $errors
|
|
|
|
|
* @param User|null $user
|
|
|
|
|
* @return Status
|
|
|
|
|
*/
|
|
|
|
|
public function errorArrayToStatus( array $errors, User $user = null ) {
|
|
|
|
|
if ( $user === null ) {
|
|
|
|
|
$user = $this->getUser();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$status = Status::newGood();
|
|
|
|
|
foreach ( $errors as $error ) {
|
2019-03-01 14:49:05 +00:00
|
|
|
if ( !is_array( $error ) ) {
|
|
|
|
|
$error = [ $error ];
|
|
|
|
|
}
|
|
|
|
|
if ( is_string( $error[0] ) && isset( self::$blockMsgMap[$error[0]] ) && $user->getBlock() ) {
|
2019-02-18 20:30:41 +00:00
|
|
|
list( $msg, $code ) = self::$blockMsgMap[$error[0]];
|
|
|
|
|
$status->fatal( ApiMessage::create( $msg, $code,
|
2019-05-09 10:13:30 +00:00
|
|
|
[ 'blockinfo' => $this->getBlockDetails( $user->getBlock() ) ]
|
2016-12-01 16:51:03 +00:00
|
|
|
) );
|
2016-10-19 16:54:25 +00:00
|
|
|
} else {
|
2019-03-01 14:49:05 +00:00
|
|
|
$status->fatal( ...$error );
|
2016-10-19 16:54:25 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return $status;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-18 20:30:41 +00:00
|
|
|
/**
|
|
|
|
|
* Add block info to block messages in a Status
|
|
|
|
|
* @since 1.33
|
|
|
|
|
* @param StatusValue $status
|
|
|
|
|
* @param User|null $user
|
|
|
|
|
*/
|
|
|
|
|
public function addBlockInfoToStatus( StatusValue $status, User $user = null ) {
|
|
|
|
|
if ( $user === null ) {
|
|
|
|
|
$user = $this->getUser();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach ( self::$blockMsgMap as $msg => list( $apiMsg, $code ) ) {
|
|
|
|
|
if ( $status->hasMessage( $msg ) && $user->getBlock() ) {
|
|
|
|
|
$status->replaceMessage( $msg, ApiMessage::create( $apiMsg, $code,
|
2019-05-09 10:13:30 +00:00
|
|
|
[ 'blockinfo' => $this->getBlockDetails( $user->getBlock() ) ]
|
2019-02-18 20:30:41 +00:00
|
|
|
) );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-10 17:55:09 +00:00
|
|
|
/**
|
|
|
|
|
* Call wfTransactionalTimeLimit() if this request was POSTed
|
|
|
|
|
* @since 1.26
|
|
|
|
|
*/
|
|
|
|
|
protected function useTransactionalTimeLimit() {
|
|
|
|
|
if ( $this->getRequest()->wasPosted() ) {
|
|
|
|
|
wfTransactionalTimeLimit();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-14 18:55:22 +00:00
|
|
|
/**
|
|
|
|
|
* Filter out-of-range values from a list of positive integer IDs
|
|
|
|
|
* @since 1.33
|
|
|
|
|
* @param array $fields Array of pairs of table and field to check
|
|
|
|
|
* @param (string|int)[] $ids IDs to filter. Strings in the array are
|
|
|
|
|
* expected to be stringified ints.
|
|
|
|
|
* @return (string|int)[] Filtered IDs.
|
|
|
|
|
*/
|
|
|
|
|
protected function filterIDs( $fields, array $ids ) {
|
|
|
|
|
$min = INF;
|
|
|
|
|
$max = 0;
|
|
|
|
|
foreach ( $fields as list( $table, $field ) ) {
|
|
|
|
|
if ( isset( self::$filterIDsCache[$table][$field] ) ) {
|
|
|
|
|
$row = self::$filterIDsCache[$table][$field];
|
|
|
|
|
} else {
|
|
|
|
|
$row = $this->getDB()->selectRow(
|
|
|
|
|
$table,
|
|
|
|
|
[
|
|
|
|
|
'min_id' => "MIN($field)",
|
|
|
|
|
'max_id' => "MAX($field)",
|
|
|
|
|
],
|
2018-12-12 14:25:00 +00:00
|
|
|
'',
|
2016-07-14 18:55:22 +00:00
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
self::$filterIDsCache[$table][$field] = $row;
|
|
|
|
|
}
|
|
|
|
|
$min = min( $min, $row->min_id );
|
|
|
|
|
$max = max( $max, $row->max_id );
|
|
|
|
|
}
|
|
|
|
|
return array_filter( $ids, function ( $id ) use ( $min, $max ) {
|
|
|
|
|
return ( is_int( $id ) && $id >= 0 || ctype_digit( $id ) )
|
|
|
|
|
&& $id >= $min && $id <= $max;
|
|
|
|
|
} );
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Warning and error reporting
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Add a warning for this module.
|
|
|
|
|
*
|
|
|
|
|
* Users should monitor this section to notice any changes in API. Multiple
|
|
|
|
|
* calls to this function will result in multiple warning messages.
|
|
|
|
|
*
|
|
|
|
|
* If $msg is not an ApiMessage, the message code will be derived from the
|
|
|
|
|
* message key by stripping any "apiwarn-" or "apierror-" prefix.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|array|Message $msg See ApiErrorFormatter::addWarning()
|
|
|
|
|
* @param string|null $code See ApiErrorFormatter::addWarning()
|
|
|
|
|
* @param array|null $data See ApiErrorFormatter::addWarning()
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
public function addWarning( $msg, $code = null, $data = null ) {
|
|
|
|
|
$this->getErrorFormatter()->addWarning( $this->getModulePath(), $msg, $code, $data );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Add a deprecation warning for this module.
|
2014-08-27 19:41:05 +00:00
|
|
|
*
|
2016-10-19 16:54:25 +00:00
|
|
|
* A combination of $this->addWarning() and $this->logFeatureUsage()
|
|
|
|
|
*
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|array|Message $msg See ApiErrorFormatter::addWarning()
|
|
|
|
|
* @param string|null $feature See ApiBase::logFeatureUsage()
|
|
|
|
|
* @param array|null $data See ApiErrorFormatter::addWarning()
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
public function addDeprecation( $msg, $feature, $data = [] ) {
|
|
|
|
|
$data = (array)$data;
|
|
|
|
|
if ( $feature !== null ) {
|
|
|
|
|
$data['feature'] = $feature;
|
|
|
|
|
$this->logFeatureUsage( $feature );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->addWarning( $msg, 'deprecation', $data );
|
2017-01-09 23:38:36 +00:00
|
|
|
|
|
|
|
|
// No real need to deduplicate here, ApiErrorFormatter does that for
|
|
|
|
|
// us (assuming the hook is deterministic).
|
|
|
|
|
$msgs = [ $this->msg( 'api-usage-mailinglist-ref' ) ];
|
|
|
|
|
Hooks::run( 'ApiDeprecationHelp', [ &$msgs ] );
|
|
|
|
|
if ( count( $msgs ) > 1 ) {
|
2018-02-17 12:29:13 +00:00
|
|
|
$key = '$' . implode( ' $', range( 1, count( $msgs ) ) );
|
2017-01-09 23:38:36 +00:00
|
|
|
$msg = ( new RawMessage( $key ) )->params( $msgs );
|
|
|
|
|
} else {
|
|
|
|
|
$msg = reset( $msgs );
|
|
|
|
|
}
|
|
|
|
|
$this->getMain()->addWarning( $msg, 'deprecation-help' );
|
2016-10-19 16:54:25 +00:00
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
/**
|
|
|
|
|
* Add an error for this module without aborting
|
|
|
|
|
*
|
|
|
|
|
* If $msg is not an ApiMessage, the message code will be derived from the
|
|
|
|
|
* message key by stripping any "apiwarn-" or "apierror-" prefix.
|
|
|
|
|
*
|
|
|
|
|
* @note If you want to abort processing, use self::dieWithError() instead.
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|array|Message $msg See ApiErrorFormatter::addError()
|
|
|
|
|
* @param string|null $code See ApiErrorFormatter::addError()
|
|
|
|
|
* @param array|null $data See ApiErrorFormatter::addError()
|
|
|
|
|
*/
|
|
|
|
|
public function addError( $msg, $code = null, $data = null ) {
|
|
|
|
|
$this->getErrorFormatter()->addError( $this->getModulePath(), $msg, $code, $data );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Add warnings and/or errors from a Status
|
2009-07-23 23:50:04 +00:00
|
|
|
*
|
2016-10-19 16:54:25 +00:00
|
|
|
* @note If you want to abort processing, use self::dieStatus() instead.
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param StatusValue $status
|
|
|
|
|
* @param string[] $types 'warning' and/or 'error'
|
2018-12-20 14:59:02 +00:00
|
|
|
* @param string[] $filter Message keys to filter out (since 1.33)
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
2018-12-20 14:59:02 +00:00
|
|
|
public function addMessagesFromStatus(
|
|
|
|
|
StatusValue $status, $types = [ 'warning', 'error' ], array $filter = []
|
|
|
|
|
) {
|
|
|
|
|
$this->getErrorFormatter()->addMessagesFromStatus(
|
|
|
|
|
$this->getModulePath(), $status, $types, $filter
|
|
|
|
|
);
|
2016-10-19 16:54:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Abort execution with an error
|
|
|
|
|
*
|
|
|
|
|
* If $msg is not an ApiMessage, the message code will be derived from the
|
|
|
|
|
* message key by stripping any "apiwarn-" or "apierror-" prefix.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|array|Message $msg See ApiErrorFormatter::addError()
|
|
|
|
|
* @param string|null $code See ApiErrorFormatter::addError()
|
|
|
|
|
* @param array|null $data See ApiErrorFormatter::addError()
|
|
|
|
|
* @param int|null $httpCode HTTP error code to use
|
|
|
|
|
* @throws ApiUsageException always
|
|
|
|
|
*/
|
|
|
|
|
public function dieWithError( $msg, $code = null, $data = null, $httpCode = null ) {
|
|
|
|
|
throw ApiUsageException::newWithMessage( $this, $msg, $code, $data, $httpCode );
|
2006-10-01 04:38:31 +00:00
|
|
|
}
|
2008-04-14 07:45:50 +00:00
|
|
|
|
2016-12-08 18:38:45 +00:00
|
|
|
/**
|
2019-12-29 19:44:43 +00:00
|
|
|
* Abort execution with an error derived from a throwable
|
2016-12-08 18:38:45 +00:00
|
|
|
*
|
|
|
|
|
* @since 1.29
|
2019-12-29 19:44:43 +00:00
|
|
|
* @param Throwable $exception See ApiErrorFormatter::getMessageFromException()
|
2016-12-08 18:38:45 +00:00
|
|
|
* @param array $options See ApiErrorFormatter::getMessageFromException()
|
|
|
|
|
* @throws ApiUsageException always
|
|
|
|
|
*/
|
2019-12-29 19:44:43 +00:00
|
|
|
public function dieWithException( Throwable $exception, array $options = [] ) {
|
2016-12-08 18:38:45 +00:00
|
|
|
$this->dieWithError(
|
2019-06-18 20:26:00 +00:00
|
|
|
// @phan-suppress-next-line PhanTypeMismatchArgument
|
2016-12-08 18:38:45 +00:00
|
|
|
$this->getErrorFormatter()->getMessageFromException( $exception, $options )
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
/**
|
|
|
|
|
* Throw an ApiUsageException, which will (if uncaught) call the main module's
|
2015-12-21 22:59:16 +00:00
|
|
|
* error handler and die with an error message including block info.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.27
|
2019-05-14 12:42:50 +00:00
|
|
|
* @param AbstractBlock $block The block used to generate the ApiUsageException
|
2016-10-19 16:54:25 +00:00
|
|
|
* @throws ApiUsageException always
|
2015-12-21 22:59:16 +00:00
|
|
|
*/
|
Separate Block into AbstractBlock, Block and SystemBlock
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
2019-03-18 22:09:49 +00:00
|
|
|
public function dieBlocked( AbstractBlock $block ) {
|
2015-12-21 22:59:16 +00:00
|
|
|
// Die using the appropriate message depending on block type
|
2019-05-13 14:18:07 +00:00
|
|
|
if ( $block->getType() == DatabaseBlock::TYPE_AUTO ) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
|
|
|
|
'apierror-autoblocked',
|
2015-12-21 22:59:16 +00:00
|
|
|
'autoblocked',
|
2019-05-09 10:13:30 +00:00
|
|
|
[ 'blockinfo' => $this->getBlockDetails( $block ) ]
|
2015-12-21 22:59:16 +00:00
|
|
|
);
|
2018-08-27 01:45:18 +00:00
|
|
|
} elseif ( !$block->isSitewide() ) {
|
|
|
|
|
$this->dieWithError(
|
|
|
|
|
'apierror-blocked-partial',
|
|
|
|
|
'blocked',
|
2019-05-09 10:13:30 +00:00
|
|
|
[ 'blockinfo' => $this->getBlockDetails( $block ) ]
|
2018-08-27 01:45:18 +00:00
|
|
|
);
|
2015-12-21 22:59:16 +00:00
|
|
|
} else {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
|
|
|
|
'apierror-blocked',
|
2015-12-21 22:59:16 +00:00
|
|
|
'blocked',
|
2019-05-09 10:13:30 +00:00
|
|
|
[ 'blockinfo' => $this->getBlockDetails( $block ) ]
|
2015-12-21 22:59:16 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-13 17:56:29 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Throw an ApiUsageException based on the Status object.
|
2013-06-13 17:56:29 +00:00
|
|
|
*
|
2016-10-19 16:54:25 +00:00
|
|
|
* @since 1.22
|
|
|
|
|
* @since 1.29 Accepts a StatusValue
|
|
|
|
|
* @param StatusValue $status
|
|
|
|
|
* @throws ApiUsageException always
|
2013-06-13 17:56:29 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
public function dieStatus( StatusValue $status ) {
|
2013-06-13 17:56:29 +00:00
|
|
|
if ( $status->isGood() ) {
|
|
|
|
|
throw new MWException( 'Successful status passed to ApiBase::dieStatus' );
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-12 16:54:24 +00:00
|
|
|
// ApiUsageException needs a fatal status, but this method has
|
|
|
|
|
// historically accepted any non-good status. Convert it if necessary.
|
|
|
|
|
$status->setOK( false );
|
|
|
|
|
if ( !$status->getErrorsByType( 'error' ) ) {
|
|
|
|
|
$newStatus = Status::newGood();
|
|
|
|
|
foreach ( $status->getErrorsByType( 'warning' ) as $err ) {
|
2018-06-05 06:24:34 +00:00
|
|
|
$newStatus->fatal( $err['message'], ...$err['params'] );
|
2017-06-12 16:54:24 +00:00
|
|
|
}
|
|
|
|
|
if ( !$newStatus->getErrorsByType( 'error' ) ) {
|
|
|
|
|
$newStatus->fatal( 'unknownerror-nocode' );
|
|
|
|
|
}
|
|
|
|
|
$status = $newStatus;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-18 20:30:41 +00:00
|
|
|
$this->addBlockInfoToStatus( $status );
|
2016-10-19 16:54:25 +00:00
|
|
|
throw new ApiUsageException( $this, $status );
|
2014-01-29 18:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
2009-07-12 12:38:03 +00:00
|
|
|
/**
|
|
|
|
|
* Helper function for readonly errors
|
2015-09-02 12:13:45 +00:00
|
|
|
*
|
2016-10-19 16:54:25 +00:00
|
|
|
* @throws ApiUsageException always
|
2009-07-12 12:38:03 +00:00
|
|
|
*/
|
|
|
|
|
public function dieReadOnly() {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError(
|
|
|
|
|
'apierror-readonly',
|
|
|
|
|
'readonly',
|
|
|
|
|
[ 'readonlyreason' => wfReadOnlyReason() ]
|
|
|
|
|
);
|
2009-07-12 12:38:03 +00:00
|
|
|
}
|
|
|
|
|
|
2008-01-15 20:21:16 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Helper function for permission-denied errors
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|string[] $rights
|
|
|
|
|
* @param User|null $user
|
|
|
|
|
* @throws ApiUsageException if the user doesn't have any of the rights.
|
|
|
|
|
* The error message is based on $rights[0].
|
2008-01-15 20:21:16 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
public function checkUserRightsAny( $rights, $user = null ) {
|
|
|
|
|
if ( !$user ) {
|
|
|
|
|
$user = $this->getUser();
|
|
|
|
|
}
|
|
|
|
|
$rights = (array)$rights;
|
2019-08-21 22:42:08 +00:00
|
|
|
if ( !$this->getPermissionManager()
|
2020-03-26 04:13:20 +00:00
|
|
|
->userHasAnyRight( $user, ...$rights )
|
2019-08-21 22:42:08 +00:00
|
|
|
) {
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieWithError( [ 'apierror-permissiondenied', $this->msg( "action-{$rights[0]}" ) ] );
|
2011-05-14 11:19:59 +00:00
|
|
|
}
|
2009-02-09 14:16:51 +00:00
|
|
|
}
|
2010-02-09 08:37:38 +00:00
|
|
|
|
2013-01-18 15:23:17 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Helper function for permission-denied errors
|
2019-05-18 16:58:24 +00:00
|
|
|
*
|
|
|
|
|
* @param LinkTarget $linkTarget
|
2016-10-19 16:54:25 +00:00
|
|
|
* @param string|string[] $actions
|
2019-02-18 19:46:05 +00:00
|
|
|
* @param array $options Additional options
|
|
|
|
|
* - user: (User) User to use rather than $this->getUser()
|
|
|
|
|
* - autoblock: (bool, default false) Whether to spread autoblocks
|
2016-10-19 16:54:25 +00:00
|
|
|
* @throws ApiUsageException if the user doesn't have all of the rights.
|
2019-05-18 16:58:24 +00:00
|
|
|
*
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @since 1.33 Changed the third parameter from $user to $options.
|
2013-01-18 15:23:17 +00:00
|
|
|
*/
|
2020-01-08 19:19:22 +00:00
|
|
|
public function checkTitleUserPermissions(
|
|
|
|
|
LinkTarget $linkTarget,
|
|
|
|
|
$actions,
|
|
|
|
|
array $options = []
|
|
|
|
|
) {
|
2019-02-18 19:46:05 +00:00
|
|
|
$user = $options['user'] ?? $this->getUser();
|
2013-11-17 19:54:11 +00:00
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
$errors = [];
|
|
|
|
|
foreach ( (array)$actions as $action ) {
|
2019-05-18 16:58:24 +00:00
|
|
|
$errors = array_merge(
|
|
|
|
|
$errors,
|
|
|
|
|
$this->getPermissionManager()->getPermissionErrors( $action, $user, $linkTarget )
|
|
|
|
|
);
|
2016-10-19 16:54:25 +00:00
|
|
|
}
|
2018-11-16 03:33:47 +00:00
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
if ( $errors ) {
|
2019-02-18 19:46:05 +00:00
|
|
|
if ( !empty( $options['autoblock'] ) ) {
|
|
|
|
|
$user->spreadAnyEditBlock();
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-19 16:54:25 +00:00
|
|
|
$this->dieStatus( $this->errorArrayToStatus( $errors, $user ) );
|
2013-11-17 19:54:11 +00:00
|
|
|
}
|
2013-01-18 15:23:17 +00:00
|
|
|
}
|
|
|
|
|
|
2013-03-02 00:06:46 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Will only set a warning instead of failing if the global $wgDebugAPI
|
|
|
|
|
* is set to true. Otherwise behaves exactly as self::dieWithError().
|
|
|
|
|
*
|
|
|
|
|
* @since 1.29
|
|
|
|
|
* @param string|array|Message $msg
|
|
|
|
|
* @param string|null $code
|
|
|
|
|
* @param array|null $data
|
|
|
|
|
* @param int|null $httpCode
|
|
|
|
|
* @throws ApiUsageException
|
2013-03-02 00:06:46 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
public function dieWithErrorOrDebug( $msg, $code = null, $data = null, $httpCode = null ) {
|
|
|
|
|
if ( $this->getConfig()->get( 'DebugAPI' ) !== true ) {
|
|
|
|
|
$this->dieWithError( $msg, $code, $data, $httpCode );
|
|
|
|
|
} else {
|
|
|
|
|
$this->addWarning( $msg, $code, $data );
|
2013-03-02 00:06:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-09 14:16:51 +00:00
|
|
|
/**
|
2016-10-19 16:54:25 +00:00
|
|
|
* Die with the 'badcontinue' error.
|
|
|
|
|
*
|
|
|
|
|
* This call is common enough to make it into the base method.
|
|
|
|
|
*
|
|
|
|
|
* @param bool $condition Will only die if this value is true
|
|
|
|
|
* @throws ApiUsageException
|
|
|
|
|
* @since 1.21
|
2019-12-22 21:50:29 +00:00
|
|
|
* @phan-assert-false-condition $condition
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
2016-10-19 16:54:25 +00:00
|
|
|
protected function dieContinueUsageIf( $condition ) {
|
|
|
|
|
if ( $condition ) {
|
|
|
|
|
$this->dieWithError( 'apierror-badcontinue' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Internal code errors should be reported with this method
|
|
|
|
|
* @param string $method Method or function name
|
|
|
|
|
* @param string $message Error message
|
2015-09-02 12:13:45 +00:00
|
|
|
* @throws MWException always
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
|
|
|
|
protected static function dieDebug( $method, $message ) {
|
|
|
|
|
throw new MWException( "Internal error in $method: $message" );
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-10 22:26:31 +00:00
|
|
|
/**
|
|
|
|
|
* Write logging information for API features to a debug log, for usage
|
|
|
|
|
* analysis.
|
2016-10-19 16:54:25 +00:00
|
|
|
* @note Consider using $this->addDeprecation() instead to both warn and log.
|
2015-03-10 22:26:31 +00:00
|
|
|
* @param string $feature Feature being used.
|
|
|
|
|
*/
|
2016-08-18 17:36:11 +00:00
|
|
|
public function logFeatureUsage( $feature ) {
|
2019-03-05 22:43:16 +00:00
|
|
|
static $loggedFeatures = [];
|
|
|
|
|
|
|
|
|
|
// Only log each feature once per request. We can get multiple calls from calls to
|
|
|
|
|
// extractRequestParams() with different values for 'parseLimit', for example.
|
|
|
|
|
if ( isset( $loggedFeatures[$feature] ) ) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
$loggedFeatures[$feature] = true;
|
|
|
|
|
|
2015-03-10 22:26:31 +00:00
|
|
|
$request = $this->getRequest();
|
2019-02-27 20:51:38 +00:00
|
|
|
$ctx = [
|
|
|
|
|
'feature' => $feature,
|
|
|
|
|
// Spaces to underscores in 'username' for historical reasons.
|
|
|
|
|
'username' => str_replace( ' ', '_', $this->getUser()->getName() ),
|
2020-02-14 17:46:10 +00:00
|
|
|
'clientip' => $request->getIP(),
|
2019-02-27 20:51:38 +00:00
|
|
|
'referer' => (string)$request->getHeader( 'Referer' ),
|
|
|
|
|
'agent' => $this->getMain()->getUserAgent(),
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
// Text string is deprecated. Remove (or replace with just $feature) in MW 1.34.
|
|
|
|
|
$s = '"' . addslashes( $ctx['feature'] ) . '"' .
|
|
|
|
|
' "' . wfUrlencode( $ctx['username'] ) . '"' .
|
2020-02-14 17:46:10 +00:00
|
|
|
' "' . $ctx['clientip'] . '"' .
|
2019-02-27 20:51:38 +00:00
|
|
|
' "' . addslashes( $ctx['referer'] ) . '"' .
|
|
|
|
|
' "' . addslashes( $ctx['agent'] ) . '"';
|
|
|
|
|
|
|
|
|
|
wfDebugLog( 'api-feature-usage', $s, 'private', $ctx );
|
2015-03-10 22:26:31 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Help message generation
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
2014-09-18 17:38:23 +00:00
|
|
|
/**
|
2017-05-26 17:50:06 +00:00
|
|
|
* Return the summary message.
|
|
|
|
|
*
|
|
|
|
|
* This is a one-line description of the module, suitable for display in a
|
|
|
|
|
* list of modules.
|
2014-09-18 17:38:23 +00:00
|
|
|
*
|
2017-05-26 17:50:06 +00:00
|
|
|
* @since 1.30
|
2014-09-18 17:38:23 +00:00
|
|
|
* @return string|array|Message
|
|
|
|
|
*/
|
2017-05-26 17:50:06 +00:00
|
|
|
protected function getSummaryMessage() {
|
|
|
|
|
return "apihelp-{$this->getModulePath()}-summary";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Return the extended help text message.
|
|
|
|
|
*
|
|
|
|
|
* This is additional text to display at the top of the help section, below
|
|
|
|
|
* the summary.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.30
|
|
|
|
|
* @return string|array|Message
|
|
|
|
|
*/
|
|
|
|
|
protected function getExtendedDescription() {
|
|
|
|
|
return [ [
|
|
|
|
|
"apihelp-{$this->getModulePath()}-extended-description",
|
|
|
|
|
'api-help-no-extended-description',
|
|
|
|
|
] ];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get final module summary
|
|
|
|
|
*
|
|
|
|
|
* @since 1.30
|
|
|
|
|
* @return Message
|
|
|
|
|
*/
|
|
|
|
|
public function getFinalSummary() {
|
2017-07-23 01:24:09 +00:00
|
|
|
$msg = self::makeMessage( $this->getSummaryMessage(), $this->getContext(), [
|
2017-05-26 17:50:06 +00:00
|
|
|
$this->getModulePrefix(),
|
|
|
|
|
$this->getModuleName(),
|
|
|
|
|
$this->getModulePath(),
|
|
|
|
|
] );
|
|
|
|
|
return $msg;
|
2014-09-18 17:38:23 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-27 19:41:05 +00:00
|
|
|
/**
|
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
|
|
|
* Get final module description, after hooks have had a chance to tweak it as
|
|
|
|
|
* needed.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25, returns Message[] rather than string[]
|
|
|
|
|
* @return Message[]
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
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 getFinalDescription() {
|
2017-07-23 01:24:09 +00:00
|
|
|
$summary = self::makeMessage( $this->getSummaryMessage(), $this->getContext(), [
|
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
|
|
|
$this->getModulePrefix(),
|
|
|
|
|
$this->getModuleName(),
|
|
|
|
|
$this->getModulePath(),
|
2016-02-17 09:09:32 +00:00
|
|
|
] );
|
2017-07-23 01:24:09 +00:00
|
|
|
$extendedDescription = self::makeMessage(
|
2017-05-26 17:50:06 +00:00
|
|
|
$this->getExtendedDescription(), $this->getContext(), [
|
|
|
|
|
$this->getModulePrefix(),
|
|
|
|
|
$this->getModuleName(),
|
|
|
|
|
$this->getModulePath(),
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
|
2018-10-10 17:14:13 +00:00
|
|
|
$msgs = [ $summary, $extendedDescription ];
|
2014-08-27 19:41:05 +00:00
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
Hooks::run( 'APIGetDescriptionMessages', [ $this, &$msgs ] );
|
2014-08-27 19:41:05 +00:00
|
|
|
|
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
|
|
|
return $msgs;
|
|
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Get final list of parameters, after hooks have had a chance to
|
|
|
|
|
* tweak it as needed.
|
|
|
|
|
*
|
|
|
|
|
* @param int $flags Zero or more flags like GET_VALUES_FOR_HELP
|
|
|
|
|
* @return array|bool False on no parameters
|
|
|
|
|
* @since 1.21 $flags param added
|
|
|
|
|
*/
|
|
|
|
|
public function getFinalParams( $flags = 0 ) {
|
2019-09-26 14:17:03 +00:00
|
|
|
// @phan-suppress-next-line PhanParamTooMany
|
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
|
|
|
$params = $this->getAllowedParams( $flags );
|
|
|
|
|
if ( !$params ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$params = [];
|
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
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
|
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
|
|
|
if ( $this->needsToken() ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$params['token'] = [
|
2017-07-23 01:24:09 +00:00
|
|
|
self::PARAM_TYPE => 'string',
|
|
|
|
|
self::PARAM_REQUIRED => true,
|
|
|
|
|
self::PARAM_SENSITIVE => true,
|
|
|
|
|
self::PARAM_HELP_MSG => [
|
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
|
|
|
'api-help-param-token',
|
|
|
|
|
$this->needsToken(),
|
2016-02-17 09:09:32 +00:00
|
|
|
],
|
2017-10-06 22:17:58 +00:00
|
|
|
] + ( $params['token'] ?? [] );
|
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
|
|
|
}
|
|
|
|
|
|
2016-12-25 19:32:22 +00:00
|
|
|
// Avoid PHP 7.1 warning of passing $this by reference
|
|
|
|
|
$apiModule = $this;
|
|
|
|
|
Hooks::run( 'APIGetAllowedParams', [ &$apiModule, &$params, $flags ] );
|
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
|
|
|
|
|
|
|
|
return $params;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get final parameter descriptions, after hooks have had a chance to tweak it as
|
|
|
|
|
* needed.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.25, returns array of Message[] rather than array of string[]
|
|
|
|
|
* @return array Keys are parameter names, values are arrays of Message objects
|
|
|
|
|
*/
|
|
|
|
|
public function getFinalParamDescription() {
|
2014-11-07 23:57:14 +00:00
|
|
|
$prefix = $this->getModulePrefix();
|
|
|
|
|
$name = $this->getModuleName();
|
|
|
|
|
$path = $this->getModulePath();
|
|
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
$params = $this->getFinalParams( self::GET_VALUES_FOR_HELP );
|
2016-02-17 09:09:32 +00:00
|
|
|
$msgs = [];
|
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
|
|
|
foreach ( $params as $param => $settings ) {
|
|
|
|
|
if ( !is_array( $settings ) ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$settings = [];
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
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
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
if ( isset( $settings[self::PARAM_HELP_MSG] ) ) {
|
|
|
|
|
$msg = $settings[self::PARAM_HELP_MSG];
|
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
|
|
|
} else {
|
2014-11-07 23:57:14 +00:00
|
|
|
$msg = $this->msg( "apihelp-{$path}-param-{$param}" );
|
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
|
|
|
}
|
2017-07-23 01:24:09 +00:00
|
|
|
$msg = self::makeMessage( $msg, $this->getContext(),
|
2016-02-17 09:09:32 +00:00
|
|
|
[ $prefix, $param, $name, $path ] );
|
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
|
|
|
if ( !$msg ) {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
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
|
|
|
'Value in ApiBase::PARAM_HELP_MSG is not valid' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
2016-02-17 09:09:32 +00:00
|
|
|
$msgs[$param] = [ $msg ];
|
2014-08-27 19:41:05 +00:00
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
if ( isset( $settings[self::PARAM_TYPE] ) &&
|
|
|
|
|
$settings[self::PARAM_TYPE] === 'submodule'
|
2017-05-25 21:31:59 +00:00
|
|
|
) {
|
2017-07-23 01:24:09 +00:00
|
|
|
if ( isset( $settings[self::PARAM_SUBMODULE_MAP] ) ) {
|
|
|
|
|
$map = $settings[self::PARAM_SUBMODULE_MAP];
|
2017-05-25 21:31:59 +00:00
|
|
|
} else {
|
|
|
|
|
$prefix = $this->isMain() ? '' : ( $this->getModulePath() . '+' );
|
|
|
|
|
$map = [];
|
|
|
|
|
foreach ( $this->getModuleManager()->getNames( $param ) as $submoduleName ) {
|
|
|
|
|
$map[$submoduleName] = $prefix . $submoduleName;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-10-10 15:51:57 +00:00
|
|
|
|
2017-05-25 21:31:59 +00:00
|
|
|
$submodules = [];
|
2019-10-10 15:51:57 +00:00
|
|
|
$submoduleFlags = []; // for sorting: higher flags are sorted later
|
|
|
|
|
$submoduleNames = []; // for sorting: lexicographical, ascending
|
2017-05-25 21:31:59 +00:00
|
|
|
foreach ( $map as $v => $m ) {
|
|
|
|
|
$isDeprecated = false;
|
2019-10-10 15:51:57 +00:00
|
|
|
$isInternal = false;
|
2017-05-25 21:31:59 +00:00
|
|
|
$summary = null;
|
|
|
|
|
try {
|
|
|
|
|
$submod = $this->getModuleFromPath( $m );
|
|
|
|
|
if ( $submod ) {
|
|
|
|
|
$summary = $submod->getFinalSummary();
|
|
|
|
|
$isDeprecated = $submod->isDeprecated();
|
2019-10-10 15:51:57 +00:00
|
|
|
$isInternal = $submod->isInternal();
|
2017-05-25 21:31:59 +00:00
|
|
|
}
|
|
|
|
|
} catch ( ApiUsageException $ex ) {
|
|
|
|
|
// Ignore
|
|
|
|
|
}
|
|
|
|
|
if ( $summary ) {
|
|
|
|
|
$key = $summary->getKey();
|
|
|
|
|
$params = $summary->getParams();
|
|
|
|
|
} else {
|
|
|
|
|
$key = 'api-help-undocumented-module';
|
|
|
|
|
$params = [ $m ];
|
|
|
|
|
}
|
2019-10-10 15:51:57 +00:00
|
|
|
$m = new ApiHelpParamValueMessage(
|
|
|
|
|
"[[Special:ApiHelp/$m|$v]]",
|
|
|
|
|
$key,
|
|
|
|
|
$params,
|
|
|
|
|
$isDeprecated,
|
|
|
|
|
$isInternal
|
|
|
|
|
);
|
|
|
|
|
$submodules[] = $m->setContext( $this->getContext() );
|
|
|
|
|
$submoduleFlags[] = ( $isDeprecated ? 1 : 0 ) | ( $isInternal ? 2 : 0 );
|
|
|
|
|
$submoduleNames[] = $v;
|
2017-05-25 21:31:59 +00:00
|
|
|
}
|
2019-10-10 15:51:57 +00:00
|
|
|
// sort $submodules by $submoduleFlags and $submoduleNames
|
|
|
|
|
array_multisort( $submoduleFlags, $submoduleNames, $submodules );
|
|
|
|
|
$msgs[$param] = array_merge( $msgs[$param], $submodules );
|
2017-07-23 01:24:09 +00:00
|
|
|
} elseif ( isset( $settings[self::PARAM_HELP_MSG_PER_VALUE] ) ) {
|
|
|
|
|
if ( !is_array( $settings[self::PARAM_HELP_MSG_PER_VALUE] ) ) {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
2014-11-07 23:57:14 +00:00
|
|
|
'ApiBase::PARAM_HELP_MSG_PER_VALUE is not valid' );
|
|
|
|
|
}
|
2017-07-23 01:24:09 +00:00
|
|
|
if ( !is_array( $settings[self::PARAM_TYPE] ) ) {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
2014-11-07 23:57:14 +00:00
|
|
|
'ApiBase::PARAM_HELP_MSG_PER_VALUE may only be used when ' .
|
|
|
|
|
'ApiBase::PARAM_TYPE is an array' );
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
$valueMsgs = $settings[self::PARAM_HELP_MSG_PER_VALUE];
|
2017-10-06 22:17:58 +00:00
|
|
|
$deprecatedValues = $settings[self::PARAM_DEPRECATED_VALUES] ?? [];
|
2017-05-25 20:07:25 +00:00
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
foreach ( $settings[self::PARAM_TYPE] as $value ) {
|
2014-11-07 23:57:14 +00:00
|
|
|
if ( isset( $valueMsgs[$value] ) ) {
|
|
|
|
|
$msg = $valueMsgs[$value];
|
|
|
|
|
} else {
|
|
|
|
|
$msg = "apihelp-{$path}-paramvalue-{$param}-{$value}";
|
|
|
|
|
}
|
2017-07-23 01:24:09 +00:00
|
|
|
$m = self::makeMessage( $msg, $this->getContext(),
|
2016-02-17 09:09:32 +00:00
|
|
|
[ $prefix, $param, $name, $path, $value ] );
|
2014-11-07 23:57:14 +00:00
|
|
|
if ( $m ) {
|
|
|
|
|
$m = new ApiHelpParamValueMessage(
|
|
|
|
|
$value,
|
2019-06-18 20:26:00 +00:00
|
|
|
// @phan-suppress-next-line PhanTypeMismatchArgument
|
2016-02-17 09:09:32 +00:00
|
|
|
[ $m->getKey(), 'api-help-param-no-description' ],
|
2017-05-25 20:07:25 +00:00
|
|
|
$m->getParams(),
|
|
|
|
|
isset( $deprecatedValues[$value] )
|
2014-11-07 23:57:14 +00:00
|
|
|
);
|
|
|
|
|
$msgs[$param][] = $m->setContext( $this->getContext() );
|
|
|
|
|
} else {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
2014-11-07 23:57:14 +00:00
|
|
|
"Value in ApiBase::PARAM_HELP_MSG_PER_VALUE for $value is not valid" );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-23 01:24:09 +00:00
|
|
|
if ( isset( $settings[self::PARAM_HELP_MSG_APPEND] ) ) {
|
|
|
|
|
if ( !is_array( $settings[self::PARAM_HELP_MSG_APPEND] ) ) {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
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
|
|
|
'Value for ApiBase::PARAM_HELP_MSG_APPEND is not an array' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
2017-07-23 01:24:09 +00:00
|
|
|
foreach ( $settings[self::PARAM_HELP_MSG_APPEND] as $m ) {
|
|
|
|
|
$m = self::makeMessage( $m, $this->getContext(),
|
2016-02-17 09:09:32 +00:00
|
|
|
[ $prefix, $param, $name, $path ] );
|
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
|
|
|
if ( $m ) {
|
|
|
|
|
$msgs[$param][] = $m;
|
2014-08-27 19:41:05 +00:00
|
|
|
} else {
|
2016-03-08 07:28:54 +00:00
|
|
|
self::dieDebug( __METHOD__,
|
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
|
|
|
'Value in ApiBase::PARAM_HELP_MSG_APPEND is not valid' );
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
Hooks::run( 'APIGetParamDescriptionMessages', [ $this, &$msgs ] );
|
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
|
|
|
|
|
|
|
|
return $msgs;
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
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
|
|
|
* Generates the list of flags for the help screen and for action=paraminfo
|
|
|
|
|
*
|
|
|
|
|
* Corresponding messages: api-help-flag-deprecated,
|
|
|
|
|
* api-help-flag-internal, api-help-flag-readrights,
|
|
|
|
|
* api-help-flag-writerights, api-help-flag-mustbeposted
|
|
|
|
|
*
|
|
|
|
|
* @return string[]
|
2014-08-27 19:41:05 +00:00
|
|
|
*/
|
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
|
|
|
protected function getHelpFlags() {
|
2016-02-17 09:09:32 +00:00
|
|
|
$flags = [];
|
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
|
|
|
|
|
|
|
|
if ( $this->isDeprecated() ) {
|
|
|
|
|
$flags[] = 'deprecated';
|
2014-08-27 19:41:05 +00:00
|
|
|
}
|
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
|
|
|
if ( $this->isInternal() ) {
|
|
|
|
|
$flags[] = 'internal';
|
2011-05-07 13:05:22 +00:00
|
|
|
}
|
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
|
|
|
if ( $this->isReadMode() ) {
|
|
|
|
|
$flags[] = 'readrights';
|
|
|
|
|
}
|
|
|
|
|
if ( $this->isWriteMode() ) {
|
|
|
|
|
$flags[] = 'writerights';
|
|
|
|
|
}
|
|
|
|
|
if ( $this->mustBePosted() ) {
|
|
|
|
|
$flags[] = 'mustbeposted';
|
2010-02-20 19:39:51 +00:00
|
|
|
}
|
2011-06-17 16:03:52 +00:00
|
|
|
|
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
|
|
|
return $flags;
|
2008-01-15 20:21:16 +00:00
|
|
|
}
|
2006-10-01 04:38:31 +00:00
|
|
|
|
2015-03-27 21:10:31 +00:00
|
|
|
/**
|
|
|
|
|
* Returns information about the source of this module, if known
|
|
|
|
|
*
|
|
|
|
|
* Returned array is an array with the following keys:
|
|
|
|
|
* - path: Install path
|
|
|
|
|
* - name: Extension name, or "MediaWiki" for core
|
|
|
|
|
* - namemsg: (optional) i18n message key for a display name
|
|
|
|
|
* - license-name: (optional) Name of license
|
|
|
|
|
*
|
|
|
|
|
* @return array|null
|
|
|
|
|
*/
|
|
|
|
|
protected function getModuleSourceInfo() {
|
|
|
|
|
global $IP;
|
|
|
|
|
|
|
|
|
|
if ( $this->mModuleSource !== false ) {
|
|
|
|
|
return $this->mModuleSource;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// First, try to find where the module comes from...
|
|
|
|
|
$rClass = new ReflectionClass( $this );
|
|
|
|
|
$path = $rClass->getFileName();
|
|
|
|
|
if ( !$path ) {
|
|
|
|
|
// No path known?
|
|
|
|
|
$this->mModuleSource = null;
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
$path = realpath( $path ) ?: $path;
|
|
|
|
|
|
|
|
|
|
// Build map of extension directories to extension info
|
|
|
|
|
if ( self::$extensionInfo === null ) {
|
2015-12-13 03:45:43 +00:00
|
|
|
$extDir = $this->getConfig()->get( 'ExtensionDirectory' );
|
2016-02-17 09:09:32 +00:00
|
|
|
self::$extensionInfo = [
|
|
|
|
|
realpath( __DIR__ ) ?: __DIR__ => [
|
2015-03-27 21:10:31 +00:00
|
|
|
'path' => $IP,
|
|
|
|
|
'name' => 'MediaWiki',
|
2018-03-06 01:14:07 +00:00
|
|
|
'license-name' => 'GPL-2.0-or-later',
|
2016-02-17 09:09:32 +00:00
|
|
|
],
|
2015-03-27 21:10:31 +00:00
|
|
|
realpath( "$IP/extensions" ) ?: "$IP/extensions" => null,
|
2015-12-13 03:45:43 +00:00
|
|
|
realpath( $extDir ) ?: $extDir => null,
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
|
|
|
|
$keep = [
|
2015-03-27 21:10:31 +00:00
|
|
|
'path' => null,
|
|
|
|
|
'name' => null,
|
|
|
|
|
'namemsg' => null,
|
|
|
|
|
'license-name' => null,
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-03-27 21:10:31 +00:00
|
|
|
foreach ( $this->getConfig()->get( 'ExtensionCredits' ) as $group ) {
|
|
|
|
|
foreach ( $group as $ext ) {
|
|
|
|
|
if ( !isset( $ext['path'] ) || !isset( $ext['name'] ) ) {
|
|
|
|
|
// This shouldn't happen, but does anyway.
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$extpath = $ext['path'];
|
|
|
|
|
if ( !is_dir( $extpath ) ) {
|
|
|
|
|
$extpath = dirname( $extpath );
|
|
|
|
|
}
|
|
|
|
|
self::$extensionInfo[realpath( $extpath ) ?: $extpath] =
|
|
|
|
|
array_intersect_key( $ext, $keep );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
foreach ( ExtensionRegistry::getInstance()->getAllThings() as $ext ) {
|
|
|
|
|
$extpath = $ext['path'];
|
|
|
|
|
if ( !is_dir( $extpath ) ) {
|
|
|
|
|
$extpath = dirname( $extpath );
|
|
|
|
|
}
|
|
|
|
|
self::$extensionInfo[realpath( $extpath ) ?: $extpath] =
|
|
|
|
|
array_intersect_key( $ext, $keep );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Now traverse parent directories until we find a match or run out of
|
|
|
|
|
// parents.
|
|
|
|
|
do {
|
|
|
|
|
if ( array_key_exists( $path, self::$extensionInfo ) ) {
|
|
|
|
|
// Found it!
|
|
|
|
|
$this->mModuleSource = self::$extensionInfo[$path];
|
|
|
|
|
return $this->mModuleSource;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$oldpath = $path;
|
|
|
|
|
$path = dirname( $path );
|
|
|
|
|
} while ( $path !== $oldpath );
|
|
|
|
|
|
|
|
|
|
// No idea what extension this might be.
|
|
|
|
|
$this->mModuleSource = null;
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
2006-10-01 04:38:31 +00:00
|
|
|
/**
|
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
|
|
|
* Called from ApiHelp before the pieces are joined together and returned.
|
|
|
|
|
*
|
|
|
|
|
* This exists mainly for ApiMain to add the Permissions and Credits
|
|
|
|
|
* sections. Other modules probably don't need it.
|
|
|
|
|
*
|
|
|
|
|
* @param string[] &$help Array of help data
|
|
|
|
|
* @param array $options Options passed to ApiHelp::getHelp
|
2015-05-06 17:37:41 +00:00
|
|
|
* @param array &$tocData If a TOC is being generated, this array has keys
|
|
|
|
|
* as anchors in the page and values as for Linker::generateTOC().
|
2006-10-01 04:38:31 +00:00
|
|
|
*/
|
2015-05-06 17:37:41 +00:00
|
|
|
public function modifyHelp( array &$help, array $options, array &$tocData ) {
|
2010-02-14 22:20:27 +00:00
|
|
|
}
|
2007-12-02 15:04:53 +00:00
|
|
|
|
2019-08-05 17:00:00 +00:00
|
|
|
/** @} */
|
2019-08-21 19:53:53 +00:00
|
|
|
|
|
|
|
|
/************************************************************************//**
|
|
|
|
|
* @name Deprecated methods
|
|
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Split a multi-valued parameter string, like explode()
|
|
|
|
|
* @since 1.28
|
|
|
|
|
* @deprecated since 1.35, use ParamValidator::explodeMultiValue() instead
|
|
|
|
|
* @param string $value
|
|
|
|
|
* @param int $limit
|
|
|
|
|
* @return string[]
|
|
|
|
|
*/
|
|
|
|
|
protected function explodeMultiValue( $value, $limit ) {
|
|
|
|
|
wfDeprecated( __METHOD__, '1.35' );
|
|
|
|
|
return ParamValidator::explodeMultiValue( $value, $limit );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Return an array of values that were given in a 'a|b|c' notation,
|
|
|
|
|
* after it optionally validates them against the list allowed values.
|
|
|
|
|
*
|
|
|
|
|
* @deprecated since 1.35, no replacement
|
|
|
|
|
* @param string $valueName The name of the parameter (for error
|
|
|
|
|
* reporting)
|
|
|
|
|
* @param mixed $value The value being parsed
|
|
|
|
|
* @param bool $allowMultiple Can $value contain more than one value
|
|
|
|
|
* separated by '|'?
|
|
|
|
|
* @param string[]|null $allowedValues An array of values to check against. If
|
|
|
|
|
* null, all values are accepted.
|
|
|
|
|
* @param string|null $allSpecifier String to use to specify all allowed values, or null
|
|
|
|
|
* if this behavior should not be allowed
|
|
|
|
|
* @param int|null $limit1 Maximum number of values, for normal users.
|
|
|
|
|
* @param int|null $limit2 Maximum number of values, for users with the apihighlimits right.
|
|
|
|
|
* @return string|string[] (allowMultiple ? an_array_of_values : a_single_value)
|
|
|
|
|
*/
|
|
|
|
|
protected function parseMultiValue( $valueName, $value, $allowMultiple, $allowedValues,
|
|
|
|
|
$allSpecifier = null, $limit1 = null, $limit2 = null
|
|
|
|
|
) {
|
|
|
|
|
wfDeprecated( __METHOD__, '1.35' );
|
|
|
|
|
|
|
|
|
|
if ( ( $value === '' || $value === "\x1f" ) && $allowMultiple ) {
|
|
|
|
|
return [];
|
|
|
|
|
}
|
|
|
|
|
$limit1 = $limit1 ?: self::LIMIT_SML1;
|
|
|
|
|
$limit2 = $limit2 ?: self::LIMIT_SML2;
|
|
|
|
|
|
|
|
|
|
// This is a bit awkward, but we want to avoid calling canApiHighLimits()
|
|
|
|
|
// because it unstubs $wgUser
|
|
|
|
|
$valuesList = $this->explodeMultiValue( $value, $limit2 + 1 );
|
|
|
|
|
$sizeLimit = count( $valuesList ) > $limit1 && $this->mMainModule->canApiHighLimits()
|
|
|
|
|
? $limit2
|
|
|
|
|
: $limit1;
|
|
|
|
|
|
|
|
|
|
if ( $allowMultiple && is_array( $allowedValues ) && $allSpecifier &&
|
|
|
|
|
count( $valuesList ) === 1 && $valuesList[0] === $allSpecifier
|
|
|
|
|
) {
|
|
|
|
|
return $allowedValues;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( count( $valuesList ) > $sizeLimit ) {
|
|
|
|
|
$this->dieWithError(
|
|
|
|
|
[ 'apierror-toomanyvalues', $valueName, $sizeLimit ],
|
|
|
|
|
"too-many-$valueName"
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( !$allowMultiple && count( $valuesList ) != 1 ) {
|
|
|
|
|
// T35482 - Allow entries with | in them for non-multiple values
|
|
|
|
|
if ( in_array( $value, $allowedValues, true ) ) {
|
|
|
|
|
return $value;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$values = array_map( function ( $v ) {
|
|
|
|
|
return '<kbd>' . wfEscapeWikiText( $v ) . '</kbd>';
|
|
|
|
|
}, $allowedValues );
|
|
|
|
|
$this->dieWithError( [
|
|
|
|
|
'apierror-multival-only-one-of',
|
|
|
|
|
$valueName,
|
|
|
|
|
Message::listParam( $values ),
|
|
|
|
|
count( $values ),
|
|
|
|
|
], "multival_$valueName" );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( is_array( $allowedValues ) ) {
|
|
|
|
|
// Check for unknown values
|
|
|
|
|
$unknown = array_map( 'wfEscapeWikiText', array_diff( $valuesList, $allowedValues ) );
|
|
|
|
|
if ( count( $unknown ) ) {
|
|
|
|
|
if ( $allowMultiple ) {
|
|
|
|
|
$this->addWarning( [
|
|
|
|
|
'apiwarn-unrecognizedvalues',
|
|
|
|
|
$valueName,
|
|
|
|
|
Message::listParam( $unknown, 'comma' ),
|
|
|
|
|
count( $unknown ),
|
|
|
|
|
] );
|
|
|
|
|
} else {
|
|
|
|
|
$this->dieWithError(
|
|
|
|
|
[ 'apierror-unrecognizedvalue', $valueName, wfEscapeWikiText( $valuesList[0] ) ],
|
|
|
|
|
"unknown_$valueName"
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// Now throw them out
|
|
|
|
|
$valuesList = array_intersect( $valuesList, $allowedValues );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $allowMultiple ? $valuesList : $valuesList[0];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Validate the value against the minimum and user/bot maximum limits.
|
|
|
|
|
* Prints usage info on failure.
|
|
|
|
|
* @deprecated since 1.35, use $this->getMain()->getParamValidator()->validateValue() instead.
|
|
|
|
|
* @param string $name Parameter name, unprefixed
|
|
|
|
|
* @param int &$value Parameter value
|
|
|
|
|
* @param int|null $min Minimum value
|
|
|
|
|
* @param int|null $max Maximum value for users
|
|
|
|
|
* @param int|null $botMax Maximum value for sysops/bots
|
|
|
|
|
* @param bool $enforceLimits Whether to enforce (die) if value is outside limits
|
|
|
|
|
*/
|
|
|
|
|
protected function validateLimit( $name, &$value, $min, $max, $botMax = null,
|
|
|
|
|
$enforceLimits = false
|
|
|
|
|
) {
|
|
|
|
|
wfDeprecated( __METHOD__, '1.35' );
|
|
|
|
|
$value = $this->getMain()->getParamValidator()->validateValue(
|
|
|
|
|
$this, $name, $value, [
|
|
|
|
|
ParamValidator::PARAM_TYPE => 'limit',
|
|
|
|
|
IntegerDef::PARAM_MIN => $min,
|
|
|
|
|
IntegerDef::PARAM_MAX => $max,
|
|
|
|
|
IntegerDef::PARAM_MAX2 => $botMax,
|
|
|
|
|
IntegerDef::PARAM_IGNORE_RANGE => !$enforceLimits,
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Validate and normalize parameters of type 'timestamp'
|
|
|
|
|
* @deprecated since 1.35, use $this->getMain()->getParamValidator()->validateValue() instead.
|
|
|
|
|
* @param string $value Parameter value
|
|
|
|
|
* @param string $encParamName Parameter name
|
|
|
|
|
* @return string Validated and normalized parameter
|
|
|
|
|
*/
|
|
|
|
|
protected function validateTimestamp( $value, $encParamName ) {
|
|
|
|
|
wfDeprecated( __METHOD__, '1.35' );
|
|
|
|
|
|
|
|
|
|
// Sigh.
|
|
|
|
|
$name = $encParamName;
|
|
|
|
|
$p = (string)$this->getModulePrefix();
|
|
|
|
|
$l = strlen( $p );
|
|
|
|
|
if ( $l && substr( $name, 0, $l ) === $p ) {
|
|
|
|
|
$name = substr( $name, $l );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $this->getMain()->getParamValidator()->validateValue(
|
|
|
|
|
$this, $name, $value, [
|
|
|
|
|
ParamValidator::PARAM_TYPE => 'timestamp',
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
|
2009-02-28 13:25:21 +00:00
|
|
|
}
|
2014-08-27 19:41:05 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* For really cool vim folding this needs to be at the end:
|
|
|
|
|
* vim: foldmarker=@{,@} foldmethod=marker
|
|
|
|
|
*/
|