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

1498 lines
43 KiB
PHP
Raw Normal View History

<?php
/**
*
*
* Created on Sep 4, 2006
*
* Copyright © 2006 Yuri Astrakhan "<Firstname><Lastname>@gmail.com"
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
* @defgroup API API
*/
/**
* This is the main API class, used for both external and internal processing.
* When executed, it will create the requested formatter object,
* instantiate and execute an object associated with the needed action,
* and use formatter to print results.
* In case of an exception, an error message will be printed using the same formatter.
*
* To use API from another application, run it using FauxRequest object, in which
* case any internal exceptions will not be handled but passed up to the caller.
* After successful execution, use getResult() for the resulting data.
*
* @ingroup API
*/
class ApiMain extends ApiBase {
/**
* When no format parameter is given, this format will be used
*/
const API_DEFAULT_FORMAT = 'jsonfm';
/**
* List of available modules: action name => module class
*/
private static $Modules = array(
'login' => 'ApiLogin',
2008-01-08 18:10:58 +00:00
'logout' => 'ApiLogout',
'createaccount' => 'ApiCreateAccount',
'query' => 'ApiQuery',
'expandtemplates' => 'ApiExpandTemplates',
'parse' => 'ApiParse',
'stashedit' => 'ApiStashEdit',
'opensearch' => 'ApiOpenSearch',
'feedcontributions' => 'ApiFeedContributions',
'feedrecentchanges' => 'ApiFeedRecentChanges',
'feedwatchlist' => 'ApiFeedWatchlist',
'help' => 'ApiHelp',
'paraminfo' => 'ApiParamInfo',
'rsd' => 'ApiRsd',
'compare' => 'ApiComparePages',
'tokens' => 'ApiTokens',
// Write modules
'purge' => 'ApiPurge',
'setnotificationtimestamp' => 'ApiSetNotificationTimestamp',
'rollback' => 'ApiRollback',
'delete' => 'ApiDelete',
'undelete' => 'ApiUndelete',
'protect' => 'ApiProtect',
'block' => 'ApiBlock',
'unblock' => 'ApiUnblock',
'move' => 'ApiMove',
2008-03-03 18:08:40 +00:00
'edit' => 'ApiEditPage',
here it is ... the upload-api, script-server, js2 (javascript phase2) branch merge 1st attempt. Here is a short overview of changes and associated default configuration variables (most everything is off by default) also see ~soon to be updated~: http://www.mediawiki.org/wiki/Media_Projects_Overview = Upload Improvements = ==Upload API == * Based on the early work of Bryan Tong and others it adds the upload option to the api. * We rewrite Special:Upload page to include use the new refactoring * Added in token checks in both the SpecialUpload.php page so avoids DOS / xss copy-by-url JavaScript based cross site POST file submissions == Copy by URL== $wgAllowCopyUploads = false; * http class rewrite includes a new http background download see: includes/HttpFunctions.php * spins off a php process that calls: maintenance/http_session_download.php * pushes updates to the session and gives the user a progress bar on http copy uploads from other server progress (using js2 upload interface) (if not using the js2 upload interface it does the request in-place but the download is limited to the php ini timeout time) == Firefogg == * Firefogg enables resumable upload by chunks * progress indicators and conditional invokation (js2 system) * and of-course client side transcoding. = Script Server = $wgEnableScriptLoader = false; * off by default if $wgEnableScriptLoader is turned on script files are grouped, gziped, cached etc. for more info see: http://www.mediawiki.org/wiki/Extension:ScriptLoader * Includes some early skin js include fixes (skin/script system still lots of love) * Includes a "javascript class autoloader" this is packaged into mwEmbed so that the mwEmbed library can work in stand alone mode (while retaining localization and script serving) (one such application is the make page for firefogg.org : http://www.firefogg.org/make/index.html ) * The file that contains the autojavascript loading classes is: js2/php/jsAutoloadLocalClasses.php * One can use this auto class loading dependency system with extensions and add-ons but I need to better document that. = js2 system / mwEmbed= $wgEnableJS2system = false * includes initial rewrite towards more jquery based javascript code * especially for the Special:Upload page. * Also the edit page include support for the "add-media-wizard" * includes dependency loader for javascript that optionally takes advantage of the script-loader * remote embedding of javascript interfaces (like embedding video, or commons media searching) * $wgDebugJavaScript = false; .. .this variable lets you always get "always fresh javascript". When used with the script-loader it does not minify the script-loader output. = mwEmbed = * Will commit a separate patch to oggHandler that conditionally outputs <video tag> to use the new javascript video player. ** mv_embed player includes: play-head, volume control, remote embedding, oggz-chop support across plugins. * add-media-wizard adds easy inserts of media to pages (with import) == jQuery== * we include a base install of jQuery, jQuery ui and some plugins. * all the javascript classes are in the scriptloader so its easy to load any set of jquery ui components that you may need using the script-server. You get a callback so you can then execute js with dependencies loaded. == other stuff == there is a bit more code in js2 that pertains to sequence editing, timed text display and basic image editing. We include a base import of pixastic-lib & pixastic-editor... will work with the pixastic developer to try and ensure upstream compatibility on our usage of the library for in-browser photo and sequence manipulation.
2009-07-14 23:52:14 +00:00
'upload' => 'ApiUpload',
'filerevert' => 'ApiFileRevert',
2008-06-01 17:58:27 +00:00
'emailuser' => 'ApiEmailUser',
2008-08-21 15:44:13 +00:00
'watch' => 'ApiWatch',
'patrol' => 'ApiPatrol',
'import' => 'ApiImport',
'clearhasmsg' => 'ApiClearHasMsg',
'userrights' => 'ApiUserrights',
'options' => 'ApiOptions',
'imagerotate' => 'ApiImageRotate',
'revisiondelete' => 'ApiRevisionDelete',
);
/**
* List of available formats: format name => format class
*/
private static $Formats = array(
'json' => 'ApiFormatJson',
'jsonfm' => 'ApiFormatJson',
'php' => 'ApiFormatPhp',
'phpfm' => 'ApiFormatPhp',
'wddx' => 'ApiFormatWddx',
'wddxfm' => 'ApiFormatWddx',
'xml' => 'ApiFormatXml',
'xmlfm' => 'ApiFormatXml',
'yaml' => 'ApiFormatYaml',
'yamlfm' => 'ApiFormatYaml',
'rawfm' => 'ApiFormatJson',
'txt' => 'ApiFormatTxt',
'txtfm' => 'ApiFormatTxt',
'dbg' => 'ApiFormatDbg',
'dbgfm' => 'ApiFormatDbg',
'dump' => 'ApiFormatDump',
'dumpfm' => 'ApiFormatDump',
'none' => 'ApiFormatNone',
);
2010-01-22 03:14:52 +00:00
// @codingStandardsIgnoreStart String contenation on "msg" not allowed to break long line
/**
* List of user roles that are specifically relevant to the API.
* array( 'right' => array ( 'msg' => 'Some message with a $1',
* 'params' => array ( $someVarToSubst ) ),
* );
*/
private static $mRights = array(
'writeapi' => array(
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
'msg' => 'right-writeapi',
'params' => array()
),
'apihighlimits' => array(
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
'msg' => 'api-help-right-apihighlimits',
'params' => array( ApiBase::LIMIT_SML2, ApiBase::LIMIT_BIG2 )
)
);
// @codingStandardsIgnoreEnd
/**
* @var ApiFormatBase
*/
private $mPrinter;
private $mModuleMgr, $mResult;
private $mAction;
private $mEnableWrite;
private $mInternalMode, $mSquidMaxage, $mModule;
private $mCacheMode = 'private';
private $mCacheControl = array();
private $mParamsUsed = array();
/**
* Constructs an instance of ApiMain that utilizes the module and format specified by $request.
*
* @param IContextSource|WebRequest $context If this is an instance of
* FauxRequest, errors are thrown and no printing occurs
* @param bool $enableWrite Should be set to true if the api may modify data
*/
public function __construct( $context = null, $enableWrite = false ) {
if ( $context === null ) {
$context = RequestContext::getMain();
} elseif ( $context instanceof WebRequest ) {
// BC for pre-1.19
$request = $context;
$context = RequestContext::getMain();
}
// We set a derivative context so we can change stuff later
$this->setContext( new DerivativeContext( $context ) );
if ( isset( $request ) ) {
$this->getContext()->setRequest( $request );
}
$this->mInternalMode = ( $this->getRequest() instanceof FauxRequest );
// Special handling for the main module: $parent === $this
parent::__construct( $this, $this->mInternalMode ? 'main_int' : 'main' );
if ( !$this->mInternalMode ) {
// Impose module restrictions.
// If the current user cannot read,
// Remove all modules other than login
global $wgUser;
if ( $this->getVal( 'callback' ) !== null ) {
// JSON callback allows cross-site reads.
// For safety, strip user credentials.
wfDebug( "API: stripping user credentials for JSON callback\n" );
$wgUser = new User();
$this->getContext()->setUser( $wgUser );
}
}
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
$uselang = $this->getParameter( 'uselang' );
if ( $uselang === 'user' ) {
$uselang = $this->getUser()->getOption( 'language' );
$uselang = RequestContext::sanitizeLangCode( $uselang );
Hooks::run( 'UserGetLanguageObject', array( $this->getUser(), &$uselang, $this ) );
} elseif ( $uselang === 'content' ) {
global $wgContLang;
$uselang = $wgContLang->getCode();
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
}
$code = RequestContext::sanitizeLangCode( $uselang );
$this->getContext()->setLanguage( $code );
if ( !$this->mInternalMode ) {
global $wgLang;
$wgLang = $this->getContext()->getLanguage();
RequestContext::getMain()->setLanguage( $wgLang );
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
}
$config = $this->getConfig();
$this->mModuleMgr = new ApiModuleManager( $this );
$this->mModuleMgr->addModules( self::$Modules, 'action' );
$this->mModuleMgr->addModules( $config->get( 'APIModules' ), 'action' );
$this->mModuleMgr->addModules( self::$Formats, 'format' );
$this->mModuleMgr->addModules( $config->get( 'APIFormatModules' ), 'format' );
$this->mResult = new ApiResult( $this );
$this->mEnableWrite = $enableWrite;
$this->mSquidMaxage = -1; // flag for executeActionWithErrorHandling()
$this->mCommit = false;
}
/**
* Return true if the API was started by other PHP code using FauxRequest
2011-01-30 08:16:13 +00:00
* @return bool
*/
public function isInternalMode() {
return $this->mInternalMode;
}
/**
2010-01-22 03:14:52 +00:00
* Get the ApiResult object associated with current request
2010-09-29 18:18:07 +00:00
*
* @return ApiResult
*/
Prevent the following strict-standards warnings - i.e. when running with error_logging(E_ALL | E_STRICT); - which seems to disable the yucky "@" operator, as well as maxing out the pedantry of warnings. Nothing major found, just nice to be as explicit and as forward-compatible as possible. * Strict Standards: Undefined index: switch in includes/Parser.php on line 3849 * Strict Standards: Undefined index: ref in includes/Parser.php on line 3818 * Strict Standards: Non-static method OutputPage::setEncodings() should not be called statically in index.php on line 11 * Strict Standards: Only variables should be assigned by reference in includes/Skin.php on line 888 * Strict Standards: Non-static method Title::newFromURL() should not be called statically in includes/SpecialContributions.php on line 178 * Strict Standards: Only variables should be assigned by reference in includes/GlobalFunctions.php on line 2054 * Strict Standards: Undefined index: contributions-summary in languages/Language.php on line 764 * Strict Standards: Undefined index: trackbackhtml in skins/MonoBook.php on line 86 * Strict Standards: Undefined index: blockip in skins/MonoBook.php on line 204 * Strict Standards: Undefined index: tagline in skins/MonoBook.php on line 261 * Strict Standards: Undefined index: uselang in includes/SkinTemplate.php on line 1159 * Strict Standards: Non-static method CoreParserFunctions::plural() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Undefined offset: 0 in includes/SkinTemplate.php on line 196 * Strict Standards: Undefined index: USE INDEX in includes/Database.php on line 1015 * Strict Standards: Undefined index: image_tests in includes/Parser.php on line 3488 * Strict Standards: Undefined offset: 0 in includes/Parser.php on line 3507 * Strict Standards: Non-static method ChangesList::newFromUser() should not be called statically in includes/SpecialWatchlist.php on line 361 * Strict Standards: Non-static method RecentChange::newFromCurRow() should not be called statically in includes/SpecialWatchlist.php on line 367 * Strict Standards: is_a(): Deprecated. Please use the instanceof operator in includes/Exception.php on line 168 * Strict Standards: Non-static method LogPage::logName() should not be called statically in includes/SpecialContributions.php on line 325 * Strict Standards: ob_end_flush(): failed to delete and flush buffer. No buffer to delete or flush. in maintenance/commandLine.inc on line 191 * Strict Standards: Undefined index: meatball in languages/Language.php on line 234 * Strict Standards: rmdir(/tmp/mwParser-2108164586-images/thumb): Directory not empty in maintenance/parserTests.inc on line 605 * Cleaning out some new temp files left over by parserTests (there were one or two straggler dirs/files that would persist after the test run ended, due to new tests being added over time) * Strict Standards: Non-static method CoreParserFunctions::special() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Declaration of ListUsersPage::preprocessResults() should be compatible with that of QueryPage::preprocessResults() in includes/SpecialListusers.php on line 38 * Strict Standards: Only variables should be passed by reference in includes/SpecialBlockip.php on line 175 * Strict Standards: Skin::include_once(skins/Standard.deps.php) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory in includes/Skin.php on line 121 * Strict Standards: Declaration of ApiMain::getResult() should be compatible with that of ApiBase::getResult() in includes/api/ApiMain.php on line 35 * Strict Standards: is_a(): Deprecated. Please use the instanceof operator in includes/WikiError.php on line 63 * Strict Standards: Non-static method WikiError::isError() should not be called statically in includes/SpecialImport.php on line 64 * Strict Standards: Non-static method ImportStreamSource::newFromInterwiki() should not be called statically in includes/SpecialImport.php on line 58<b * Strict Standards: Only variables should be assigned by reference in includes/SpecialUndelete.php on line 501 * Strict Standards: Non-static method Image::newFromName() should not be called statically in thumb.php on line 56 * Strict Standards: Non-static method CoreParserFunctions::numberoffiles() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Non-static method CoreParserFunctions::statisticsFunction() should not be called statically in includes/CoreParserFunctions.php on line 139 * Strict Standards: Non-static method CoreParserFunctions::isRaw() should not be called statically in includes/CoreParserFunctions.php on line 128 * Strict Standards: Non-static method CoreParserFunctions::grammar() cannot be called statically in includes/Parser.php on line 2902 * Strict Standards: Undefined offset: 1 in includes/SpecialMIMEsearch.php on line 130 * Strict Standards: Undefined index: recentchangeslinked in skins/MonoBook.php on line 184 * Strict Standards: Declaration of DumpNotalkFilter::pass() should be compatible with that of DumpFilter::pass() in includes/Export.php on line 612 * Strict Standards: Declaration of DumpNamespaceFilter::pass() should be compatible with that of DumpFilter::pass() in includes/Export.php on line 665 * Strict Standards: Non-static method ImportStreamSource::newFromUpload() should not be called statically in includes/SpecialImport.php on line 46 * Strict Standards: Undefined offset: 5 in includes/Sanitizer.php on line 396 * Strict Standards: Undefined index: wikidbUserName in includes/SpecialUserlogin.php on line 562 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryBase.php on line 95 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryBase.php on line 116 * Strict Standards: Only variables should be assigned by reference in includes/api/ApiQueryWatchlist.php on line 128 * Strict Standards: Undefined property: stdClass::$rc_id in includes/api/ApiQueryBase.php on line 131 * Strict Standards: Undefined property: stdClass::$rc_last_oldid in includes/api/ApiQueryBase.php on line 164 * Strict Standards: Undefined property: stdClass::$rc_moved_to_ns in includes/api/ApiQueryBase.php on line 285 * Strict Standards: Undefined property: stdClass::$rc_patrolled in includes/api/ApiQueryBase.php on line 176 * Strict Standards: Undefined index: comment in includes/api/ApiFeedWatchlist.php on line 85 * Strict Standards: Undefined offset: 0 in includes/Skin.php on line 302 * Strict Standards: Non-static method User::SetupSession() should not be called statically in includes/SpecialUserlogin.php on line 15 ... There are certain to be other things too, so this is not intended to be comprehensive, rather the above just stops most of the notifications I observed.
2006-11-29 05:45:03 +00:00
public function getResult() {
return $this->mResult;
}
2010-01-22 03:14:52 +00:00
/**
* Get the API module object. Only works after executeAction()
2011-01-30 08:16:13 +00:00
*
* @return ApiBase
*/
public function getModule() {
return $this->mModule;
}
/**
* Get the result formatter object. Only works after setupExecuteAction()
2010-09-29 18:18:07 +00:00
*
* @return ApiFormatBase
*/
public function getPrinter() {
return $this->mPrinter;
}
/**
* Set how long the response should be cached.
*
* @param int $maxage
*/
public function setCacheMaxAge( $maxage ) {
$this->setCacheControl( array(
'max-age' => $maxage,
's-maxage' => $maxage
) );
}
/**
* Set the type of caching headers which will be sent.
*
* @param string $mode One of:
* - 'public': Cache this object in public caches, if the maxage or smaxage
* parameter is set, or if setCacheMaxAge() was called. If a maximum age is
* not provided by any of these means, the object will be private.
* - 'private': Cache this object only in private client-side caches.
* - 'anon-public-user-private': Make this object cacheable for logged-out
* users, but private for logged-in users. IMPORTANT: If this is set, it must be
* set consistently for a given URL, it cannot be set differently depending on
* things like the contents of the database, or whether the user is logged in.
*
* If the wiki does not allow anonymous users to read it, the mode set here
* will be ignored, and private caching headers will always be sent. In other words,
* the "public" mode is equivalent to saying that the data sent is as public as a page
* view.
*
* For user-dependent data, the private mode should generally be used. The
* anon-public-user-private mode should only be used where there is a particularly
* good performance reason for caching the anonymous response, but where the
* response to logged-in users may differ, or may contain private data.
*
* If this function is never called, then the default will be the private mode.
*/
public function setCacheMode( $mode ) {
if ( !in_array( $mode, array( 'private', 'public', 'anon-public-user-private' ) ) ) {
wfDebug( __METHOD__ . ": unrecognised cache mode \"$mode\"\n" );
// Ignore for forwards-compatibility
return;
}
if ( !User::isEveryoneAllowed( 'read' ) ) {
// Private wiki, only private headers
if ( $mode !== 'private' ) {
wfDebug( __METHOD__ . ": ignoring request for $mode cache mode, private wiki\n" );
return;
}
}
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 ( $mode === 'public' && $this->getParameter( 'uselang' ) === 'user' ) {
// User language is used for i18n, so we don't want to publicly
// cache. Anons are ok, because if they have non-default language
// then there's an appropriate Vary header set by whatever set
// their non-default language.
wfDebug( __METHOD__ . ": downgrading cache mode 'public' to " .
"'anon-public-user-private' due to uselang=user\n" );
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
$mode = 'anon-public-user-private';
}
wfDebug( __METHOD__ . ": setting cache mode $mode\n" );
$this->mCacheMode = $mode;
}
/**
* Set directives (key/value pairs) for the Cache-Control header.
* Boolean values will be formatted as such, by including or omitting
* without an equals sign.
*
* Cache control values set here will only be used if the cache mode is not
* private, see setCacheMode().
*
* @param array $directives
*/
public function setCacheControl( $directives ) {
$this->mCacheControl = $directives + $this->mCacheControl;
}
/**
* Create an instance of an output formatter by its name
2011-01-30 08:16:13 +00:00
*
* @param string $format
*
2011-01-30 08:16:13 +00:00
* @return ApiFormatBase
*/
public function createPrinterByName( $format ) {
$printer = $this->mModuleMgr->getModule( $format, 'format' );
if ( $printer === null ) {
$this->dieUsage( "Unrecognized format: {$format}", 'unknown_format' );
}
return $printer;
}
/**
* Execute api request. Any errors will be handled if the API was called by the remote client.
*/
public function execute() {
$this->profileIn();
if ( $this->mInternalMode ) {
$this->executeAction();
} else {
$this->executeActionWithErrorHandling();
}
2010-01-22 03:14:52 +00:00
$this->profileOut();
}
/**
* Execute an action, and in case of an error, erase whatever partial results
* have been accumulated, and replace it with an error message and a help screen.
*/
protected function executeActionWithErrorHandling() {
// Verify the CORS header before executing the action
if ( !$this->handleCORS() ) {
// handleCORS() has sent a 403, abort
return;
}
// Exit here if the request method was OPTIONS
// (assume there will be a followup GET or POST)
if ( $this->getRequest()->getMethod() === 'OPTIONS' ) {
return;
}
// In case an error occurs during data output,
// clear the output buffer and print just the error information
ob_start();
$t = microtime( true );
try {
$this->executeAction();
} catch ( Exception $e ) {
$this->handleException( $e );
}
// Log the request whether or not there was an error
$this->logRequest( microtime( true ) - $t );
// Send cache headers after any code which might generate an error, to
// avoid sending public cache headers for errors.
$this->sendCacheHeaders();
ob_end_flush();
}
/**
* Handle an exception as an API response
*
* @since 1.23
* @param Exception $e
*/
protected function handleException( Exception $e ) {
// Bug 63145: Rollback any open database transactions
if ( !( $e instanceof UsageException ) ) {
// UsageExceptions are intentional, so don't rollback if that's the case
MWExceptionHandler::rollbackMasterChangesAndLog( $e );
}
// Allow extra cleanup and logging
Hooks::run( 'ApiMain::onException', array( $this, $e ) );
// Log it
if ( !( $e instanceof UsageException ) ) {
MWExceptionHandler::logException( $e );
}
// Handle any kind of exception by outputting properly formatted error message.
// If this fails, an unhandled exception should be thrown so that global error
// handler will process and log it.
$errCode = $this->substituteResultWithError( $e );
// Error results should not be cached
$this->setCacheMode( 'private' );
$response = $this->getRequest()->response();
$headerStr = 'MediaWiki-API-Error: ' . $errCode;
if ( $e->getCode() === 0 ) {
$response->header( $headerStr );
} else {
$response->header( $headerStr, true, $e->getCode() );
}
// Reset and print just the error message
ob_clean();
// If the error occurred during printing, do a printer->profileOut()
$this->mPrinter->safeProfileOut();
$this->printResult( true );
}
/**
* Handle an exception from the ApiBeforeMain hook.
*
* This tries to print the exception as an API response, to be more
* friendly to clients. If it fails, it will rethrow the exception.
*
* @since 1.23
* @param Exception $e
*/
public static function handleApiBeforeMainException( Exception $e ) {
ob_start();
try {
$main = new self( RequestContext::getMain(), false );
$main->handleException( $e );
} catch ( Exception $e2 ) {
// Nope, even that didn't work. Punt.
throw $e;
}
// Log the request and reset cache headers
$main->logRequest( 0 );
$main->sendCacheHeaders();
ob_end_flush();
}
/**
* Check the &origin= query parameter against the Origin: HTTP header and respond appropriately.
*
* If no origin parameter is present, nothing happens.
* If an origin parameter is present but doesn't match the Origin header, a 403 status code
* is set and false is returned.
* If the parameter and the header do match, the header is checked against $wgCrossSiteAJAXdomains
* and $wgCrossSiteAJAXdomainExceptions, and if the origin qualifies, the appropriate CORS
* headers are set.
*
* @return bool False if the caller should abort (403 case), true otherwise (all other cases)
*/
protected function handleCORS() {
$originParam = $this->getParameter( 'origin' ); // defaults to null
if ( $originParam === null ) {
// No origin parameter, nothing to do
return true;
}
$request = $this->getRequest();
$response = $request->response();
// Origin: header is a space-separated list of origins, check all of them
$originHeader = $request->getHeader( 'Origin' );
if ( $originHeader === false ) {
$origins = array();
} else {
$origins = explode( ' ', $originHeader );
}
if ( !in_array( $originParam, $origins ) ) {
// origin parameter set but incorrect
// Send a 403 response
$message = HttpStatus::getMessage( 403 );
$response->header( "HTTP/1.1 403 $message", true, 403 );
$response->header( 'Cache-Control: no-cache' );
echo "'origin' parameter does not match Origin header\n";
return false;
}
$config = $this->getConfig();
$matchOrigin = self::matchOrigin(
$originParam,
$config->get( 'CrossSiteAJAXdomains' ),
$config->get( 'CrossSiteAJAXdomainExceptions' )
);
if ( $matchOrigin ) {
$response->header( "Access-Control-Allow-Origin: $originParam" );
$response->header( 'Access-Control-Allow-Credentials: true' );
$response->header( 'Access-Control-Allow-Headers: Api-User-Agent' );
$this->getOutput()->addVaryHeader( 'Origin' );
}
return true;
}
/**
* Attempt to match an Origin header against a set of rules and a set of exceptions
* @param string $value Origin header
* @param array $rules Set of wildcard rules
* @param array $exceptions Set of wildcard rules
* @return bool True if $value matches a rule in $rules and doesn't match
* any rules in $exceptions, false otherwise
*/
protected static function matchOrigin( $value, $rules, $exceptions ) {
foreach ( $rules as $rule ) {
if ( preg_match( self::wildcardToRegex( $rule ), $value ) ) {
// Rule matches, check exceptions
foreach ( $exceptions as $exc ) {
if ( preg_match( self::wildcardToRegex( $exc ), $value ) ) {
return false;
}
}
return true;
}
}
return false;
}
/**
* Helper function to convert wildcard string into a regex
* '*' => '.*?'
* '?' => '.'
*
* @param string $wildcard String with wildcards
* @return string Regular expression
*/
protected static function wildcardToRegex( $wildcard ) {
$wildcard = preg_quote( $wildcard, '/' );
$wildcard = str_replace(
array( '\*', '\?' ),
array( '.*?', '.' ),
$wildcard
);
return "/^https?:\/\/$wildcard$/";
}
protected function sendCacheHeaders() {
$response = $this->getRequest()->response();
$out = $this->getOutput();
$config = $this->getConfig();
if ( $config->get( 'VaryOnXFP' ) ) {
$out->addVaryHeader( 'X-Forwarded-Proto' );
}
if ( $this->mCacheMode == 'private' ) {
$response->header( 'Cache-Control: private' );
return;
}
$useXVO = $config->get( 'UseXVO' );
if ( $this->mCacheMode == 'anon-public-user-private' ) {
$out->addVaryHeader( 'Cookie' );
$response->header( $out->getVaryHeader() );
if ( $useXVO ) {
$response->header( $out->getXVO() );
if ( $out->haveCacheVaryCookies() ) {
// Logged in, mark this request private
$response->header( 'Cache-Control: private' );
return;
}
// Logged out, send normal public headers below
} elseif ( session_id() != '' ) {
// Logged in or otherwise has session (e.g. anonymous users who have edited)
// Mark request private
$response->header( 'Cache-Control: private' );
return;
} // else no XVO and anonymous, send public headers below
}
// Send public headers
$response->header( $out->getVaryHeader() );
if ( $useXVO ) {
$response->header( $out->getXVO() );
}
// If nobody called setCacheMaxAge(), use the (s)maxage parameters
if ( !isset( $this->mCacheControl['s-maxage'] ) ) {
$this->mCacheControl['s-maxage'] = $this->getParameter( 'smaxage' );
}
if ( !isset( $this->mCacheControl['max-age'] ) ) {
$this->mCacheControl['max-age'] = $this->getParameter( 'maxage' );
2008-06-16 20:06:23 +00:00
}
if ( !$this->mCacheControl['s-maxage'] && !$this->mCacheControl['max-age'] ) {
// Public cache not requested
// Sending a Vary header in this case is harmless, and protects us
// against conditional calls of setCacheMaxAge().
$response->header( 'Cache-Control: private' );
return;
}
$this->mCacheControl['public'] = true;
// Send an Expires header
$maxAge = min( $this->mCacheControl['s-maxage'], $this->mCacheControl['max-age'] );
$expiryUnixTime = ( $maxAge == 0 ? 1 : time() + $maxAge );
$response->header( 'Expires: ' . wfTimestamp( TS_RFC2822, $expiryUnixTime ) );
// Construct the Cache-Control header
$ccHeader = '';
$separator = '';
foreach ( $this->mCacheControl as $name => $value ) {
if ( is_bool( $value ) ) {
if ( $value ) {
$ccHeader .= $separator . $name;
2010-02-15 21:34:31 +00:00
$separator = ', ';
}
} else {
$ccHeader .= $separator . "$name=$value";
2010-02-15 21:34:31 +00:00
$separator = ', ';
}
}
$response->header( "Cache-Control: $ccHeader" );
}
/**
* Replace the result data with the information about an exception.
* Returns the error code
* @param Exception $e
2011-01-30 08:16:13 +00:00
* @return string
*/
protected function substituteResultWithError( $e ) {
$result = $this->getResult();
// Printer may not be initialized if the extractRequestParams() fails for the main module
if ( !isset( $this->mPrinter ) ) {
// The printer has not been created yet. Try to manually get formatter value.
$value = $this->getRequest()->getVal( 'format', self::API_DEFAULT_FORMAT );
if ( !$this->mModuleMgr->isDefined( $value, 'format' ) ) {
$value = self::API_DEFAULT_FORMAT;
}
$this->mPrinter = $this->createPrinterByName( $value );
}
// Printer may not be able to handle errors. This is particularly
// likely if the module returns something for getCustomPrinter().
if ( !$this->mPrinter->canPrintErrors() ) {
$this->mPrinter->safeProfileOut();
$this->mPrinter = $this->createPrinterByName( self::API_DEFAULT_FORMAT );
}
// Update raw mode flag for the selected printer.
$result->setRawMode( $this->mPrinter->getNeedsRawData() );
$config = $this->getConfig();
if ( $e instanceof UsageException ) {
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
// User entered incorrect parameters - generate error response
$errMessage = $e->getMessageArray();
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
$link = wfExpandUrl( wfScript( 'api' ) );
ApiResult::setContent( $errMessage, "See $link for API usage" );
} else {
// Something is seriously wrong
if ( ( $e instanceof DBQueryError ) && !$config->get( 'ShowSQLErrors' ) ) {
$info = 'Database query error';
} else {
$info = "Exception Caught: {$e->getMessage()}";
}
$errMessage = array(
'code' => 'internal_api_error_' . get_class( $e ),
'info' => $info,
);
ApiResult::setContent(
$errMessage,
$config->get( 'ShowExceptionDetails' ) ? "\n\n{$e->getTraceAsString()}\n\n" : ''
);
}
// Remember all the warnings to re-add them later
$oldResult = $result->getData();
$warnings = isset( $oldResult['warnings'] ) ? $oldResult['warnings'] : null;
$result->reset();
// Re-add the id
$requestid = $this->getParameter( 'requestid' );
if ( !is_null( $requestid ) ) {
$result->addValue( null, 'requestid', $requestid, ApiResult::NO_SIZE_CHECK );
}
if ( $config->get( 'ShowHostnames' ) ) {
// servedby is especially useful when debugging errors
$result->addValue( null, 'servedby', wfHostName(), ApiResult::NO_SIZE_CHECK );
}
if ( $warnings !== null ) {
$result->addValue( null, 'warnings', $warnings, ApiResult::NO_SIZE_CHECK );
}
$result->addValue( null, 'error', $errMessage, ApiResult::NO_SIZE_CHECK );
return $errMessage['code'];
}
/**
* Set up for the execution.
2011-01-30 08:16:13 +00:00
* @return array
*/
protected function setupExecuteAction() {
// First add the id to the top element
$result = $this->getResult();
$requestid = $this->getParameter( 'requestid' );
if ( !is_null( $requestid ) ) {
$result->addValue( null, 'requestid', $requestid );
}
if ( $this->getConfig()->get( 'ShowHostnames' ) ) {
$servedby = $this->getParameter( 'servedby' );
if ( $servedby ) {
$result->addValue( null, 'servedby', wfHostName() );
}
}
2008-01-08 18:10:58 +00:00
if ( $this->getParameter( 'curtimestamp' ) ) {
$result->addValue( null, 'curtimestamp', wfTimestamp( TS_ISO_8601, time() ),
ApiResult::NO_SIZE_CHECK );
}
$params = $this->extractRequestParams();
2010-02-22 03:34:56 +00:00
2007-06-29 22:05:30 +00:00
$this->mAction = $params['action'];
if ( !is_string( $this->mAction ) ) {
$this->dieUsage( 'The API requires a valid action parameter', 'unknown_action' );
}
return $params;
}
/**
* Set up the module for response
* @return ApiBase The module that will handle this action
*/
protected function setupModule() {
// Instantiate the module requested by the user
$module = $this->mModuleMgr->getModule( $this->mAction, 'action' );
if ( $module === null ) {
$this->dieUsage( 'The API requires a valid action parameter', 'unknown_action' );
}
$moduleParams = $module->extractRequestParams();
// Check token, if necessary
if ( $module->needsToken() === true ) {
throw new MWException(
"Module '{$module->getModuleName()}' must be updated for the new token handling. " .
"See documentation for ApiBase::needsToken for details."
);
}
if ( $module->needsToken() ) {
if ( !$module->mustBePosted() ) {
throw new MWException(
"Module '{$module->getModuleName()}' must require POST to use tokens."
);
}
if ( !isset( $moduleParams['token'] ) ) {
$this->dieUsageMsg( array( 'missingparam', 'token' ) );
}
if ( !$this->getConfig()->get( 'DebugAPI' ) &&
array_key_exists(
$module->encodeParamName( 'token' ),
$this->getRequest()->getQueryValues()
)
) {
$this->dieUsage(
"The '{$module->encodeParamName( 'token' )}' parameter was found in the query string, but must be in the POST body",
'mustposttoken'
);
}
if ( !$module->validateToken( $moduleParams['token'], $moduleParams ) ) {
$this->dieUsageMsg( 'sessionfailure' );
}
}
return $module;
}
/**
* Check the max lag if necessary
* @param ApiBase $module Api module being used
* @param array $params Array an array containing the request parameters.
* @return bool True on success, false should exit immediately
*/
2010-04-17 20:58:04 +00:00
protected function checkMaxLag( $module, $params ) {
if ( $module->shouldCheckMaxlag() && isset( $params['maxlag'] ) ) {
// Check for maxlag
$maxLag = $params['maxlag'];
list( $host, $lag ) = wfGetLB()->getMaxLag();
if ( $lag > $maxLag ) {
$response = $this->getRequest()->response();
$response->header( 'Retry-After: ' . max( intval( $maxLag ), 5 ) );
$response->header( 'X-Database-Lag: ' . intval( $lag ) );
if ( $this->getConfig()->get( 'ShowHostnames' ) ) {
$this->dieUsage( "Waiting for $host: $lag seconds lagged", 'maxlag' );
}
$this->dieUsage( "Waiting for a database server: $lag seconds lagged", 'maxlag' );
}
}
return true;
}
/**
* Check for sufficient permissions to execute
* @param ApiBase $module An Api module
*/
2010-04-17 20:58:04 +00:00
protected function checkExecutePermissions( $module ) {
$user = $this->getUser();
if ( $module->isReadMode() && !User::isEveryoneAllowed( 'read' ) &&
!$user->isAllowed( 'read' )
) {
$this->dieUsageMsg( 'readrequired' );
}
if ( $module->isWriteMode() ) {
if ( !$this->mEnableWrite ) {
$this->dieUsageMsg( 'writedisabled' );
}
if ( !$user->isAllowed( 'writeapi' ) ) {
$this->dieUsageMsg( 'writerequired' );
}
if ( wfReadOnly() ) {
$this->dieReadOnly();
}
}
// Allow extensions to stop execution for arbitrary reasons.
$message = false;
if ( !Hooks::run( 'ApiCheckCanExecute', array( $module, $user, &$message ) ) ) {
$this->dieUsageMsg( $message );
}
}
/**
* Check asserts of the user's rights
* @param array $params
*/
protected function checkAsserts( $params ) {
if ( isset( $params['assert'] ) ) {
$user = $this->getUser();
switch ( $params['assert'] ) {
case 'user':
if ( $user->isAnon() ) {
$this->dieUsage( 'Assertion that the user is logged in failed', 'assertuserfailed' );
}
break;
case 'bot':
if ( !$user->isAllowed( 'bot' ) ) {
$this->dieUsage( 'Assertion that the user has the bot right failed', 'assertbotfailed' );
}
break;
}
}
}
/**
* Check POST for external response and setup result printer
* @param ApiBase $module An Api module
* @param array $params An array with the request parameters
*/
2010-04-17 20:58:04 +00:00
protected function setupExternalResponse( $module, $params ) {
if ( !$this->getRequest()->wasPosted() && $module->mustBePosted() ) {
// Module requires POST. GET request might still be allowed
// if $wgDebugApi is true, otherwise fail.
$this->dieUsageMsgOrDebug( array( 'mustbeposted', $this->mAction ) );
}
// See if custom printer is used
$this->mPrinter = $module->getCustomPrinter();
if ( is_null( $this->mPrinter ) ) {
// Create an appropriate printer
$this->mPrinter = $this->createPrinterByName( $params['format'] );
}
if ( $this->mPrinter->getNeedsRawData() ) {
$this->getResult()->setRawMode();
}
}
/**
* Execute the actual module, without any error handling
*/
protected function executeAction() {
$params = $this->setupExecuteAction();
$module = $this->setupModule();
$this->mModule = $module;
2010-04-17 20:58:04 +00:00
$this->checkExecutePermissions( $module );
if ( !$this->checkMaxLag( $module, $params ) ) {
return;
}
if ( !$this->mInternalMode ) {
2010-04-17 20:58:04 +00:00
$this->setupExternalResponse( $module, $params );
}
$this->checkAsserts( $params );
// Execute
$module->profileIn();
$module->execute();
Hooks::run( 'APIAfterExecute', array( &$module ) );
$module->profileOut();
$this->reportUnusedParams();
if ( !$this->mInternalMode ) {
//append Debug information
MWDebug::appendDebugInfoToApiResult( $this->getContext(), $this->getResult() );
// Print result data
$this->printResult( false );
}
}
/**
* Log the preceding request
* @param int $time Time in seconds
*/
protected function logRequest( $time ) {
$request = $this->getRequest();
$milliseconds = $time === null ? '?' : round( $time * 1000 );
$s = 'API' .
' ' . $request->getMethod() .
' ' . wfUrlencode( str_replace( ' ', '_', $this->getUser()->getName() ) ) .
' ' . $request->getIP() .
' T=' . $milliseconds . 'ms';
foreach ( $this->getParamsUsed() as $name ) {
$value = $request->getVal( $name );
if ( $value === null ) {
continue;
}
$s .= ' ' . $name . '=';
if ( strlen( $value ) > 256 ) {
$encValue = $this->encodeRequestLogValue( substr( $value, 0, 256 ) );
$s .= $encValue . '[...]';
} else {
$s .= $this->encodeRequestLogValue( $value );
}
}
$s .= "\n";
wfDebugLog( 'api', $s, 'private' );
}
/**
* Encode a value in a format suitable for a space-separated log line.
* @param string $s
* @return string
*/
protected function encodeRequestLogValue( $s ) {
static $table;
if ( !$table ) {
$chars = ';@$!*(),/:';
$numChars = strlen( $chars );
for ( $i = 0; $i < $numChars; $i++ ) {
$table[rawurlencode( $chars[$i] )] = $chars[$i];
}
}
return strtr( rawurlencode( $s ), $table );
}
/**
* Get the request parameters used in the course of the preceding execute() request
* @return array
*/
protected function getParamsUsed() {
return array_keys( $this->mParamsUsed );
}
/**
* Get a request value, and register the fact that it was used, for logging.
* @param string $name
* @param mixed $default
* @return mixed
*/
public function getVal( $name, $default = null ) {
$this->mParamsUsed[$name] = true;
$ret = $this->getRequest()->getVal( $name );
if ( $ret === null ) {
if ( $this->getRequest()->getArray( $name ) !== null ) {
// See bug 10262 for why we don't just join( '|', ... ) the
// array.
$this->setWarning(
"Parameter '$name' uses unsupported PHP array syntax"
);
}
$ret = $default;
}
return $ret;
}
/**
* Get a boolean request value, and register the fact that the parameter
* was used, for logging.
* @param string $name
* @return bool
*/
public function getCheck( $name ) {
return $this->getVal( $name, null ) !== null;
}
/**
* Get a request upload, and register the fact that it was used, for logging.
*
* @since 1.21
* @param string $name Parameter name
* @return WebRequestUpload
*/
public function getUpload( $name ) {
$this->mParamsUsed[$name] = true;
return $this->getRequest()->getUpload( $name );
}
/**
* Report unused parameters, so the client gets a hint in case it gave us parameters we don't know,
* for example in case of spelling mistakes or a missing 'g' prefix for generators.
*/
protected function reportUnusedParams() {
$paramsUsed = $this->getParamsUsed();
$allParams = $this->getRequest()->getValueNames();
if ( !$this->mInternalMode ) {
// Printer has not yet executed; don't warn that its parameters are unused
$printerParams = array_map(
array( $this->mPrinter, 'encodeParamName' ),
array_keys( $this->mPrinter->getFinalParams() ?: array() )
);
$unusedParams = array_diff( $allParams, $paramsUsed, $printerParams );
} else {
$unusedParams = array_diff( $allParams, $paramsUsed );
}
if ( count( $unusedParams ) ) {
$s = count( $unusedParams ) > 1 ? 's' : '';
$this->setWarning( "Unrecognized parameter$s: '" . implode( $unusedParams, "', '" ) . "'" );
}
}
/**
* Print results using the current printer
*
* @param bool $isError
*/
protected function printResult( $isError ) {
if ( $this->getConfig()->get( 'DebugAPI' ) !== false ) {
$this->setWarning( 'SECURITY WARNING: $wgDebugAPI is enabled' );
}
$this->getResult()->cleanUpUTF8();
$printer = $this->mPrinter;
$printer->profileIn();
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
$printer->initPrinter( false );
$printer->execute();
$printer->closePrinter();
$printer->profileOut();
}
2010-01-22 03:14:52 +00:00
2011-01-30 08:16:13 +00:00
/**
* @return bool
*/
public function isReadMode() {
return false;
}
/**
* See ApiBase for description.
*
* @return array
*/
public function getAllowedParams() {
return array(
'action' => array(
ApiBase::PARAM_DFLT => 'help',
ApiBase::PARAM_TYPE => 'submodule',
),
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
'format' => array(
ApiBase::PARAM_DFLT => ApiMain::API_DEFAULT_FORMAT,
ApiBase::PARAM_TYPE => 'submodule',
),
'maxlag' => array(
ApiBase::PARAM_TYPE => 'integer'
),
'smaxage' => array(
ApiBase::PARAM_TYPE => 'integer',
ApiBase::PARAM_DFLT => 0
),
'maxage' => array(
ApiBase::PARAM_TYPE => 'integer',
ApiBase::PARAM_DFLT => 0
2008-06-16 20:06:23 +00:00
),
'assert' => array(
ApiBase::PARAM_TYPE => array( 'user', 'bot' )
),
'requestid' => null,
'servedby' => false,
'curtimestamp' => false,
'origin' => null,
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
'uselang' => array(
ApiBase::PARAM_DFLT => '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
),
);
}
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
/** @see ApiBase::getExamplesMessages() */
protected function getExamplesMessages() {
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(
'action=help'
=> 'apihelp-help-example-main',
'action=help&recursivesubmodules=1'
=> 'apihelp-help-example-recursive',
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 modifyHelp( array &$help, array $options ) {
// Wish PHP had an "array_insert_before". Instead, we have to manually
// reindex the array to get 'permissions' in the right place.
$oldHelp = $help;
$help = array();
foreach ( $oldHelp as $k => $v ) {
if ( $k === 'submodules' ) {
$help['permissions'] = '';
}
$help[$k] = $v;
}
$help['credits'] = '';
// Fill 'permissions'
$help['permissions'] .= Html::openElement( 'div',
array( 'class' => 'apihelp-block apihelp-permissions' ) );
$m = $this->msg( 'api-help-permissions' );
if ( !$m->isDisabled() ) {
$help['permissions'] .= Html::rawElement( 'div', array( 'class' => 'apihelp-block-head' ),
$m->numParams( count( self::$mRights ) )->parse()
);
}
$help['permissions'] .= Html::openElement( 'dl' );
foreach ( self::$mRights as $right => $rightMsg ) {
$help['permissions'] .= Html::element( 'dt', null, $right );
$rightMsg = $this->msg( $rightMsg['msg'], $rightMsg['params'] )->parse();
$help['permissions'] .= Html::rawElement( 'dd', null, $rightMsg );
$groups = array_map( function ( $group ) {
return $group == '*' ? 'all' : $group;
}, User::getGroupsWithPermission( $right ) );
$help['permissions'] .= Html::rawElement( 'dd', null,
$this->msg( 'api-help-permissions-granted-to' )
->numParams( count( $groups ) )
->params( $this->getLanguage()->commaList( $groups ) )
->parse()
);
}
$help['permissions'] .= Html::closeElement( 'dl' );
$help['permissions'] .= Html::closeElement( 'div' );
// Fill 'credits', if applicable
if ( empty( $options['nolead'] ) ) {
$help['credits'] .= Html::element( 'h' . min( 6, $options['headerlevel'] + 1 ),
array( 'id' => '+credits', 'class' => 'apihelp-header' ),
$this->msg( 'api-credits-header' )->parse()
);
$help['credits'] .= $this->msg( 'api-credits' )->useDatabase( false )->parseAsBlock();
}
}
private $mCanApiHighLimits = null;
/**
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
* Check whether the current user is allowed to use high limits
* @return bool
*/
public function canApiHighLimits() {
if ( !isset( $this->mCanApiHighLimits ) ) {
$this->mCanApiHighLimits = $this->getUser()->isAllowed( 'apihighlimits' );
}
return $this->mCanApiHighLimits;
}
/**
* Overrides to return this instance's module manager.
* @return ApiModuleManager
*/
public function getModuleManager() {
return $this->mModuleMgr;
}
/**
* Fetches the user agent used for this request
*
* The value will be the combination of the 'Api-User-Agent' header (if
* any) and the standard User-Agent header (if any).
*
* @return string
*/
public function getUserAgent() {
return trim(
$this->getRequest()->getHeader( 'Api-user-agent' ) . ' ' .
$this->getRequest()->getHeader( 'User-agent' )
);
}
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
/************************************************************************//**
* @name Deprecated
* @{
*/
/**
* Sets whether the pretty-printer should format *bold* and $italics$
*
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
* @deprecated since 1.25
* @param bool $help
*/
public function setHelp( $help = true ) {
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
wfDeprecated( __METHOD__, '1.25' );
$this->mPrinter->setHelp( $help );
}
/**
* Override the parent to generate help messages for all available modules.
*
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
* @deprecated since 1.25
* @return string
*/
public function makeHelpMsg() {
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
wfDeprecated( __METHOD__, '1.25' );
global $wgMemc;
$this->setHelp();
// Get help text from cache if present
$key = wfMemcKey( 'apihelp', $this->getModuleName(),
str_replace( ' ', '_', SpecialVersion::getVersion( 'nodb' ) ) );
$cacheHelpTimeout = $this->getConfig()->get( 'APICacheHelpTimeout' );
if ( $cacheHelpTimeout > 0 ) {
$cached = $wgMemc->get( $key );
if ( $cached ) {
return $cached;
}
}
$retval = $this->reallyMakeHelpMsg();
if ( $cacheHelpTimeout > 0 ) {
$wgMemc->set( $key, $retval, $cacheHelpTimeout );
}
return $retval;
}
2010-01-22 03:14: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
* @deprecated since 1.25
* @return mixed|string
*/
public function reallyMakeHelpMsg() {
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
wfDeprecated( __METHOD__, '1.25' );
$this->setHelp();
// Use parent to make default message for the main module
$msg = parent::makeHelpMsg();
2011-01-07 03:04:03 +00:00
$astriks = str_repeat( '*** ', 14 );
$msg .= "\n\n$astriks Modules $astriks\n\n";
foreach ( $this->mModuleMgr->getNames( 'action' ) as $name ) {
$module = $this->mModuleMgr->getModule( $name );
$msg .= self::makeHelpMsgHeader( $module, 'action' );
$msg2 = $module->makeHelpMsg();
if ( $msg2 !== false ) {
$msg .= $msg2;
}
$msg .= "\n";
}
$msg .= "\n$astriks Permissions $astriks\n\n";
foreach ( self::$mRights as $right => $rightMsg ) {
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
$rightsMsg = $this->msg( $rightMsg['msg'], $rightMsg['params'] )
->useDatabase( false )
->inLanguage( 'en' )
->text();
$groups = User::getGroupsWithPermission( $right );
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
$msg .= "* " . $right . " *\n $rightsMsg" .
"\nGranted to:\n " . str_replace( '*', 'all', implode( ', ', $groups ) ) . "\n\n";
}
$msg .= "\n$astriks Formats $astriks\n\n";
foreach ( $this->mModuleMgr->getNames( 'format' ) as $name ) {
$module = $this->mModuleMgr->getModule( $name );
$msg .= self::makeHelpMsgHeader( $module, 'format' );
$msg2 = $module->makeHelpMsg();
if ( $msg2 !== false ) {
$msg .= $msg2;
}
$msg .= "\n";
}
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
$credits = $this->msg( 'api-credits' )->useDatabase( 'false' )->inLanguage( 'en' )->text();
$credits = str_replace( "\n", "\n ", $credits );
$msg .= "\n*** Credits: ***\n $credits\n";
return $msg;
}
2010-12-23 19:24:38 +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
* @deprecated since 1.25
* @param ApiBase $module
* @param string $paramName What type of request is this? e.g. action,
* query, list, prop, meta, format
2010-12-23 19:24:38 +00:00
* @return string
*/
public static function makeHelpMsgHeader( $module, $paramName ) {
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
wfDeprecated( __METHOD__, '1.25' );
$modulePrefix = $module->getModulePrefix();
if ( strval( $modulePrefix ) !== '' ) {
$modulePrefix = "($modulePrefix) ";
}
return "* $paramName={$module->getModuleName()} $modulePrefix*";
}
/**
* Check whether the user wants us to show version information in the API help
* @return bool
* @deprecated since 1.21, always returns false
*/
public function getShowVersions() {
wfDeprecated( __METHOD__, '1.21' );
return false;
}
/**
* Add or overwrite a module in this ApiMain instance. Intended for use by extending
* classes who wish to add their own modules to their lexicon or override the
* behavior of inherent ones.
*
* @deprecated since 1.21, Use getModuleManager()->addModule() instead.
* @param string $name The identifier for this module.
* @param ApiBase $class The class where this module is implemented.
*/
protected function addModule( $name, $class ) {
$this->getModuleManager()->addModule( $name, 'action', $class );
}
/**
* Add or overwrite an output format for this ApiMain. Intended for use by extending
* classes who wish to add to or modify current formatters.
*
* @deprecated since 1.21, Use getModuleManager()->addModule() instead.
* @param string $name The identifier for this format.
* @param ApiFormatBase $class The class implementing this format.
*/
protected function addFormat( $name, $class ) {
$this->getModuleManager()->addModule( $name, 'format', $class );
}
/**
* Get the array mapping module names to class names
* @deprecated since 1.21, Use getModuleManager()'s methods instead.
2011-01-30 08:16:13 +00:00
* @return array
*/
function getModules() {
return $this->getModuleManager()->getNamesWithClasses( 'action' );
}
/**
* Returns the list of supported formats in form ( 'format' => 'ClassName' )
*
* @since 1.18
* @deprecated since 1.21, Use getModuleManager()'s methods instead.
* @return array
*/
public function getFormats() {
return $this->getModuleManager()->getNamesWithClasses( 'format' );
}
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 exception will be thrown when dieUsage is called to stop module execution.
*
* @ingroup API
*/
2012-03-16 02:02:41 +00:00
class UsageException extends MWException {
private $mCodestr;
/**
* @var null|array
*/
private $mExtraData;
/**
* @param string $message
* @param string $codestr
* @param int $code
* @param array|null $extradata
*/
public function __construct( $message, $codestr, $code = 0, $extradata = null ) {
parent::__construct( $message, $code );
$this->mCodestr = $codestr;
$this->mExtraData = $extradata;
}
/**
* @return string
*/
public function getCodeString() {
return $this->mCodestr;
}
/**
* @return array
*/
public function getMessageArray() {
$result = array(
'code' => $this->mCodestr,
'info' => $this->getMessage()
);
if ( is_array( $this->mExtraData ) ) {
$result = array_merge( $result, $this->mExtraData );
}
return $result;
}
/**
* @return string
*/
public function __toString() {
return "{$this->getCodeString()}: {$this->getMessage()}";
}
}
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
/**
* For really cool vim folding this needs to be at the end:
* vim: foldmarker=@{,@} foldmethod=marker
*/