Manual:Tag extensions

Individual projects will often find it useful to extend the built-in wiki markup with additional capabilities, whether simple string processing, or full-blown information retrieval. MediaWiki's parser provides two main methods for extending markup:


 * Tag extensions : Introduce a new pseudo-XML tag, e.g. &lt;foo /&gt;, which injects custom-prepared HTML into the page
 * Parser functions : Provide additional capabilities for handling wiki text using simple brace constructs, e.g.  

Each has different applications and in general, a specific task will be better suited to one than the other. For example, one might use a tag extension to introduce a simple &lt;donation /&gt; tag, which injects a donation form into the page, whereas conditional statements (e.g. the if example above) are better suited to parser functions, which are more convenient to use within other wiki text.

Tag extensions
A simple tag extension consists of a callback function, which is hooked to the parser so that, when the parser runs, it will find and replace all instances of a specific tag, calling the corresponding callback function to render the actual HTML.

Example
A simple example is provided below:

This example registers a hook callback function for the &lt;sample&gt; tag. When this is used in a page, the parser will call the efSampleRender function, passing in three arguments:


 * $input : Input between the &lt;sample&gt; and &lt;/sample&gt; tags, or null if the tag is "closed", i.e. &lt;sample /&gt;
 * $args : Tag arguments, which are entered like HTML tag attributes; this is an associative array indexed by attribute name
 * $parser : The parent parser; more advanced extensions use this to obtain the contextual Title, parse wiki text, expand braces, register link relationships and dependencies, etc.

Gotcha: You'll notice above that the input is escaped using htmlspecialchars</tt> 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.

Attributes
Let's look at another example:

This example dumps the attributes passed to the tag, along with their values. It's quite evident that this allows for flexible specification of new, custom tags. You might, for example, define a tag extension which allows a user to inject a contact form on their user page, using something like &lt;emailform to="User" email="user@foo.com" /&gt;</tt>.

There is a veritable plethora of tag extensions available for MediaWiki, some of which are listed on this site; others can be found via a quick web search. While a number of these are quite specialised for their use case, there are a great deal of well-loved and well-used extensions providing varying degrees of functionality.

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.

Hooks
Your extension can include functions that are called at various steps of the rendering process. Many "hooks" are included in MediaWiki which you can use.

Example : Call a function just before TidyHTML is run on the (mostly rendered) page.

In Parser.php, the appropriate hook is already defined:

In your extension file, add: and your function

Passing attributes to extensions
As of MediaWiki 1.5, the second parameter to the hook function will be an associative array of attribute => value pairs from the extension's opening tag.

In MediaWiki 1.4 and below, you can't pass attributes in the extensions opening tag. You can work around this by using a  element with a class name of your extension to be invisible and contain the attributes. The extension code can then match them from the article content. This example will extract and loop through all the attributes from a specified  class:

You would pass the attributes like this:

Parser functions
Tag hook extensions, as described above, are expected to take unprocessed text and return HTML. There is virtually no integration with the rest of the parser; for example, the output of an extension cannot be used as a template parameter. Expanding templates within extension tags is possible, but must be done manually -- an error-prone process which changes from version to version.

Parser functions, available since 1.7, provide a way to integrate much more closely with templates and other parser features. There is an embryonic parser function feature in 1.6, but using it is not recommmended, due to the differences in API and syntax.
 * Seems to work well in 1.6.8 with the suggested mods as per ParserFunctions

The typical syntax for a parser function is:

Creating a parser function is slightly more complicated than creating a tag hook, because the function name must be a "magic word" -- a kind of keyword that supports aliases and localisation. Below is an example of an extension that creates a parser function.

With this extension enabled,

*

produces:


 * param1 is hello and param2 is hi

As with tag extensions, $parser->disableCache may be used to disable the cache for dynamic extensions.

To return unparsed HTML output instead of wikitext output using a parser function, use: return array($output, 'noparse' => true, 'isHTML' => true);

Here is the documentation for setFunctionHook, copied from the comments in the code in includes/Parser.php:

function setFunctionHook( $id, $callback, $flags = 0 )

Parameters:


 * string $id - The magic word ID
 * mixed $callback - The callback function (and object) to use
 * integer $flags - Optional, set it to the SFH_NO_HASH constant to call the function without "#".

Return value: The old callback function for this name, if any

Create a function, e.g. . The callback function should have the form:

The callback may either return the text result of the function, or an array with the text in element 0, and a number of flags in the other elements. The names of the flags are specified in the keys. Valid flags are:


 * found : The text returned is valid, stop processing the template. This is on by default.
 * nowiki : Wiki markup in the return value should be escaped
 * noparse : Unsafe HTML tags should not be stripped, etc.
 * noargs : Don't replace triple-brace arguments in the return value
 * isHTML : The returned text is HTML, armour it against wikitext transformation

The ParserFunctions extension is a well-known collection of parser functions.

Naming
When choosing a name without a hash character (number sign, "#"), note that transclusion of a page with a name starting with that function name followed by a colon is no longer possible. In particular, avoid function names equal to a namespace name. In the case that interwiki transclusion is enabled, also avoid function names equal to an interwiki prefix.

Publishing your extensions

 * 1) Give the code and documentation on a page in the Extension namespace and put it in  Category:Extensions.
 * 2) Notify the mediawiki-l mailing list.