Extensions FAQ

How do I enable an extension?
Copy the extension PHP file to your extensions folder and add a require_once( "extensions/FILENAME" ); statement to your LocalSettings.php, with FILENAME being the filename of your extension, such as Extension.php.

See also Manual:Extensions

How do I write my own extension?
See Manual:Extensions.

How do I disable caching for pages using my extension?
The extension purgePage can also be used to perform the steps listed below, it works for MediaWiki 1.3 - 1.5. For MediaWiki 1.3, include the following code in your extension:

For MediaWiki 1.4, use this (won't necessarily work in all cases):

Note: The above doesn't work in all cases. Using the same logic but with different code the following lines work much better. $ts = mktime; $now = gmdate("YmdHis", $ts + 120); $ns = $wgTitle->getNamespace; $ti = wfStrencode($wgTitle->getDBkey); $sql = "UPDATE cur SET cur_touched='$now' WHERE cur_namespace=$ns AND cur_title='$ti'"; wfQuery($sql, DB_WRITE, ""); For MediaWiki 1.4 the following also works (possibly better than the above method):

In MediaWiki 1.5beta5, a more reliable interface was introduced. Your parser hook function may take a parser object as a third parameter, by reference. Use the following code: Note: on MediaWiki version 1.5.8 any of the above didn't work. You can see the following code functioning properly here. I had to use the following code in the second function of the extension (not the "setHook" function):

WARNING: In version 1.6 and many early versions of 1.7, it is impossible for extensions to prevent pages from being cached when edits are submitted. This is not expected behavior, see 5683. There are a number of ways to work around this issue:
 * Install the DisableCache hack. This is the most elegant solution, but has not been thoroughly tested.
 * Run action=purge after submitting edits. This is the safest choice, but may not be feasible in large wikis.
 * Disable caching site-wide. This will sharply increase the amount of work that your server will have to perform.  To disable all caching, put the following code in LocalSettings.php:

Recent versions
In MediaWiki 1.7.0 and upwards, the following should be sufficient:



where  is the reference to the parent parser that is passed as a third parameter to parser hook extensions.

Special pages
When rendering output that will not be subject to parser cache, such as on a special page

where $text is the wikitext to be parsed.

Parser hooks
Parser hook functions are passed a reference to the parser object and should use this to parse wikitext.

Parser::recursiveTagParse 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 $text, so you can nest extension tags. An approach that does not have these advantages would be:

The fourth and fifth parameters to Parser::parse are $lineStart and $clearState</tt>; these dictate how the parser behaves. $lineStart</tt>, when true, indicates that the wikitext is to be treated as starting on a new line (use this when dealing with blocks, or handling lists, etc.). $clearState</tt>, when true, indicates that the parser should clear internal state information; in most cases, this should be false.

Note that Parser::parse</tt> returns a ParserOutput object, not raw HTML, as in the example above.

In cases where this does not work (often due to order of operations, nesting or other hook confusion), use a cloned copy of the parser object:

How do I enable searching in my extension's output (dynamic content)?
You can't. Dynamic content can not be included in a static index.

How can I avoid modification of my extension's HTML output?
The current extension code assumes parser hook extensions will produce inline material and they are inserted before the final block-level rendering stages (see 8997).

One way to work around this is to make your extension's parser hook function output a marker, instead of the actual result, and then replace that marker with the actual result in a handler function registered for the ParserAfterTidy hook.

Alternatively, instead of outputting a marker, it would also be possible to output the result in an armored form (e.g. Base64-Encoded), and unarmor (decode) it in the ParserAfterTidy handler.

How can I pass XML-style parameters in my extension tag?
This is supported from MediaWiki 1.5. Accept a second parameter on your hook function, which will be an associative array of attribute => value pairs.

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
 * In version 1.4x you can use a div 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 div class:


 * Addition/alternative to the 1.4x approach

As the above script didn't worked out a 100%, I developed something on me own, based on the above solution. I put the div inside of the tags of my extension, so a different set of arguments can be passed to the extension on every use in one article. The var $input is the text between the extension tags, passed to the extension function.

Example:

name="Andreas" Other stuff, for the extension to process

Code:

Extensions and Templates
If template parameters are used inside extension tags (e.g. " is passed directly to the extension and not transformed into the correct value specified when the template was called.  This is because extensions are parsed before templates in the parser.  See, bug 2257 for more info and possible patches.

A workaround for this issue is to create a new parser function which expands template variables and then creates the extension code. For example to call the  extension with template parameters, you would create a new parser function like this:

Then you would call the function on a page like this:

"NaodW..." or "UNIQ..."
In previous version of MediaWiki, another problem with templates and extensions was the appearance of "NaodW..." or "UNIQ..." strings in the template output. MediaWiki 1.5(.1) has problems with some PHP versions which causes that output. You should upgrade to MediaWiki 1.5.2 or later.

How can I determine in my extension, if an article is protected or not?
Use the Title class and the isProtected method, e.g.

What permissions do I apply to the extensions folder?
All the scripts in the /wiki structure need to be readable and executable by the user that PHP runs as. All perms are usually 755 and owner/group being that user. The LocalSettings.php file is created by the script on setup and so will be an example to set the rest by.

How do I get my extension to show up on Special:Version?
In order for your extension to be displayed on the Special:Version page in MediaWiki, you must assign extension credits within your PHP code.

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

An example extension credit is:

Replace 'validextensionclass' with one of the following:
 * 'specialpage' -- reserved for additions to Mediawiki Special Pages;
 * 'parserhook' -- used if your extension modifies, complements, or replaces the parser functions in MediaWiki;
 * 'variable' -- extension that add multiple functionality to MediaWiki;
 * 'other' -- all other extensions.

Note: If the extension falls into multiple classes, duplicate the credits for each class (or use a function/template/whatever where only the class changes).