Manual:Tag extensions/ja

単純な文字列処理でも本格的な情報検索でも、追加の機能を加えて組み込みウィキマークアップを拡張すると、個々のプロジェクトで有効な場合があります. タグ拡張機能を使用すると、ユーザーはそのような新しいカスタムタグを作成できます. たとえば、タグ拡張を使用して単純な タグを導入すると、寄付フォームがページに挿入されます. 拡張機能は、パーサー関数やハックと共に、MediaWikiの機能を変更または強化する最も効果的な方法です. 拡張機能に関する作業を始める前に、あなたがやろうとしていることを既に他の誰かがつくっていないかを確認するため拡張機能一覧をチェックするようにしてください.

単純なタグ拡張は、パーサーにフックされるコールバック関数で構成されています. そのため、パーサーが実行されると特定のタグに関するインスタンスがすべて検索・置換され、対応するコールバック関数が呼び出されて実際のHTMLがレンダリングされます.

例
In extension.json, set up the hooks:

And add the hook into a PHP file

この例では  タグのコールバック関数を登録します. ユーザーがこのタグを  のようにしてページに書くと、パーサーは   関数を呼び出し、4つの引数を引き渡します.


 * $input :  タグと   タグとの間に記された入力. あるいは、タグが閉じている場合、つまり   であった場合は null
 * $args : HTMLタグ属性のように入力されたタグの引数. 属性名をキーとする連想配列.
 * $parser : 上位パーサー（パーサーオブジェクト）. より高度な拡張機能はこれを使ってコンテキストタイトルを取得し、ウィキテキストを解析し、括弧を展開し、リンク関係と依存関係を登録します.
 * $frame : 上位フレーム（PPFrameオブジェクト）.  $parser と一緒に用いられ、拡張機能が呼び出されたコンテキストに関するより完全な情報をパーサーに提供します.

より複雑な例については、タグ拡張の例を参照してください

属性
別の例を見てみましょう:

この例ではタグに渡された属性の名前と値を出力します. こうして新たなカスタムタグを柔軟に指定できることは明らかです. 例えば、 のように、ユーザーが自分のユーザーページに連絡先フォームを挿入できるようにするタグ拡張機能を定義することができます.

Mediawikiには非常にたくさんの拡張機能があり、その一部はこのサイトに掲載されています. その他の拡張機能も簡易ウェブ検索で見つけることができます. これらの多くは特定の利用場面に特化したものですが、よく好まれよく利用されているたくさんの拡張機能があります. それらの機能の程度もさまざまです.

規約
拡張機能の一般的な設計と設定については を参照してください.

拡張機能の公開

 * 1) Create a new page on this wiki named Extension: with information on your extension, how to install it, and screenshots of it in use. A convenient template has been created to hold this information called . See the template page for more information. You should also add as much detail as possible to the body of the page, and it is wise to check back fairly regularly to respond to user questions on the associated talk page. Also, make sure the page belongs to.
 * 2) Extensions that create new hooks within the extension code should register them on extension hook registry.
 * 1) Notify the mediawiki-l mailing list.

See also publishing your extension.

セキュリティ上の問題
You'll notice above that the input in the examples above is escaped using  before being returned. It is vital that all user input is treated in this manner before echoing it back to the clients, to avoid introducing vectors for arbitrary HTML injection, which can lead to cross-site scripting vulnerabilities.

モジュールの読み込み
The right way to add modules for your extension is to attach them to the ParserOutput rather than to $wgOut. The module list will then be automatically taken from the ParserOutput object and added to $wgOut even when the page rendering is pre-cached. If you are directly adding the modules to $wgOut they might not be cached in the parser output.

Timing and extensions
If you change the code for an extension, all pages that use the extension will, theoretically, immediately reflect the results of new code. Technically speaking, this means your code is executed each and every time a page containing the extension is rendered.

In practice, this is often not the case, due to page caching - either by the MediaWiki software, the browser or by an intermediary proxy or firewall.

To bypass MediaWiki's parser cache and ensure a new version of the page is generated, click on edit, replace "action=edit" in the URL shown in the address bar of your browser by "action=purge" and submit the new URL. The page and all templates it references will be regenerated, ignoring all cached data. The purge action is needed if the main page itself is not modified, but the way it must be rendered has changed (the extension was modified, or only a referenced template was modified).

If this is not sufficient to get you a fresh copy of the page, you can normally bypass intermediary caches by adding '&rand=somerandomtext' to the end of the above URL. Make sure 'somerandomtext' is different every time.

拡張機能を使用するページのキャッシュの無効化
Since MediaWiki 1.5, the parser is passed as the third parameter to an extension. This parser can be used to invalidate the cache like this:

他ページの編集時にページを再生成
Maybe you don't want to disable caching entirely, you just want the page to be regenerated whenever another page is edited, similar to the way that template transclusions are handled. This can be done using the parser object that is passed to your hook function. The following method was lifted from and appears to work for this purpose.

キャッシュ動作の微調整
You can use fine grained caching for your extension by using cache keys to differentiate between different versions of your extension output. While rendering you can add cache keys for every feature by adding an addExtraKey method to your hook function, e.g.:

However, modifying $parser->getOptions during parse means that the extra option keys aren't included when trying to get a cached page, only when rendering a page to go into cache, so you can use the PageRenderingHash hook to set extra options. PageRenderingHash is run both when putting a page into cache, and getting it out, so its important to only add new keys to the hash if they're not already there. 例:

Some important notes on this:

! is used a separator for different rendering options Be warned that addExtraKey does not tell the parser cache that the extra key is in use, and thus can easily result in breaking the cache if you are not careful.
 * Using "!setting1=$value" instead of just "!$value" in the confstr ensures that the parser cache does not become messed up if different extensions are installed or their load order changes.
 * Some people use  instead of.

バージョン1.16以降
Parser hook functions are passed a reference to the parser object and a frame object; these should be used to parse wikitext.

has been around since version 1.8. Its advantages include simplicity (it takes just one argument and returns a string) and the fact that it parses extension tags in, so you can nest extension tags.

The second parameter to recursiveTagParse,, is an optional argument introduced in MW 1.16 alpha (r55682).

In other words, content such as  will be recognized and converted into the appropriate value. Although this unlikely to be the desired behavior, this was the only option available before MW 1.16.
 * If  is provided (using the value of   passed to your extension), then any template parameters in   will be expanded.
 * If  is not provided (e.g.,  ), or if   is set to false, then template parameters will not be expanded;   will not be altered.

However, one step of parsing that is still skipped for tags, even when using recursiveTagParse, is Parser::preSaveTransform. preSaveTransform is the first step of parsing, responsible for making permanent changes to the about-to-be saved wikitext, such as:

(, ~ ,  )  Without this step, shorthand links such as Help:Contents are considered to be invalid, and are left in their wikitext form when parsed.
 * Converting signatures
 * Expanding link labels, also known as the pipe-trick (e.g., changing Help:Contents into Contents ).
 * Expanding templates.

The original call to preSaveTransform intentionally skips such conversions within all extension tags. If you need pre save transform to be done, you should consider using a parser function instead. All tag extensions can also be called as a parser function using  which will have pre save transform applied.

バージョン1.5以降
Since MediaWiki 1.5, XML-style parameters (tag attributes) are supported. The parameters are passed as the second parameter to the hook function, as an associative array. The value strings have already had HTML character entities decoded for you, so if you emit them back to HTML, don't forget to use, to avoid the risk of HTML injection.

拡張機能のHTML出力による変更の回避
The return value of a tag extension is considered almost parsed text, which means its not treated as pure html, but still modified slightly. There are two main things that are done to the output of a tag extension (Along with a couple other minor things):

Strip markers are certain items which are inserted at various stages of processing wikitext to act as a marker to re-insert removed content at a later time. This is not something extensions usually need to worry about. This can sometimes be an issue in some extensions.
 * Replace strip markers.
 * which turns *'s into lists, and turns any line starting with a leading space into a &lt;pre&gt; among other things.

Tag extensions also support returning an array instead of just a string (Much like parser functions) in order to change how the return value is interpreted. The 0th value of the array must be the HTML. The "markerType" key can be set to  in order to stop further parsing. Doing something like  would ensure that the $html value is not further modified and treated as just plain html.

Special:Versionへの拡張機能の表示
In order for your extension to be displayed on the MediaWiki Special:Version page, you must assign extension credits within the PHP code.

To do this, add a  variable as the first executable line of code before the hook line or function definition.

An example extension credit is:

Replace  with one of the following (unless your extension falls under multiple classes&mdash;then create a credit for each class):


 * 'specialpage'&mdash;reserved for additions to MediaWiki Special Pages;
 * 'parserhook'&mdash;used if your extension modifies, complements, or replaces the parser functions in MediaWiki;
 * 'variable'&mdash;extension that add multiple functionality to MediaWiki;
 * 'media'&mdash;used if your extension is a media handler of some sort
 * 'other'&mdash;all other extensions.

The  is the name of an interface/i18n message that describes your extension that will need to be defined in your extension's i18n.php file. If you omit this field, the  field will be used instead.

Retrieving the tag name inside of the callback
Suppose you have several tags  and   that share the same callback, and inside the callback function, you want to obtain the name of the tag that invoked the callback.

The short answer is: the tag name ( or  ) is not present in any of the callback's arguments. But you can work around this by dynamically constructing a separate callback for each tag:

関連項目

 * – List of special tag/variables like,  , ...
 * – List of parser tags in use on Wikimedia wikis.