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

673 lines
20 KiB
PHP
Raw Normal View History

<?php
/**
*
*
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
* Created on Aug 29, 2014
*
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
* Copyright © 2014 Brad Jorsch <bjorsch@wikimedia.org>
*
* 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
*/
/**
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
* Class to output help for an API module
*
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
* @since 1.25 completely rewritten
* @ingroup API
*/
class ApiHelp extends ApiBase {
public function execute() {
$params = $this->extractRequestParams();
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
$modules = 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
foreach ( $params['modules'] as $path ) {
$modules[] = $this->getModuleFromPath( $path );
}
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
// Get the help
$context = new DerivativeContext( $this->getMain()->getContext() );
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
$context->setSkin( SkinFactory::getDefaultInstance()->makeSkin( 'apioutput' ) );
$context->setLanguage( $this->getMain()->getLanguage() );
$context->setTitle( SpecialPage::getTitleFor( 'ApiHelp' ) );
$out = new OutputPage( $context );
$context->setOutput( $out );
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
self::getHelp( $context, $modules, $params );
// Grab the output from the skin
ob_start();
$context->getOutput()->output();
$html = ob_get_clean();
$result = $this->getResult();
if ( $params['wrap'] ) {
$data = array(
'mime' => 'text/html',
'help' => $html,
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
);
$result->setSubelements( $data, 'help' );
$result->addValue( null, $this->getModuleName(), $data );
} else {
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
$result->reset();
$result->addValue( null, 'text', $html, ApiResult::NO_SIZE_CHECK );
$result->addValue( null, 'mime', 'text/html', ApiResult::NO_SIZE_CHECK );
}
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
}
/**
* Generate help for the specified modules
*
* Help is placed into the OutputPage object returned by
* $context->getOutput().
*
* Recognized options include:
* - headerlevel: (int) Header tag level
* - nolead: (bool) Skip the inclusion of api-help-lead
* - noheader: (bool) Skip the inclusion of the top-level section headers
* - submodules: (bool) Include help for submodules of the current module
* - recursivesubmodules: (bool) Include help for submodules recursively
* - helptitle: (string) Title to link for additional modules' help. Should contain $1.
*
* @param IContextSource $context
* @param ApiBase[]|ApiBase $modules
* @param array $options Formatting options (described above)
* @return string
*/
public static function getHelp( IContextSource $context, $modules, array $options ) {
global $wgMemc, $wgContLang;
if ( !is_array( $modules ) ) {
$modules = array( $modules );
}
$out = $context->getOutput();
$out->addModules( 'mediawiki.apihelp' );
$out->setPageTitle( $context->msg( 'api-help-title' ) );
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
$cacheKey = null;
if ( count( $modules ) == 1 && $modules[0] instanceof ApiMain &&
$options['recursivesubmodules'] && $context->getLanguage() === $wgContLang
) {
$cacheHelpTimeout = $context->getConfig()->get( 'APICacheHelpTimeout' );
if ( $cacheHelpTimeout > 0 ) {
// Get help text from cache if present
$cacheKey = wfMemcKey( 'apihelp', $modules[0]->getModulePath(),
str_replace( ' ', '_', SpecialVersion::getVersion( 'nodb' ) ) );
$cached = $wgMemc->get( $cacheKey );
if ( $cached ) {
$out->addHTML( $cached );
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 ( $out->getHTML() !== '' ) {
// Don't save to cache, there's someone else's content in the page
// already
$cacheKey = null;
}
$options['recursivesubmodules'] = !empty( $options['recursivesubmodules'] );
$options['submodules'] = $options['recursivesubmodules'] || !empty( $options['submodules'] );
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
// Prepend lead
if ( empty( $options['nolead'] ) ) {
$msg = $context->msg( 'api-help-lead' );
if ( !$msg->isDisabled() ) {
$out->addHTML( $msg->parseAsBlock() );
}
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
$haveModules = array();
$out->addHTML( self::getHelpInternal( $context, $modules, $options, $haveModules ) );
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
$helptitle = isset( $options['helptitle'] ) ? $options['helptitle'] : null;
$html = self::fixHelpLinks( $out->getHTML(), $helptitle, $haveModules );
$out->clearHTML();
$out->addHTML( $html );
if ( $cacheKey !== null ) {
$wgMemc->set( $cacheKey, $out->getHTML(), $cacheHelpTimeout );
}
}
/**
* Replace Special:ApiHelp links with links to api.php
*
* @param string $html
* @param string|null $helptitle Title to link to rather than api.php, must contain '$1'
* @param array $localModules Modules to link within the current page
* @return string
*/
public static function fixHelpLinks( $html, $helptitle = null, $localModules = array() ) {
$formatter = new HtmlFormatter( $html );
$doc = $formatter->getDoc();
$xpath = new DOMXPath( $doc );
$nodes = $xpath->query( '//a[@href][not(contains(@class,\'apihelp-linktrail\'))]' );
foreach ( $nodes as $node ) {
$href = $node->getAttribute( 'href' );
do {
$old = $href;
$href = rawurldecode( $href );
} while ( $old !== $href );
if ( preg_match( '!Special:ApiHelp/([^&/|]+)!', $href, $m ) ) {
if ( isset( $localModules[$m[1]] ) ) {
$href = '#' . $m[1];
} elseif ( $helptitle !== null ) {
$href = Title::newFromText( str_replace( '$1', $m[1], $helptitle ) )
->getFullUrl();
} else {
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
$href = wfAppendQuery( wfScript( 'api' ), array(
'action' => 'help',
'modules' => $m[1],
) );
}
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
$node->setAttribute( 'href', $href );
$node->removeAttribute( 'title' );
}
}
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 $formatter->getText();
}
/**
* Wrap a message in HTML with a class.
*
* @param Message $msg
* @param string $class
* @param string $tag
* @return string
*/
private static function wrap( Message $msg, $class, $tag = 'span' ) {
return Html::rawElement( $tag, array( 'class' => $class ),
$msg->parse()
);
}
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
* Recursively-called function to actually construct the help
*
* @param IContextSource $context
* @param ApiBase[] $modules
* @param array $options
* @param array &$haveModules
2010-12-23 19:24:38 +00:00
* @return string
*/
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
private static function getHelpInternal( IContextSource $context, array $modules,
array $options, &$haveModules
) {
$out = '';
$level = min( 6, empty( $options['headerlevel'] ) ? 2 : $options['headerlevel'] );
$options['headerlevel'] = $level;
foreach ( $modules as $module ) {
$haveModules[$module->getModulePath()] = true;
$module->setContext( $context );
$help = array(
'header' => '',
'flags' => '',
'description' => '',
'help-urls' => '',
'parameters' => '',
'examples' => '',
'submodules' => '',
);
if ( empty( $options['noheader'] ) ) {
$path = $module->getModulePath();
if ( $module->isMain() ) {
$header = $context->msg( 'api-help-main-header' )->parse();
} else {
$name = $module->getModuleName();
$header = $module->getParent()->getModuleManager()->getModuleGroup( $name ) .
"=$name";
if ( $module->getModulePrefix() !== '' ) {
$header .= ' ' .
$context->msg( 'parentheses', $module->getModulePrefix() )->parse();
}
}
$help['header'] .= Html::element( "h$level",
array( 'id' => $path, 'class' => 'apihelp-header' ),
$header
);
}
$links = array();
$any = false;
for ( $m = $module; $m !== null; $m = $m->getParent() ) {
$name = $m->getModuleName();
if ( $name === 'main_int' ) {
$name = 'main';
}
if ( count( $modules ) === 1 && $m === $modules[0] &&
!( !empty( $options['submodules'] ) && $m->getModuleManager() )
) {
$link = Html::element( 'b', null, $name );
} else {
$link = SpecialPage::getTitleFor( 'ApiHelp', $m->getModulePath() )->getLocalURL();
$link = Html::element( 'a',
array( 'href' => $link, 'class' => 'apihelp-linktrail' ),
$name
);
$any = true;
}
array_unshift( $links, $link );
}
if ( $any ) {
$help['header'] .= self::wrap(
$context->msg( 'parentheses' )
->rawParams( $context->getLanguage()->pipeList( $links ) ),
'apihelp-linktrail', 'div'
);
}
$flags = $module->getHelpFlags();
if ( $flags ) {
$help['flags'] .= Html::openElement( 'div',
array( 'class' => 'apihelp-block apihelp-flags' ) );
$msg = $context->msg( 'api-help-flags' );
if ( !$msg->isDisabled() ) {
$help['flags'] .= self::wrap(
$msg->numParams( count( $flags ) ), 'apihelp-block-head', 'div'
);
}
$help['flags'] .= Html::openElement( 'ul' );
foreach ( $flags as $flag ) {
$help['flags'] .= Html::rawElement( 'li', null,
self::wrap( $context->msg( "api-help-flag-$flag" ), "apihelp-flag-$flag" )
);
}
$help['flags'] .= Html::closeElement( 'ul' );
$help['flags'] .= Html::closeElement( 'div' );
}
foreach ( $module->getFinalDescription() as $msg ) {
$msg->setContext( $context );
$help['description'] .= $msg->parseAsBlock();
}
$urls = $module->getHelpUrls();
if ( $urls ) {
$help['help-urls'] .= Html::openElement( 'div',
array( 'class' => 'apihelp-block apihelp-help-urls' )
);
$msg = $context->msg( 'api-help-help-urls' );
if ( !$msg->isDisabled() ) {
$help['help-urls'] .= self::wrap(
$msg->numParams( count( $urls ) ), 'apihelp-block-head', 'div'
);
}
if ( !is_array( $urls ) ) {
$urls = array( $urls );
}
$help['help-urls'] .= Html::openElement( 'ul' );
foreach ( $urls as $url ) {
$help['help-urls'] .= Html::rawElement( 'li', null,
Html::element( 'a', array( 'href' => $url ), $url )
);
}
$help['help-urls'] .= Html::closeElement( 'ul' );
$help['help-urls'] .= Html::closeElement( 'div' );
}
$params = $module->getFinalParams( ApiBase::GET_VALUES_FOR_HELP );
$groups = array();
if ( $params ) {
$help['parameters'] .= Html::openElement( 'div',
array( 'class' => 'apihelp-block apihelp-parameters' )
);
$msg = $context->msg( 'api-help-parameters' );
if ( !$msg->isDisabled() ) {
$help['parameters'] .= self::wrap(
$msg->numParams( count( $params ) ), 'apihelp-block-head', 'div'
);
}
$help['parameters'] .= Html::openElement( 'dl' );
$descriptions = $module->getFinalParamDescription();
foreach ( $params as $name => $settings ) {
if ( !is_array( $settings ) ) {
$settings = array( ApiBase::PARAM_DFLT => $settings );
}
$help['parameters'] .= Html::element( 'dt', null,
$module->encodeParamName( $name ) );
// Add description
$description = array();
if ( isset( $descriptions[$name] ) ) {
foreach ( $descriptions[$name] as $msg ) {
$msg->setContext( $context );
$description[] = $msg->parseAsBlock();
}
}
// Add usage info
$info = array();
// Required?
if ( !empty( $settings[ApiBase::PARAM_REQUIRED] ) ) {
$info[] = $context->msg( 'api-help-param-required' )->parse();
}
// Custom info?
if ( !empty( $settings[ApiBase::PARAM_HELP_MSG_INFO] ) ) {
foreach ( $settings[ApiBase::PARAM_HELP_MSG_INFO] as $i ) {
$tag = array_shift( $i );
$info[] = $context->msg( "apihelp-{$path}-paraminfo-{$tag}" )
->numParams( count( $i ) )
->params( $context->getLanguage()->commaList( $i ) )
->params( $module->getModulePrefix() )
->parse();
}
}
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
// Type documentation
if ( !isset( $settings[ApiBase::PARAM_TYPE] ) ) {
$dflt = isset( $settings[ApiBase::PARAM_DFLT] )
? $settings[ApiBase::PARAM_DFLT]
: null;
if ( is_bool( $dflt ) ) {
$settings[ApiBase::PARAM_TYPE] = 'boolean';
} elseif ( is_string( $dflt ) || is_null( $dflt ) ) {
$settings[ApiBase::PARAM_TYPE] = 'string';
} elseif ( is_int( $dflt ) ) {
$settings[ApiBase::PARAM_TYPE] = 'integer';
}
}
if ( isset( $settings[ApiBase::PARAM_TYPE] ) ) {
$type = $settings[ApiBase::PARAM_TYPE];
$multi = !empty( $settings[ApiBase::PARAM_ISMULTI] );
$hintPipeSeparated = true;
$count = ApiBase::LIMIT_SML2 + 1;
if ( is_array( $type ) ) {
$count = count( $type );
$links = isset( $settings[ApiBase::PARAM_VALUE_LINKS] )
? $settings[ApiBase::PARAM_VALUE_LINKS]
: array();
$type = array_map( function ( $v ) use ( $links ) {
$ret = wfEscapeWikiText( $v );
if ( isset( $links[$v] ) ) {
$ret = "[[{$links[$v]}|$ret]]";
}
return $ret;
}, $type );
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
$i = array_search( '', $type, true );
if ( $i === false ) {
$type = $context->getLanguage()->commaList( $type );
} else {
unset( $type[$i] );
$type = $context->msg( 'api-help-param-list-can-be-empty' )
->numParams( count( $type ) )
->params( $context->getLanguage()->commaList( $type ) )
->parse();
}
$info[] = $context->msg( 'api-help-param-list' )
->params( $multi ? 2 : 1 )
->params( $type )
->parse();
$hintPipeSeparated = false;
} else {
switch ( $type ) {
case 'submodule':
$groups[] = $name;
$submodules = $module->getModuleManager()->getNames( $name );
$count = count( $submodules );
sort( $submodules );
$prefix = $module->isMain()
? '' : ( $module->getModulePath() . '+' );
$submodules = array_map( function ( $name ) use ( $prefix ) {
return "[[Special:ApiHelp/{$prefix}{$name}|{$name}]]";
}, $submodules );
$info[] = $context->msg( 'api-help-param-list' )
->params( $multi ? 2 : 1 )
->params( $context->getLanguage()->commaList( $submodules ) )
->parse();
$hintPipeSeparated = false;
break;
case 'namespace':
$namespaces = MWNamespace::getValidNamespaces();
$count = count( $namespaces );
$info[] = $context->msg( 'api-help-param-list' )
->params( $multi ? 2 : 1 )
->params( $context->getLanguage()->commaList( $namespaces ) )
->parse();
$hintPipeSeparated = false;
break;
case 'limit':
if ( isset( $settings[ApiBase::PARAM_MAX2] ) ) {
$info[] = $context->msg( 'api-help-param-limit2' )
->numParams( $settings[ApiBase::PARAM_MAX] )
->numParams( $settings[ApiBase::PARAM_MAX2] )
->parse();
} else {
$info[] = $context->msg( 'api-help-param-limit' )
->numParams( $settings[ApiBase::PARAM_MAX] )
->parse();
}
break;
case 'integer':
// Possible messages:
// api-help-param-integer-min,
// api-help-param-integer-max,
// api-help-param-integer-minmax
$suffix = '';
$min = $max = 0;
if ( isset( $settings[ApiBase::PARAM_MIN] ) ) {
$suffix .= 'min';
$min = $settings[ApiBase::PARAM_MIN];
}
if ( isset( $settings[ApiBase::PARAM_MAX] ) ) {
$suffix .= 'max';
$max = $settings[ApiBase::PARAM_MAX];
}
if ( $suffix !== '' ) {
$info[] =
$context->msg( "api-help-param-integer-$suffix" )
->params( $multi ? 2 : 1 )
->numParams( $min, $max )
->parse();
}
break;
case 'upload':
$info[] = $context->msg( 'api-help-param-upload' )
->parse();
break;
}
}
if ( $multi ) {
$extra = array();
if ( $hintPipeSeparated ) {
$extra[] = $context->msg( 'api-help-param-multi-separate' )->parse();
}
if ( $count > ApiBase::LIMIT_SML1 ) {
$extra[] = $context->msg( 'api-help-param-multi-max' )
->numParams( ApiBase::LIMIT_SML1, ApiBase::LIMIT_SML2 )
->parse();
}
if ( $extra ) {
$info[] = join( ' ', $extra );
}
}
}
// Add default
$default = isset( $settings[ApiBase::PARAM_DFLT] )
? $settings[ApiBase::PARAM_DFLT]
: null;
if ( $default === '' ) {
$info[] = $context->msg( 'api-help-param-default-empty' )
->parse();
} elseif ( $default !== null && $default !== false ) {
$info[] = $context->msg( 'api-help-param-default' )
->params( wfEscapeWikiText( $default ) )
->parse();
}
if ( !array_filter( $description ) ) {
$description = array( self::wrap(
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
$context->msg( 'api-help-param-no-description' ),
'apihelp-empty'
) );
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
}
// Add "deprecated" flag
if ( !empty( $settings[ApiBase::PARAM_DEPRECATED] ) ) {
$help['parameters'] .= Html::openElement( 'dd',
array( 'class' => 'info' ) );
$help['parameters'] .= self::wrap(
$context->msg( 'api-help-param-deprecated' ),
'apihelp-deprecated', 'strong'
);
$help['parameters'] .= Html::closeElement( 'dd' );
}
if ( $description ) {
$description = join( '', $description );
$description = preg_replace( '!\s*</([oud]l)>\s*<\1>\s*!', "\n", $description );
$help['parameters'] .= Html::rawElement( 'dd',
array( 'class' => 'description' ), $description );
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
}
foreach ( $info as $i ) {
$help['parameters'] .= Html::rawElement( 'dd', array( 'class' => 'info' ), $i );
}
}
$help['parameters'] .= Html::closeElement( 'dl' );
$help['parameters'] .= Html::closeElement( 'div' );
}
$examples = $module->getExamplesMessages();
if ( $examples ) {
$help['examples'] .= Html::openElement( 'div',
array( 'class' => 'apihelp-block apihelp-examples' ) );
$msg = $context->msg( 'api-help-examples' );
if ( !$msg->isDisabled() ) {
$help['examples'] .= self::wrap(
$msg->numParams( count( $examples ) ), 'apihelp-block-head', 'div'
);
}
$help['examples'] .= Html::openElement( 'dl' );
foreach ( $examples as $qs => $msg ) {
$msg = ApiBase::makeMessage( $msg, $context, array(
$module->getModulePrefix(),
$module->getModuleName(),
$module->getModulePath()
) );
$link = wfAppendQuery( wfScript( 'api' ), $qs );
$help['examples'] .= Html::rawElement( 'dt', null, $msg->parse() );
$help['examples'] .= Html::rawElement( 'dd', null,
Html::element( 'a', array( 'href' => $link ), "api.php?$qs" )
);
}
$help['examples'] .= Html::closeElement( 'dl' );
$help['examples'] .= Html::closeElement( 'div' );
}
if ( $options['submodules'] && $module->getModuleManager() ) {
$manager = $module->getModuleManager();
$submodules = array();
foreach ( $groups as $group ) {
$names = $manager->getNames( $group );
sort( $names );
foreach ( $names as $name ) {
$submodules[] = $manager->getModule( $name );
}
}
$help['submodules'] .= self::getHelpInternal( $context, $submodules, array(
'submodules' => $options['recursivesubmodules'],
'headerlevel' => $level + 1,
'noheader' => false,
) + $options, $haveModules );
}
$module->modifyHelp( $help, $options );
Hooks::run( 'APIHelpModifyOutput', array( $module, &$help, $options ) );
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
$out .= join( "\n", $help );
}
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
return $out;
}
public function shouldCheckMaxlag() {
return false;
}
public function isReadMode() {
return false;
}
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
public function getCustomPrinter() {
$params = $this->extractRequestParams();
if ( $params['wrap'] ) {
return null;
}
$main = $this->getMain();
$errorPrinter = $main->createPrinterByName( $main->getParameter( 'format' ) );
return new ApiFormatRaw( $main, $errorPrinter );
}
public function getAllowedParams() {
return array(
'modules' => 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
ApiBase::PARAM_DFLT => 'main',
ApiBase::PARAM_ISMULTI => 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
'submodules' => false,
'recursivesubmodules' => false,
'wrap' => false,
'toc' => false,
);
}
protected function getExamplesMessages() {
return array(
'action=help'
=> 'apihelp-help-example-main',
'action=help&recursivesubmodules=1'
=> 'apihelp-help-example-recursive',
'action=help&modules=help'
=> 'apihelp-help-example-help',
'action=help&modules=query+info|query+categorymembers'
=> 'apihelp-help-example-query',
);
}
public function getHelpUrls() {
return array(
'https://www.mediawiki.org/wiki/API:Main_page',
'https://www.mediawiki.org/wiki/API:FAQ',
'https://www.mediawiki.org/wiki/API:Quick_start_guide',
);
}
}