Chapter 11 Extended MediaWiki syntax
There's a variety of other syntax, available through extensions, that can be used for specific purposes: displaying specialized content, handling logic, and displaying page elements such as tabs and footnotes. We'll get to some of it in this chapter.
ParserFunctions
Likely the most popular MediaWiki extension is the ParserFunctions extension. As you may be able to guess from its name, ParserFunctions defines a collection of parser functions (see here for an explanation of those). The functions it defines are useful in a variety of circumstances. ParserFunctions includes all the code for what used to be a separate extension, StringFunctions
. The original ParserFunctions functions are all programmatic in nature: there's #if, the most important of them, which does conditional display, #expr, which evaluates mathematical expressions, and others along similar lines; the full listing is below. The functions that came from StringFunctions all do typical string-manipulation actions, like getting substrings, and replacing certain substrings with others.
In practice, almost all of the usages of functions defined by ParserFunctions are in templates, because that's the one case where you don't know in advance what all the values passed in will be. That's why most of the examples later on for ParserFunctions functions take place within the context of a template, with passed-in parameters.
ParserFunctions comes bundled in with the downloadable version of MediaWiki. But why, given that it's so popular, isn't its functionality directly a part of core MediaWiki? That's because ParserFunctions is a bit of a hack. Functions like #if, for all their helpfulness, can be cumbersome to use, and you only need to look at the code for some of the templates in Wikipedia to see how such functions can quickly turn wikitext into an unreadable mess of curly braces. Here's a small example, from the English Wikipedia's “Infobox settlement” template:
{{#ifeq:{{{parts_style|}}} | para | <b>{{{parts|}}} {{#if:{{both | {{{parts|}}} | {{{p1|}}}}} | : |}}</b> {{comma separated entries | {{{p1|}}} | {{{p2|}}} | {{{p3|}}} | {{{p4|}}} | {{{p5|}}} | {{{p6|}}} | {{{p7|}}} | {{{p8|}}} | {{{p9|}}}
It goes on like that for a while.
Fortunately, a better solution exists: the Scribunto extension (here), which lets you use a real scripting language – Lua – to do text processing, complete with "for" loops and the like.
Nevertheless, ParserFunctions is still in widespread use, even on Wikipedia. (The “Infobox settlement” template, for example, now makes heavy use of Lua, but that crazy-looking mass of wikitext is still there, for whatever reason.) Below is the listing of the original functions it defines, along with a description of each.
- #expr – displays the result of a mathematical or logical expression.
Example: {{#expr:2 + 3}} - #if – displays different strings depending on whether some value is blank.
Example:{{#if:{{{height|}}}|The height is {{{height|}}}.|No height entered.}} - #ifeq – displays different strings depending on whether two values are equal.
- #iferror – displays different strings depending on whether a call to another such function returned an error.
- #ifexpr – displays different strings depending on whether a mathematical expression is correct.
- #ifexist – displays different strings depending on whether a given page exists.
- #rel2abs – displays a page name, based on a directory-like view of subpages.
- #switch – displays different strings depending on some specific value (there can be multiple options).
Example:{{#switch: {{{Season|}}} | Summer = How nice, it's summer! | Winter = Brr, it's winter! | It's some other season! }} - #time – displays a specific time, in a specified format.
- #timel – displays the current local time, in a specified format.
- #titleparts – displays one or more parts of a page name, based on splitting up the page by slashes.
Example: {{#titleparts: A/B/C/D/E | 2 | 3}}(returns “C/D” – call returns 2 segments, starting at segment #3)
And here are the ParserFunctions functions that came from StringFunctions:
- #len – shows the length of a given string.
Example:{{#ifexpr: {{#len: {{{Zip code|}}} }} = 5 | The zip code is {{{Zip code|}}}. | The zip code ({{{Zip code|}}}) should be 5 characters long.}} - #pos – finds the numerical character position of one string within another.
- #rpos – similar, but finds the last occurrence of a string.
- #sub – shows the substring of a string, given a start and end location.
- #pad – pads out a string to a certain length, using a character or longer string as padding.
- #replace – shows a string that has had a substring replaced with another string.
- #explode – shows a substring, based on splitting up a string by a delimiter.
Example:The third name in your list is {{#explode:{{{List of names|}}}|,|3}}.
You can read more about ParserFunctions, including many additional examples, here:
Displaying code
You may want to display source code in some programming or markup language on a wiki page, if it's, say, part of a software-related wiki. SyntaxHighlight is the recommended extension for doing that. The extension defines the tag <syntaxhighlight>, which takes in the parameter lang=, which can hold any of over 100 language names, and can then display any set of code. Here's one example call:
<syntaxhighlight lang="java">System.out.println( "Bonjour, monde!" );</syntaxhighlight>
And here is the resulting output:
<syntaxhighlight> can take in some other parameters, which modify the display; these are only rarely used, but here are some of them:
- line – adds a line number at the beginning of each line.
- start= – if line is used, sets the line number for the first line (by default it's 1).
- highlight= – specifies a line to highlight.
- enclose= – specifies the HTML tag used to enclose the entire text. By default it's "pre", but it can also be "div" or "none". Using "div" allows for line wrapping, which is helpful when there are long lines of code.
See the SyntaxHighlight homepage for more information, including the full set of languages allowed:
Displaying math
The Math extension lets you display mathematical formulas on the page in a nicely-formatted way, by placing them within a <math> tag. You can see more information here:
Cite
The Cite extension should be well-known to anyone who has read Wikipedia – it's the extension that lets users create footnotes. It's not used often outside of Wikipedia and other Wikimedia sites, but it can, and probably should, be used more often, because providing citations for facts is always a good idea. To add a footnote after a statement on a page, you can add something like the following afterward:
<ref name="USA Today interview">[http://usatoday.com/1234567.html Interview with a Screen Legend], Dana Douglas, ''USA Today'', January 1, 1980. Page retrieved February 2, 2021.</ref>
The citation style is up to you, and you can use a template to set the formatting; that's how it's often done on Wikipedia, using templates like “cite news” and “cite web”. On Wikipedia, you could do, in place of the former,
<ref name="USA Today interview">{{cite news |url=http://usatoday.com/1234567.html |title=Interview with a Screen Legend |first=Dana |last=Douglas |work=USA Today |date=January 1, 1980 |accessed=February 2, 2021}}</ref>
This will guarantee a consistent display of citations.
The “name=” attribute within the <ref> tag is optional – it's useful if you cite the same source more than once. If that happens, every additional citation can simply look like this:
<ref name="USA Today interview" />
Finally, at the bottom of the page, you need the following tag to display the full set of footnotes:
<references />
The English Wikipedia has a “{{Reflist}}” template that displays this tag, and applies some custom formatting around it.
Header Tabs
Header Tabs is a cool extension that lets you place tabs within a wiki page (separate from, and below, the editing-based tabs provided by the skin), thus letting you break up the content of what might otherwise be overly-long pages. It's fairly limited: it can only create one set of tabs on a page, with no sub-tabs. Still, that by itself is enough to make pages more readable in a variety of circumstances.
To create a tab with Header Tabs, just print the tab name as a top-level section header, i.e. with one '=', like this:
=Tab name=
This takes advantage of the fact that top-level headers are usually unused; two equals signs ('==') and higher are recommended for regular page headers in almost all cases.
Here's an example of the display of tabs, for a page about an athlete:
This display would just require having lines like “=Biography=”, “=Statistics=”, etc. within the wikitext.
Even if you have Header Tabs installed, such headers won't automatically get turned into tabs unless you do one of two things. The first option is to place the tag <headertabs /> somewhere below the set of tabs for the page; wherever it goes marks the end of the contents of the last tab, and everything below the <headertabs /> will show up below the tabs structure.
The other option is to designate one or more namespaces as automatically getting tabs, so that headers with a single equals sign around them will get turned into tabs, without the need for a <headertabs /> tag. You can do this by adding to the global variable $wgHeaderTabsAutomaticNamespaces, within LocalSettings.php. So to make tabs automatically show up for every page in the main namespace, you would add the following line, below the inclusion of Header Tabs:
$wgHeaderTabsAutomaticNamespaces[] = NS_MAIN;
(If you don't know PHP, this line adds the value “NS_MAIN” to the array of values that $wgHeaderTabsAutomaticNamespaces already held.)
This approach is certainly more convenient; its downside is that you can't have a section of the page below the tabs area – everything from the last tab name down to the end will become part of the last tab's contents. (Although you can still manually insert a <headertabs /> tag in the right place to get around this problem.)
In either case, you also need to have at least two such headers on a page for tabs to show up – unless you add "$wgHeaderTabsRenderSingleTab = true;" to LocalSettings.php.
Tabs are useful for a variety of purposes. They're often in structured pages, defined by templates and editable with forms (using Page Forms – chapter 17). The structured, data-centric nature of such pages makes splitting them into tabs a natural fit. In this case, it makes sense to have the set of tabs be the same for the page and for the form.
There other customizations you can do, also within LocalSettings.php, to modify some of the other aspects of Header Tabs. By default, every click on a tab adds another page to the browser history, so that hitting the "back" button will bring you back to the previous tab you were on. You can disable this behavior, so that tabs won't show up in the browser history, by adding the following:
$wgHeaderTabsUseHistory = false;
Every tab also gets an "edit" link that shows up on the right-hand side. You can remove this link by adding the following:
$wgHeaderTabsEditTabLink= false;
Header Tabs also provides a parser function, #switchtablink, which produces a link to a specific tab, from within either the page on which the tab is located or another page. It is called in the following format:
{{#switchtablink:Tab name|Link text|Page name}}
If the tab is on the same page as the link, only the first two parameters are needed; if it's called from another page, the third parameter is needed as well.
More information about Header Tabs can be found at:
RegularTooltips
The RegularTooltips extension lets you insert tooltips
, i.e. small windows that display additional text when you hover over or click on some icon or text. In the case of RegularTooltips, it happens on hover, and the hovered-over element can be either a piece of text, a standard question mark icon or a custom image/icon. To display a question mark icon with associated text, call something like the following:
{{#info-tooltip: ...Text goes here... }}
For more information on RegularTooltips, see: