Manual:特別ページ

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Manual:Special pages and the translation is 38% complete.

Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎français • ‎polski • ‎português do Brasil • ‎русский • ‎中文 • ‎日本語
Gnome-preferences-other.svg 拡張機能:Manual:Extensions 開発Manual:Developing extensions タグ拡張機能Manual:Tag extensions パーサー関数Manual:Parser functions フックManual:Hooks 特別ページManual:Special pages マニュアル:スキンManual:Skins マジックワードManual:Magic words APIAPI:Extensions Content modelsManual:Page content models
MediaWiki extensions

特別ページは、特定の機能を求められたときにソフトウェアが作成したページです。 例えば特定の外部サイトにひとつ以上リンクがあるページをすべて抽出させることも、利用者が提供したフィードバックをまとめたフォームの作成もできます。 特別ページは固有の名前空間 (特別:) に置かれ、他のページと違って直接、編集することはできません。 DeveloperDevelopers が特別ページを開設することも可能です。 利用者はこれらのページにアクセスでき、すべての特別ページをまとめた一覧は通常は Special:SpecialPages にあります。 特別ページの中には、特別な利用者権限やアクセス権がないと利用できものがあります。 あるいは特別ページの一覧には表示されず、ウィキで内部的に使用されるだけのものもあります。

全般的な情報

MediaWiki に伴うおよそ75件の特別ページはすべてSpecialSomename.phpと呼ばれ、includes/specialsディレクトリに置かれます。 通常、サードパーティ製の特別ページは個別ファイルの属するextensionsディレクトリか、もしくはさらに大きな拡張機能の一部として置かれます。 どの特別ページも includes/SpecialPage.php で定義されているクラス SpecialPage を継承します。 新しい特別ページを作成する際には、その特別ページにアクセスするのに必要な利用者権限を定義する必要があります。 利用者権限の定義により、特に特別ページに表示するか、その他のページの下位に置くことを許可するか定義します。

また特別ページ固有の名称は、ウィキごとに変更できます。 一般形式の「特別:ページ名」の「特別」も「ページ名」も、どちらもカスタマイズできます。 「特別」の仮の名前空間は他言語に翻訳可能です。 翻訳した名前空間の名称はこのウィキに「Special」として、ウィキテキストで{{ns:special}}に記述してください。 特別ページの属名を ID にすると、名称はシステム・メッセージでもサイトの使用言語で定義し直せます。

特別ページにより、入力を許可するものとしないものがあります。 一例としてページの書き出しの場合、ユーザーはSpecial:Export/Sunにより特定のページを定義できます。 複雑な指定を許可する特別ページの場合は、他のパラメーターをURLのクエリ文字列に送って処理します。例:http://www.mediawiki.org/w/index.php?title=Special:Recentchanges&days=3&limit=250 (「最近の更新」のオプションで 最近 3 日間の更新を最大 250 件表示)

  • 特別ページの作成方法は何種類もありますが、公式の拡張機能の大部分が採用する下記の方法に従うよう推奨します。 また新設した特別ページの'specialpage'には必ず著作権ブロックを含めるようお願いします。詳細は$wgExtensionCreditsManual:$wgExtensionCreditsを参照してください。
  • 他の人が作成した特別ページに気づくように、カテゴリ:特別ページの拡張機能に追加するのをお忘れなく。
  • この方法は PHP5 以降で MediaWiki を実行したときのみ有効です。PHPの版は新しくても旧版の MediaWiki をご使用でしたら、アップグレードをお願いします。
  • 特別ページは、$wgOut->allowClickjacking();を適用しない限り、フレーム化できません。


特別ページの基本のテンプレート

一般に、特別ページの拡張機能の要件は、次の3種類のファイルです。

  • MediaWiki の開始時に毎回読み込む、小さな設定ファイル
  • コードの集まりであるファイル
  • 地域化ファイル.

MediaWiki のコーディング規約の定義

  • MyExtension/extension.json - 設定ファイル
  • MyExtension/SpecialMyExtension_body.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",
	"AutoloadClasses": {
		"SpecialMyExtension": "SpecialMyExtension_body.php"
	},
	"SpecialPages": {
		"MyExtension": "SpecialMyExtension"
	},
	"MessagesDirs": {
		"MyExtension": [
			"i18n"
		]
	},
	"manifest_version": 1
}

このファイルで登録する項目には重要なものも任意のものもあります。

  • SpecialMyExtension クラスの保存先
  • 地域化ファイルの保存先
  • 新設した特別ページ名とクラス名

特別ページのファイル

ファイル本体 (MyExtension/SpecialMyExtension_body.php) には必ず特別ページあるいはそれ自体のサブクラスを最低1件、含むこと。 このファイルはその特別ページを誰かが呼び出すたびに自動で読み込まれます。 次の例ではサブクラス SpecialMyExtension を実行します。

最初のパラメーターで特別ページを名付けるため、__construct() コンストラクタは必須。

execute() は特別ページにアクセスがあったときに呼び出される main 関数。 この関数は、関数 SpecialPage::execute() をオーバーライドします。 現在のタイトルの下位ページのコンポーネントである、単体のパラメーター$parを渡します。 例えば誰かがSpecial:MyExtension/blahのリンクをたどると、$parに「blah」が入ります。

ウィキテキストと HTML は$wgOutを介して走らせます。直接、ウィキの UI を操作する間、 'print' 文も 'echo' 文も使用しないでください。

ただし特別ページをアクセスポイントとして利用し、カスタムの XML もしくはバイナリ出力を得ようとする場合は、「特別ページで出力を引き継ぐ」を参照してください。


<?php
class SpecialMyExtension extends SpecialPage {
	function __construct() {
		parent::__construct( 'MyExtension' );
	}

	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->addWikiText( $wikitext );
	}
}

地域化ファイル

翻訳方法はLocalisation#Adding new messagesLocalisation#Adding new messagesを参照してください。

特別ページはすべて、'My Extension'のようにタイトルを定義します。

  • タイトルは拡張機能のページで<title><H1>の要素として、また特別ページでも使われます。
  • 特別ページと拡張機能の説明になっていれば、どんなタイトルでもかまいません。
  • タイトルを定義するのはメッセージで、その構成はキーと値のペアで構成されます。キーも'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."
}

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 <tvar|1>Special:MyExtension</>."
}

ID は頭文字(最初の1文字)から小文字のみで表記していること、ID の文字列をコードで記すには、スペース(空白)に代わってアンダーバー(_)を使うこと。

-summary メッセージは必須ではありません。 親クラスが自動で生成すると特別ページの最上部に表示し、通常はユーザーの手続きを明示的に解説します。 その内容を定義しなければ、ウィキ管理者がそのウィキでカスタマイズするまで実行されません。

別名ファイル

特別ページに別名のページを作り、それを国際化する方法もあります。下記の例で使うファイルは「i18n/MyExtension.i18n.alias.php」です。 特別ページMyExtension別名を登録することで、ドイツ語版では.../Special:My Extension.../Spezial:Meine_Erweiterungからアクセス可能にしました。

extension.jsonに別名を付ける。

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

特別ページi18n/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' ],
];

ここでも ID 中にスペース(空白)を用いる場合は、アンダーバー(_)を代入します。

ページのヘッダーとリンクの処理は、通常のページと同じ規則に従います。

$wgCapitalLinksManual:$wgCapitalLinksが正の場合、小文字を大文字変換し、アンダーバーはスペース(空白)として表示します。

例えば拡張機能を例外なくすべてmy_extensionで定義したと仮定し、上記を'my_extension' => 'My extension'で表現することも可能です。

その場合、英語の連想配列においてSpecialPageを識別する文字列(この例ではMyExtension)は同時に有効なタイトルでもあることに注意します。

あるいはまた、$specialPageAliases['en']['MyExtension']の最初の要素はキーと同一('MyExtension')の必要があります ! さもないと特別ページはページを一覧に出力しません。

特別ページ群

サブクラスでSpecialPage::getGroupName()をオーバーライドすると、その特別ページをSpecial:SpecialPagesでどの群の下位に表示するか指定できます。

    /**
     * 特別ページをSpecial:SpecialPagesで表示する場所を指定するには、親ページをオーバーライドしてください。
     * 規定値の'other'のままでよければ、オーバーライドは不要です。
     * 'media'を指定するとシステム・インターフェース<code>specialpages-group-media</code> を適用します。英語では'Media reports and uploads' (メディアのレポートと読み込み)と訳出します。
     * 
     * @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.

Other Important Files

SpecialPage.php

Constructor

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->addWikiText( 'Hello, World' );

instead of the deprecated $wgOut global variable

SpecialPage->getRequest()

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

$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 special page 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 variablename $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, declare the variable global:

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.phpManual: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.

警告 警告: If your special page is intended to be included in other pages, you should probably not use addWikiText() (or any other function that calls the parser except for message related functions that parse (wfMessage) which are OK to call on modern versions of MediaWiki). Due to a bug in MediaWiki (Bug T18129), an included special page will mess up any inclusion before it on the same including page, showing strings like UNIQ10842e596cbb71da.

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.

workaround #1

Important: these work arounds are only needed if you are making a transcludable special page. Normal special pages do not need these.

As a workaround, you can have your extensions convert Wikitext to HTML using a separate Parser object and then use addHTML(). Example:

$wgOut->addHTML( $this->sandboxParse( "Here's some '''formatted''' text." ) );
# Assuming this is inside the same class as the rest of your special page code
function sandboxParse( $wikiText ) {
	global $wgTitle, $wgUser;
	$myParser = new Parser();
	$myParserOptions = ParserOptions::newFromUser( $wgUser );
	$result = $myParser->parse( $wikiText, $wgTitle, $myParserOptions );
	return $result->getText();
}


workaround #2

I tried the above, and found that the same problem now applied to any <tag>s in the transcluded text. This won't be a problem for a lot of extensions, but the extension I was writing was intended to show wikitext from another page as part of its functionality, so this was a problem.

The process for parsing a page which transcludes a special page seems to be this:

  1. Replace {{Special:MyExtension}} with a UNIQ-QINU marker (because SpecialPage output is expected to be ready-to-output HTML)
  2. Replace any <tag>s with QINU markers as above
  3. Parse everything else from wikitext to HTML
  4. Replace all QINU markers with their respective stored values, in a single pass

The process for parsing a page which transcludes a non-special page, though, is apparently like this:

  1. Replace {{:Normal Article Name}} or {{Template Name}} with contents of transcluded page (because transcluded pages contain unparsed wikitext)
  2. Replace any <tag>s with QINU markers as above
  3. Parse everything else from wikitext to HTML
  4. Replace all QINU markers with their respective stored values, in a single pass

The problem is apparently that in the earlier case, the parsing of the SpecialPage's wiki text is lacking the final QINU decoding step (why?), so all the QINU markers are left undecoded. (This may be a leftover from using the same syntax to invoke transclusion of a wikitext page, which is just pasted straight into the host page's wikitext contents and parsed, as is used to invoke transclusion of a SpecialPage, which must not be parsed at all. Wherever the code is that decides "wait, this is a special page -- replace it with a QINU", it should be doing the extra unstripGeneral before doing the QINU substitution.)

So I just did the following -- after this line:

$htOut = $wgParser->recursiveTagParse( $iText );

...I added these lines (the second one is only because the function definition for the first one recommends it):

$htOut = $wgParser->mStripState->unstripGeneral( $htOut );
$htOut = $wgParser->mStripState->unstripNoWiki( $htOut );

Since I have now documented this, of course, I will now find a tragic flaw with it and feel really stupid... but as long as it seems to be working, I had to note it here. (It is also important to note the problem with work-around #1.) Also, I have only tested this with MediaWiki 1.10.1. The problem still exists under MW 1.14, but this solution may or may not work. --WoozleUser:Woozle 18:26, 9 April 2009 (UTC)

wfMessage()

In most of the real special pages, you will rarely see $wgOut->addWikitext() without wfMessage() popping in.

wfMessage() is a MediaWikiMediaWiki internationalizationinternationalization (i18n) function. See Manual:Messages_APIManual:Messages_API

OutputPage->showErrorPage()

An error page is shown. The arguments $title and $msg specify keys into wfMessage(), not text. An example:

$output->showErrorPage( 'error', 'badarticleerror' );
  • 'error' refers to the text "Error".
  • 'badarticleerror' refers to the text "This action cannot be performed on this page.".

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, since the object does fun stuff like magic_quotes cleaning. The WebRequest object is accessible from extensions by using the RequestContextRequestContext.

WebRequest->getVal($key)

Returns a string that corresponds to the form input with the name $key.

WebRequest->get*()

Returns an int, bool, etc depending on the function called. For checkboxes for example, the function getBool is useful.

WebRequest->wasPosted()

Returns true if a form was posted.

Database.php

MediaWiki has a load of convenience functions and wrappers for interacting with the database. It also has an interesting load balancing scheme in place. It's recommended you use these wrappers. Check out Database.phpManual:Database.php for a complete listing of all the convenience functions, because these docs will only tell you about the non-obvious caveats. See Manual:データベース アクセスManual:Database access.

wfGetDB()

As this name suggests, this function gets you a reference of the database. There is no global that contains a database object.

When you call the function, you should pass it a parameter, the constant DB_MASTER or DB_REPLICA. Generally, you interact with the replica database when you're only performing read operations, and interact with the master when you're writing to the database. It's really easy to do, so do it, even if you only have one database.

User.php

The User class is used to represent users on the system. The global $wgUser represents the currently logged in user, and is usually what you will deal with when manipulating users.

User->isAllowed($right)

Returns true or false depending on whether the user is allowed to do $right.

User->isBlocked()

Returns true if a user is blocked.

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 escapeLocalURL() to get a URL to that page.

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

Title::makeTitle()

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 カテゴリ:特別ページの拡張機能Category:Special page extensions.
  • 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". In MediaWiki:Common.js, check for wgPageNameManual:Interface/JavaScript#mw.config, then hide the MediaWiki-generated content (just appendCSS {visibility:hidden;} ), and inject custom HTML (innerHTML) into the document.getElementById('bodyContent') or document.getElementById('mw_contentholder'). For an example, see w:en:User:Splarka/electrocute.js.

よくある質問

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 (specifically right before the registered wfSpecial*() function is called). In the function execute( $par ) section, use $wgOut to title the extension like: $wgOut->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. Messages can be added at run-time--see MessageCache.php". 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( wfMsg( 'dirtypageshelp' ) );

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

See also Help:System message.

Restricting page access

Do not display your SpecialPage on the Special:SpecialPages page

Sometimes you may want to limit the visibility of your SpecialPage by removing it from the Special:SpecialPages page and making it visible to only a set group of users. 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.:

$wgGroupPermissions['sysop']['myright'] = true;
$wgAvailableRights[] = 'myright';

and then call the constructor with your right:

function __construct() {
	parent::__construct( 'MyExtension', 'myright' );
}

Do not allow url access to your SpecialPage

警告! 警告: Even if you restrict your page in the constructor, as mentioned above, your SpecialPage will still be viewable directly via the url, e.g., Special:MySpecialPage. In order to limit access to your SpecialPage via the url, make sure the following is in your extension’s execute method.
function execute( $par ) {
	// ...
	if ( !$this->userCanExecute( $this->getUser() ) ) {
		$this->displayRestrictionError();
		return;
	}
	// ...
}


Special:UserLogin ならびにSpecial:UserLogout ページの無効化

In LocalSettings.php you can use the SpecialPage_initList hookManual:Hooks/SpecialPage_initList 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;
};


記録の追加

MediaWiki では透明性と共同作業のために、ユーザーの行動をすべて記録します。 その方法は Manual:Logging to Special:LogManual:Logging to Special:Log で解説してあります。

特別ページのグループを変更する

拡張機能の開発者の皆さんは、このページの特別ページのグループの節の説明に従い、getGroupName()方式を実行してください。

MediaWiki 1.21 以降、特別ページのグループはシステムメッセージを編集すると、オーバーライド可能になりました。 ただしサイト管理者が実行する方法であり、拡張機能の開発者向けではありません。 グループ名はspecialpages-specialpagegroup-<special page name>メッセージに配し、特別ページの英語版の正規名称<special page name>は小文字で表記します。 例えばグループ「MyLittleGroup」を作り特別ページで下位ページとして「Special:MyLittlePage」を示したいなら、「MediaWiki:Specialpages-specialpagegroup-mylittlepage」を作成しコンテンツページを「MyLittleGroup」と指定するだけです。 すると「Special:MyLittlePage」は「MyLittleGroup」の下位ページになります。後者の命名は「MediaWiki:Specialpages-group-mylittlegroup」で行います。
既存の特別ページのグループを変更するには、特別ページを参照して前述の「mylittlepage」の部分を書き換えます。

関連項目

  • HTMLForm — チェックボックスやテキストエリア、ラジオボタン他を、特別ページに作る方法