Jump to content

Руководство:Служебные страницы

From mediawiki.org
This page is a translated version of the page Manual:Special pages and the translation is 37% complete.
Outdated translations are marked like this.
Languages:
MediaWiki extensions

Служебные страницы — это страницы, которые были созданы программным обеспечением по запросу, чтобы исполнять особые функции.

Например, специальная страница может отображать все страницы, которые имеют одну или несколько ссылок на внешний сайт, или она может создать форму, предоставляющую пользовательскую обратную связь.

Служебные страницы находятся в своём собственном пространстве имён (Служебная:) и они не редактируются напрямую, как остальные страницы. Разработчики также могут создавать новые служебные страницы.

Эти страницы по умолчанию доступны пользователю и как правило, отображаются в списке всех служебных страниц на Special:SpecialPages. Лишь несколько служебных страниц доступны только пользователям с определенными разрешениями и доступом. Другие служебные страницы, никому не доступны, и используются только внутри вики.

Основная информация

Все встроенные служебные страницы которые приходят с дистрибутивом MediaWiki, называются SpecialSomename.php и расположены в каталоге includes/specials Главные служебные страницы должны быть зарегистрированы в генеральном списке, расположенном в includes/specialpage/SpecialPageFactory.php для того, чтобы загрузить MediaWiki. Служебные страницы созданные сторонними разработчиками, обычно находятся в директории extensions в собственном файле, или в рамках более крупного расширения. Все служебные страницы унаследованы от класса под названием SpecialPage который определён в includes/specialpage/SpecialPage.php Во время создания служебной страницы, можно выбрать права пользователя, которые необходимы для доступа к странице. Эти права определяют, среди прочего, будет ли страница отображаться в Special:SpecialPages и может ли эта страница быть подключенной к другим страницам.

Служебные страницы также имеют уникальные имена, которые вполне настраиваемы на вики. Общая форма это "Служебная:Имя страницы" где и "Служебная", и "Имя страницы" могут быть кастомизированы. Например, под "Служебная:Шаблоны на проверку". Служебный псевдо-$manual может быть локализован на другие языки. Это локализованное пространство имён может быть произведено при помощи вики-текста {{ns:special}}, в этой вики дающего "Special" Имя служебной страницы также может быть переопределено в системном сообщении, для языка сайта, с общим названием служебной страницы в качестве идентификатора.

Служебная страница может разрешить или запретить ввод. Например, Special:Export позволяет пользователю определить конкретную страницу для экспортирования, вызвав Special:Export/Sun Если служебная страница разрешает сложный ввод, дополнительные параметры будут отправлены в компонент строку запроса URL для обработки, например https://www.mediawiki.org/w/index.php?title=Special:Recentchanges&days=3&limit=250.

  • Существуют различные способы создания служебных страниц, но приведенный ниже используется большинством официальных $man, и рекомендуется придерживаться этого стиля.
Между тем, не забудьте подключить блок титров в новую служебную страницу для 'specialpage'. Посетите $wgExtensionCredits для большего понимания темы.
  • После создания новой служебной страницы, добавьте её к Категория:Расширения со служебными страницами для того, чтобы пользователи могли найти её.
  • Служебные страницы не могут быть включины в рамки, если только Вы не используете $wgOut->allowClickjacking();.

Базовый шаблон служебной страницы

Большинство служебных страниц расширений требуют эти три файла:

  • Маленький файл настройки, который загружается каждый раз, когда MediaWiki запускается.
  • Файл с основной частью кода.
  • Файл локализации

Соглашения о кодировании MediaWiki определяют три файла следующим образом:

  • MyExtension/extension.json – Установочный файл.
  • MyExtension/includes/Special.php – Код служебной страницы
  • i18n/*.json – Файл локализации .

Поместите все файлы в новую директорию внутри каталога MediaWiki extensions/.

Файл служебной страницы следует назвать по имени расширения. Например, Расширение:Гаджеты содержит файл SpecialGadgets.php. Если ваше расширение использует больше чем одна служебная страница, вам понадобится больше имён.

В примере ниже, имя служебной страницы это MyExtension.

После создания файлов перечисленных ниже, добавление следующей строки в LocalSettings.php включает расширение: 

wfLoadExtension( 'MyExtension' );

Файл установки

Пример файла настройки для MyExtension/extension.json: 

{
	"name": "MyExtension",
	"version": "0.0.0",
	"author": [
		"Your Name"
	],
	"url": "https://www.mediawiki.org/wiki/Extension:MyExtension",
	"descriptionmsg": "myextension-desc",
	"license-name": "MIT",
	"type": "other",
	"AutoloadNamespaces": {
		"MediaWiki\\Extension\\MyExtension\\": "src/"
	},
	"SpecialPages": {
		"MyExtension": "MediaWiki\\Extension\\MyExtension\\Special"
	},
	"MessagesDirs": {
		"MyExtension": [
			"i18n"
		]
	},
	"manifest_version": 2,
	"requires": {
		"MediaWiki": ">= 1.42.0",
		"platform": {
			"php": ">= 5.6"
		},
		"extensions": {
			"dependendExtension": "*"
		}
	}
}

В этом файле регистрируется несколько важных и обязательных вещей:

  • Местонахождения класса MediaWiki\Extension\MyExtension\Special;
  • Местонахождение файлов локализации;
  • Новая служебная страница и имя её класса.
Если вы получаете ошибку InvalidArgumentException: Provided specification is not an array, это как правило, означает что MediaWiki не может найти класс, указанный в extension.json, который реализует вашу служебную страницу.

Файл служебной страницы

Файл корпуса (MyExtension/src/Special.php) должен содержать подкласс SpecialPage, или один из его подклассов. Этот файл автоматически загружается, когда кто-нибудь запрашивает служебную страницу. Пример ниже реализует подкласс SpecialMyExtension.

Вам нужна конструкция __construct() ведь первый параметр называет вашу служебную страницу.

execute() — основная функция, которая вызывается при доступе к служебной странице. Эта функция переопределяет функцию SpecialPage::execute(). Она передаёт единственный параметр $par, компонент подстраницы текущего заголовка. Например, если кто-нибудь переходит по ссылке Special:MyExtension/blah, то $par содержит "blah".

Вы должны запустить выход Вики-текста и HTML через $wgOut. Не используйте 'print' или 'echo' напрямую при работе в интерфейсе пользователя вики.

Однако, если вы используете свою служебную страницу в качестве точки доступа к кастомизированному XML или двоичному выходу, посетите Taking over output in your special page . 

<?php
namespace MediaWiki\Extension\MyExtension;
class SpecialMyExtension extends \SpecialPage {
	public function __construct() {
		parent::__construct( 'MyExtension' );
	}

	public function execute( $par ) {
		$request = $this->getRequest();
		$output = $this->getOutput();
		$this->setHeaders();

		# Get request data from, e.g.
		$param = $request->getText( 'param' );

		# Do stuff
		# ...
		$wikitext = 'Hello world!';
		$output->addWikiTextAsInterface( $wikitext );
	}
}

Файл локализации

Посетите Помощь:Системные сообщения чтобы получить их перевод.

На всех служебных страницах указан заголовок, как например 'My Extension'.

  • Заголовок используется в элементах ‎<title> и ‎<h1> на странице расширения и на Special:SpecialPages.
  • Это может быть что угодно, но оно должно описывать служебную страницу и расширение.
  • Оно задается с помощью сообщения. Структура сообщения представляет собой пару "ключ-значение". Ключ, 'myextension', должен быть полностью строчным.

Пример файла локализации в MyExtension/i18n/en.json: 

{
	"@metadata": {
		"authors": [
			"<your username>"
		]
	},
	"myextension": "My Extension",
	"myextension-desc": "Adds the MyExtension functionality.",
	"myextension-summary": "On this special page, do this simple thing and earn wonders.",
	"group-myextensionrole": "Role of myextension",
	"group-myextensionrole-member": "Member of role of myextension",
	"grouppage-myextensionrole": "{{ns:project}}:Role of myextension",
	"action-myextension": "XYZ doing.",
	"right-myextension": "to do xyz"
}

В i18n/qqq.json, документация сообщений: 

{
	"@metadata": {
		"authors": [
			"<your username>"
		]
	},
	"myextension": "The name of the extension's entry in Special:SpecialPages",
	"myextension-desc": "{{desc}}",
	"myextension-summary": "Description appearing on top of Special:MyExtension.",
	"action-myextension": "{{doc-action|myextension}}",
	"right-myextension": "{{doc-right|myextension}}"
}

Учтите, что идентификаторы не должны начинаться с заглавной буквы, и что пробел должен быть заменён знаком нижнего подчёркивания "_"

Сообщение -summary является опциональным. Он создаётся автоматически от родительского класса, и отображается наверху служебной страницы, обычно для краткого описания того, что пользователь может сделать на нем. Если вы не определили его содержимое, оно будет использоваться только тогда, когда вики-администраторы кастомизируют его на вики.

Файлы псевдонимов

Вы также можете интернационализировать название служебной страницы, создав для нее псевдоним. Пример ниже использует файл "MyExtension.i18n.alias.php". В этом примере для специальной страницы MyExtension регистрируется псевдоним, поэтому она становится доступной по адресам .../Special:My Extension и .../Spezial:Meine_Erweiterung на немецком языке.

Добавьте псевдоним в файл extension.json: 

...
	"ExtensionMessagesFiles": {
		"MyExtensionAlias": "MyExtension.i18n.alias.php"
	},
...

Добавьте псевдонимы служебных страниц в файл MyExtension.i18n.alias.php: 

<?php
/**
 * Aliases for myextension
 *
 * @file
 * @ingroup Extensions
 */

$specialPageAliases = [];

/** English
 * @author <ваше имя пользователя>
 */
$specialPageAliases['en'] = [
	'MyExtension' => [ 'MyExtension', 'My Extension' ],
];

/** Deutsch
 * @author <ваше имя пользователя>
 */
$specialPageAliases['de'] = [
	'MyExtension' => [ 'MeineErweiterung', 'Meine Erweiterung' ],
];

И снова, в идентификатор следует писать пробел, а в коде - знак нижнего подчеркивания.

Для заголовка страницы и ссылок применяются обычные правила для названий страниц.

Если $wgCapitalLinks истинно, то строчная буква конвертируется в заглавную, а нижнее подчёркивание будет отображатся как пробел.

Например, вместо вышеперечисленного мы можем использовать 'my_extension' => 'My extension', предполагая, что в других местах мы последовательно идентифицировали расширение как my_extension.

Обратите внимание, что в ассоциативном массиве для английского языка строка, идентифицирующая нашу служебную страницу (MyExtension в примере), является также допустимым заголовком.

Also note, the first element of $specialPageAliases['en']['MyExtension'] must be the same as the key ('MyExtension')! Otherwise Special:Specialpages will not list the page.

Группа служебных страниц

You can set which group your special page appears under on Special:SpecialPages by overriding SpecialPage::getGroupName() in your subclass. 

    /**
     * Override the parent to set where the special page appears on Special:SpecialPages
     * 'other' is the default. If that's what you want, you do not need to override.
     * Specify 'media' to use the <code>specialpages-group-media</code> system interface message, which translates to 'Media reports and uploads' in English;
     * 
     * @return string
     */
    function getGroupName() {
        return 'media';
    }

Some common values are 'login', 'maintenance', 'media', 'other', 'pagetools', 'redirects', 'users'. You can see the accepted values at Special:AllMessages (search for specialpages-group or browse the wiki using the pseudo language 'qqx' by going to Special:SpecialPages?uselang=qqx) and looking at the headings. Specify the word 'media' to use the interface message 'specialpages-group-media'.

If your special page doesn't fit into any of the preconfigured headings, you can add a new heading by adding it to your localisation file (see The localisation file).

The standard page groups that come with MediaWiki are listed in the localisation file. For example, the English messages are in languages/i18n/en.json and begin with specialpages-group-. If you want to categorize your special page under users, then the message is specialpages-group-users. The value for this key is the text that appears as the name of that category, for example, Users and rights.

If your special page does not seem to fit under any of the existing categories, you can always make a new one. In your extension's localisation file simply insert a new key for the messages array. In this example, we define the gamification group: 

{
    "myextension": "My Extension",
	"myextension-desc": "Adds the MyExtension functionality.",
	"myextension-summary": "On this special page, do this simple thing and earn wonders",
	"specialpages-group-gamification": "Gamification"
}

Now, assuming you set the return value for the method SpecialPage::getGroupName() as gamification in your class definition, reload Special:SpecialPages to see your new category.

Другие важные файлы

SpecialPage.php

Конструктор

You can overload the constructor to initialize your own data, but the main reason you would want to do it is to change the behavior of the SpecialPage class itself. When you call the base class constructor from your child class, the following parameters are available: 

function __construct( $name = '', $restriction = '', $listed = true );
  • string $name Name of the special page, as seen in links and URLs
  • string $restriction User right required, e.g. "block" or "delete"; also see Restricting page access
  • boolean $listed Whether the page is listed in Special:Specialpages

SpecialPage->setHeaders()

This initialises the OutputPage object $wgOut with the name and description of your special page. It should always be called from your execute() method.

SpecialPage->getOutput()

This method returns an OutputPage object which can be accessed as described below. As in the example code, use 

$output = $this->getOutput();
$output->addWikiTextAsInterface( 'Hello, World' );

instead of the deprecated $wgOut global variable

SpecialPage->getRequest()

This method returns a WebRequest object which can be accessed as described below. Как и в примере кода, используйте 

$request = $this->getRequest();
$myparam = $request->getText( 'myparam' );

instead of the deprecated $wgRequest global variable

SpecialPage->including()

Some special pages can be included from within another page. For example, if you add {{Special:RecentChanges}} to the wikitext of a page, it will insert a listing of recent changes within the existing content of the page.

Including a special page from another web page is only possible if you declared the page to be includable in the constructor. You can do this by adding the following in the __construct() method after the parent class initialization: 

$this->mIncludable = true;

You can also define your SpecialPage class as extending the IncludableSpecialPage class.

The SpecialPage->including() function returns a boolean value telling you what context the special page is being called from: false if it is a separate web page, and true if it is being included from within another web page. Usually you will want to strip down the presentation somewhat if the page is being included.

SpecialPage->execute()

This is the function which your child class should overload. It passes a single parameter, usually referred to cryptically as $par (short for $parameter, as it is the parameter the users can feed to your special page). This parameter is the subpage component of the current title. For example, if someone follows a link to Special:MyExtension/blah, $par will contain "blah".

Справочная страница
Версия MediaWiki:
≥ 1.25

It's useful to add help pages on MediaWiki.org, where they'll be translatable. To make sure users find your help page, it's advisable and very simple for your special page to link the help page in question: 

$this->addHelpLink( 'Help:Extension:MyExtension' );

OutputPage.php

OutputPage.php contains the class definition for objects of type OutputPage. You can get an object of this class from your SpecialPage using 

$output = $this->getOutput();

The variable name $output is, of course, arbitrary. Whatever you call it, this is the variable you will use the most, because it is the way to send output to the browser (no, you don't use echo or print). If you want to use it somewhere, create the variable and then use it: 

function randomFunction() {
	$output = $this->getOutput();
	$output->addHTML( '<b>This is not a pipe...</b>' );
}

If you want to, you can create multiple OutputPage objects in different methods in your SpecialPage extension. They will add to the output in the order they are executed.

You can inspect the OutputPage class by viewing includes/OutputPage.php (indeed, all of these can be inspected), but there are a few methods you should definitely know about.

OutputPage->addHTML()

Essentially the quick and dirty substitute for echo. It takes your input and adds it to the buffer: no questions asked. In the below action, if $action contains user-data, it could easily have XSS, evil stuff, or the spawn of Satan injected in. You're better off using escaping (such as with the php function htmlentities) or the XML builders class to build trusted output. 

$output->addHTML( '<form action="'.$action.'" method="post">' );

OutputPage->addWikiText()

For most output, you should be using this function. It's a bit of a black magic function: wikitext goes in, HTML comes out, and a whole lotta arcane code and demon summonings happen in between. 

$output->addWikiText("This is some ''lovely'' [[wikitext]] that will '''get''' parsed nicely.");

What's worth noting is that the parser will view your chunks as cohesive wholes and paragraph accordingly. That is... 

$output->addWikiText( '* Item 1' );
$output->addWikiText( '* Item 2' );
$output->addWikiText( '* Item 3' );

Will output three lists with one item each, which probably wasn't intended.

Note however, if you just want to insert a system message and have it treated like parsed wikitext, you can use code like $this->getOutput()->addHtml( $this->msg( 'key-of-message' )->parse() ). This will not have the issue with nested parser calls mentioned above.

OutputPage->showErrorPage()

An error page is shown. The arguments $title and $msg specify keys into $this->msg(), not text. Пример: 

$output->showErrorPage( 'error', 'badarticleerror' );
  • 'error' refers to the text "Ошибка".
  • 'badarticleerror' refers to the text "Это действие не может быть выполнено на данной странице.".

You can also specify message objects or add parameters: 

$output->showErrorPage( 'error', 'badarticleerror', [ 'param1', 'param2' ] );

$messageObject = new Message(...);
...
$output->showErrorPage( 'error', $messageObject );

$titleMessageObject = new Message(...);
$messageObject = new Message(...);
...
$output->showErrorPage( $titleMessageObject, $messageObject );

WebRequest.php

The WebRequest class is used to obtain information from the GET and POST arrays. Using this is recommended over directly accessing the superglobals. The WebRequest object is accessible from extensions by using the RequestContext .

Database.php

MediaWiki has a load of convenience functions and wrappers for interacting with the database, using the \Wikimedia\Rdbms\Database class. It also has an interesting load balancing scheme in place. It's recommended you use these wrappers. Check out Database.php for a complete listing of all the convenience functions, because these docs will only tell you about the non-obvious caveats. См. Руководство:Доступ к базе данных .

User.php

The User class is used to represent users on the system. SpecialPage->getUser() should be used to obtain a User object for the currently logged in user. The use of the global $wgUser is deprecated

Title.php

Title represents the name of a page in the wiki. This is useful because MediaWiki does all sorts of fun escaping and special case logic to page names, so instead of rolling your own convert title to URL function, you create a Title object with your page name, and then use getLocalURL() to get a URL to that page.

To get a title object for your special page from outside of the SpecialPage class, you can use SpecialPage::getTitleFor( 'YourCanonicalSpecialPageName' ). It will give you a localised title in the wiki's language.

Custom special pages

There are various ways to provide your own special pages not bundled within MediaWiki:

  • One method is to install an extension that generates a form to create or edit an article. A list of extensions currently available, can be found at Категория:Расширения со служебными страницами .
  • You can also write an extension which provides your own special page. Writing your own extension requires PHP coding skill and comfort with object oriented design and databases also is helpful. You will also need to know how to use code to create and edit MediaWiki articles. For more information, please see this discussion.
  • You can also display a custom page through JavaScript, in place of the default error message "Unknown special page" (or the "Эта страница намеренно оставлена пустой." message, if using a subpage of Special:BlankPage). In MediaWiki:Common.js, check for wgPageName , then hide the MediaWiki-generated content (just append CSS {visibility:hidden;} ), and inject custom HTML (innerHTML) into the document.getElementById('bodyContent') or document.getElementById('mw_contentholder'). For an example, see meta:User:Krinkle/Tools/Real-Time Recent Changes.

FAQ

Setting an Extension Title

MediaWiki does not set the title of the extension, which is the developer's job. It will look for the name of the extension when Special:Specialpages is called or the special page is loaded. In the function execute( $par ) section, use OutputPage methods to title the extension like: $this->getOutput()->setPageTitle("your title");

The place where the extension can be found (as specified by what is passed into the SpecialPage constructor) is the key--except that it is not capitalized because of getDescription(), the internally used function that finds out the title (or, what they call description) of the special page, strtolower the name. "ThisIsACoolSpecialPage"'s key would be "thisisacoolspecialpage."

Theoretically, getDescription can be overloaded in order to avoid interacting with the message cache but, as the source code states: "Derived classes can override this, but usually it is easier to keep the default behavior. Furthermore, this prevents the MediaWiki namespace from overloading the message, as below.

Localizing the Extension Name

So you've just installed a shiny new MediaWiki extension and realize: "Oh no, my wiki is in French, but the page is showing up as English!" Most people wouldn't care, but it's actually a quite simple task to fix (as long as the developer used the method explained on this page). No noodling around in source code. Let's say the name of the page is DirtyPages and the name comes out to "List of Dirty Pages" but you want it to be (and excuse my poor French) "Liste de Pages Sales". Well, it's as simple as this:

  1. Navigate to MediaWiki:DirtyPages, this page may not exist, but edit it anyway
  2. Insert "Liste de Pages Sales" and save

And voilà (pardon the pun), the change is applied.

This is also useful for customizing the title for your wiki within your language: for instance, the developer called it "List of Dirty Pages" but you don't like that name, so you rename it "List of Pages needing Cleanup". Check out Special:Allmessages to learn more.

Also, if your extension has a large block of text that does change, like a warning, don't directly output the text. Instead, add it to the message cache and when the time comes to output the text in your code, do this: 

$wgOut->addWikiText( $this->msg( 'dirtypageshelp' ) );

Then this message too can be customized at MediaWiki:Dirtypageshelp.

See also Помощь:Системные сообщения .

Restricting page access

Do not display your Special Page on Special:SpecialPages

Sometimes you may want to limit the visibility of your Special Page by removing it from Special:SpecialPages and making it visible to only those users with a particular right. You can do this in the constructor by passing in a $restriction parameter; e.g., “editinterface”, a right only assigned to sysops by default; see the User rights manual for other available user rights. 

function __construct() {
	parent::__construct( 'MyExtension', 'editinterface' ); // restrict to sysops
}

Or you can create your own right in the setup file and assign it to sysops, e.g.: 

"AvailableRights": [
	"myextension-right"
],
"GroupPermissions": {
	"sysop": {
		"myextension-right": true
	}
}

and then call the constructor with your right: 

function __construct() {
	parent::__construct( 'MyExtension', 'myextension-right' );
}

Prevent access to your Special Page

Even if you restrict your page in the constructor, as mentioned above, it will still be viewable directly via the URL, e.g. at Special:MySpecialPage. In order to actually limit access to your SpecialPage you must call $this->checkPermissions() in the execute method.

If you need more fine-grained control over permissions, you can override $this->checkPermissions(), and/or add whatever permissions-checking is required for your extension.

Disabling Special:UserLogin and Special:UserLogout pages

In LocalSettings.php you can use the SpecialPage_initList hook to unset unwanted built-in special pages. See "making a few SpecialPages restricted" if you need conditional unsetting of special pages for example for certain user groups. The general message "You have requested an invalid special page." is shown if users try to access such unset special pages. 

$wgHooks['SpecialPage_initList'][] = function ( &$list ) {
	unset( $list['Userlogout'] );
	unset( $list['Userlogin'] );
	return true;
};

A different approach would be to use the DisabledSpecialPage callback. This approach may be preferred if you're only disabling the special page "temporarily", because the default message in this case would say: "Данная страница была отключена системным администратором." instead of pretending the page does not exist at all. This gives clear hint that the page may be activated at a later time. 

$wgSpecialPages['Userlogout'] = DisabledSpecialPage::getCallback( 'Userlogout' );
$wgSpecialPages['Userlogin'] = DisabledSpecialPage::getCallback( 'Userlogin' );

It is also possible to add custom lengthy explanation of why you're disabling the special page, by giving a message key as the second argument of the callback. To do so first create a system message "MediaWiki:Userlogout-disable-reason" and write all the explanation there. The message will be parsed in a block format. Then in LocalSettings.php add: 

$wgSpecialPages['Userlogout'] = DisabledSpecialPage::getCallback( 'Userlogout', 'Userlogout-disable-reason' );


Adding logs

On MediaWiki, all actions by users on wiki are tracked for transparency and collaboration. See Manual:Logging to Special:Log for how to do it.

Changing the groups on Special:Specialpages

If you're an extension developer, you have to implement the getGroupName() method as described in the Special page group section of this page.

Since MediaWiki 1.21, the special page group can be overridden by editing a system message. This method is not intended to be used by extension developers, but by site admins. The group name must be placed in the specialpages-specialpagegroup-<special page name> message, where <special page name> is the canonical name (in English) of the special page in lowercase. For example, if you want to set the group under which Special:MyLittlePage is displayed on Special:Specialpages to MyLittleGroup, you just have to create MediaWiki:Specialpages-specialpagegroup-mylittlepage with content MyLittleGroup. Special:MyLittlePage will then show up under the group MyLittleGroup, which you can name under MediaWiki:Specialpages-group-mylittlegroup.

If you want to change the group of existing special pages, have a look on Special:SpecialPages&uselang=qqx and use those names instead of "mylittlepage".

Unlisting the page from Special:Specialpages

To remove a special page from the Special:Specialpages altogether, pass a false as a third parameter to the SpecialPage parent constructor, as described in the SpecialPage Constructor section of this page. If you need more complicated logic to determine whether the page should be listed or not, you can also override the isListed() function, but using the constructor parameter is simpler.

Getting a list of special pages and their aliases on a wiki

Simply use the "siteinfo" API module to retrieve the information from the wiki like e.g. /api.php?action=query&meta=siteinfo&siprop=specialpagealiases.

См. также

  • HTMLForm – Tutorial on creating checkboxes, text areas, radio buttons, etc. in special pages
Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Special_pages/ru&oldid=7062448"