Manual:Special pages/ja

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

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

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

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

特別ページの基本のテンプレート
一般に、特別ページの拡張機能の要件は、次の3種類のファイルです.
 * MediaWiki の開始時に毎回読み込む、小さな設定ファイル
 * コードの集まりであるファイル
 * 地域化ファイル.

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


 * - 設定ファイル
 * - 特別ページのコード
 * - 地域化ファイル

これらのファイルを一括して MediaWiki の  に作った新しいディレクトリに保存します.

特別ページ・ファイルの名前には、拡張機能の名称を対応させる必要があります. ガジェットの拡張機能の例だと  が対応しています. もし作成した拡張機能が複数の特別ページを採用するなら、名前も複数、必要です.

下記のサンプルは特別ページがMyExtensionという名前です.

リストのファイルを作成したら拡張機能を有効にするため、次の定義文をLocalSettings.phpに書き加えます.

設定ファイル
の設定ファイルの例

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


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

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

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

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

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

ただし特別ページを、カスタムの XML またはバイナリ出力を得るためのアクセスポイントとして使用する場合は、 を参照してください.

地域化ファイル

 * 翻訳方法はを参照してください. 

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


 * タイトルは拡張機能のページで と の要素として、また特別ページでも使われます.
 * 特別ページと拡張機能の説明になっていれば、どんなタイトルでもかまいません.
 * タイトルを定義するのはメッセージで、その構成はキーと値のペアで構成されます. キーも も、英文の小文字の必要があります.

に置く地域化ファイルの一例.

にあるメッセージの説明文書.

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

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

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

に別名を付ける.

特別ページ に別名をつける.

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

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

が正の場合、小文字を大文字変換し、アンダーバーはスペース（空白）として表示します.

例えば拡張機能を例外なくすべて で定義したと仮定し、上記を で表現することも可能です.

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

あるいはまた、 の最初の要素はキーと同一（ ）の必要があります ! さもないと特別ページはページを一覧に出力しません.

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

を適用します. 英語では'Media reports and uploads' （メディアのレポートと読み込み）と訳出します. *     * @return string */   function getGroupName { return 'media'; }

よく使われる値は「'login'」「'maintenance'」「'media'」「'other'」「'pagetools'」「'redirects'」「'users'」です. 承認された設定値は Special:AllMessages (specialpages-groupを検索) もしくは Special:SpecialPages?uselang=qqx を開き仮の言語「qqx」を使ってウィキをブラウジング) を開いて、見出しを検索すると確認できます.  インターフェースのメッセージ「'specialpages-group-media'」を使用するには、「'media'」という用語を設定します.

ご利用の特別ページでpreconfigured見出しのどのパターンにも当てはまらない場合は、新しい見出しを地域化ファイルに追加して使用できます. 詳細は地域化ファイルを参照してください. )

地域化ファイルには、MediaWikiと同梱の標準ページグループの一覧があります. 例えば英語のメッセージの一覧は ) に収納してあり、冒頭は で始まります. 自分の特別ページを 配下に分類するには、メッセージは となります.  このキーの値は例えば のように、そのカテゴリ名として表示される文字列となります.

もし自分の特別ページが既存のカテゴリのどれにも当てはまらないと思える場合は、いつでも新規に作成できます. 拡張機能の地域化ファイルを開き、 配列に対応する新しいキーを挿入するだけで処理できます. この例では グループを以下のとおり定義しています.

こうして自分のクラス定義でメソッド の返り値を にしたと仮定し、Special:SpecialPagesをリロードして新しいカテゴリを確認します.

コンストラクター
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:


 * string  Name of the special page, as seen in links and URLs
 * string  User right required, e.g. "block" or "delete"; also see Restricting page access
 * boolean  Whether the page is listed in Special:Specialpages

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

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

instead of the deprecated  global variable

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

instead of the deprecated  global variable

Some special pages can be included from within another page. For example, if you add 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  method after the parent class initialization:

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.

This is the function which your child class should overload. It passes a single parameter, usually referred to cryptically as  (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,  will contain "blah".

ヘルプ ページ
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:

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

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  or  ). If you want to use it somewhere, declare the variable global:

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  (indeed, all of these can be inspected), but there are a few methods you should definitely know about.

Essentially the quick and dirty substitute for. It takes your input and adds it to the buffer: no questions asked. In the below action, if  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.

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.

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

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

workaround #2
I tried the above, and found that the same problem now applied to any 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  with a UNIQ-QINU marker (because SpecialPage output is expected to be ready-to-output HTML)
 * 2) Replace any 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  or  with contents of transcluded page (because transcluded pages contain unparsed wikitext)
 * 2) Replace any 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: ...I added these lines (the second one is only because the function definition for the first one recommends it): 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. -- 18:26, 9 April 2009 (UTC)

In most of the real special pages, you will rarely see  without   popping in.

is a  (i18n) function. See

An error page is shown. The arguments  and   specify keys into wfMessage, not text. An example:


 * '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:

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.

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

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

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  for a complete listing of all the convenience functions, because these docs will only tell you about the non-obvious caveats. See.

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  or. 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  represents the currently logged in user, and is usually what you will deal with when manipulating users.

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

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  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. 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". In MediaWiki:Common.js, check for, then hide the MediaWiki-generated content (just appendCSS  ), and inject custom HTML  into the   or  . 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  function is called). In the function execute( $par ) section, use  to title the extension like:

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, the internally used function that finds out the title (or, what they call description) of the special page,   the name. "ThisIsACoolSpecialPage"'s key would be "thisisacoolspecialpage."

Theoretically,  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  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, 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:

Then this message too can be customized at.

See also Help:System message.

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  parameter; e.g., “editinterface”, a right only assigned to sysops by default; see the User rights manual for other available user rights.

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

and then call the constructor with your 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  in the   method.

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

Special:UserLogin ならびにSpecial:UserLogout ページの無効化
In LocalSettings.php you can use the 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.

記録の追加
MediaWiki では透明性と共同作業のために、ユーザーの行動をすべて記録します. その方法は で解説してあります.

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

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

既存の特別ページのグループを変更するには、特別ページを参照して前述の「mylittlepage」の部分を書き換えます.

関連項目

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