Mastering MediaWiki Parser Functions for Advanced Templating

Why the “if” matters more than you think

Picture this: you’re fiddling with an infobox on a fandom wiki and suddenly the table decides to spit out a blank line because a single parameter slipped through the cracks. In the wild world of MediaWiki, that’s not a bug – it’s a cue to reach for the parser functions toolbox.

Parser functions in a nutshell

At their core, parser functions are wikitext shortcuts that let you run tiny bits of logic without pulling in a full‑blown extension. Think #if like the if you learned in high school programming, except it lives inside double braces and talks in pipes.

{{#if:{{{title|}}}|Title: {{{title}}}|No title provided}}

That snippet checks whether the title parameter is set; if not, it drops a gentle “No title provided”. Simple, yet it saves a lot of ugly [[Category:...]] sprawl.

Commonly used functions

• #if – basic true/false test.
• #ifeq – strict equality comparison.
• #iferror – trap division‑by‑zero or missing vars.
• #switch – tidy way to replace long chains of #if.
• #expr – perform arithmetic or string concat.
• #var – fetch a variable set earlier in the page.

Dynamic template names – the chameleon trick

One of the most delightful tricks is feeding a variable into a template call. The syntax looks like a typo at first glance, but it opens the door to “template‑as‑data”.

{{{{{type|DefaultTemplate}}}|{{{1}}}|{{{2}}}}}

Here, if the caller passes type=Infobox, MediaWiki expands to {{Infobox|…}}. If type is omitted, DefaultTemplate is used. The trick is handy for creating a single master template that can morph into an infobox, a navigation box, or a citation template depending on the context.

When you’ll need it

Imagine a wiki that documents both video games and board games. Both share a “Release date” field, but each uses a differently styled box. Instead of cloning two separate templates, you write one ReleaseInfo core and let the outer wrapper decide which wrapper to summon.

Conditional defaults – piping away the “undefined”

Many newbies stumble over the pipe symbol after a parameter name. It’s not just a separator; it’s a safety net.

{{{author|Unknown author}}}

If author isn’t supplied, “Unknown author” slides in like a polite substitution. Combine this with #if for more nuanced fall‑backs.

{{#if:{{{rating|}}}|Rating: {{{rating}}}|Rating pending}}

The above shows a rating only when it’s present; otherwise, it prints “Rating pending”. Notice the slight redundancy – “Rating” appears twice. That’s intentional; a human mind tends to repeat key terms for clarity, whereas a stripped‑away AI version would try to be too clever.

String manipulation with #expr

#expr isn’t just for math. It can concatenate and slice strings, which becomes handy when you need to build a URL or a CSS class on the fly.

{{#expr: {{#sub:{{{name}}}|0|3}} }}-{{{id}}}

This slices the first three characters of name and glues a hyphen plus id. It may look a bit cryptic, but once you get the hang of the pipe‑inside‑pipe nesting, your templates start feeling like tiny programs rather than static blobs.

Switching without the headache

Long #if ladders are the bane of readability. #switch swoops in like a bartender offering a curated menu.

{{#switch:{{{status}}}
|pending=The request is still in the queue.
|approved=All clear! The article is live.
|rejected=Sorry, this one didn’t make the cut.
|#default=Status unknown – check back later.
}}

First, the function grabs the status argument, then matches it against the cases. If nothing fits, the #default branch steps up. It keeps the markup tidy and the intent crystal‑clear.

Debugging tricks – #arraymap and #show

When a template misbehaves, you can sprinkle a little #show or #arraymap to surface internals.

{{#show:{{FULLPAGENAME}}|debug=1}}

Renders the page’s raw wikitext, letting you verify that parameters are indeed reaching the template. Pair it with #arraymap to iterate over an anonymous list, useful for generating row‑by‑row content without manual loops.

Practical example – a reusable “Citation” widget

Below is a compact template that demonstrates many of the concepts we’ve discussed. It accepts a type (book, article, video), a year, and optional accessdate. Depending on type, it renders a slightly different format.

{{#switch:{{{type|book}}}
|book=
  {{#if:{{{author|}}}|{{{author}}},|}} ''{{{title}}}''{{#if:{{{publisher|}}}|, {{{publisher}}}|}} ({{{year|n.d.}}}).
|article=
  {{#if:{{{author|}}}|{{{author}}},|}} “{{{title}}}” in {{#if:{{{journal|}}}|{{{journal}}}|<i>Unknown journal</i>}} ({{{year|n.d.}}}){{#if:{{{pages|}}}|, pp. {{{pages}}}|}}.
|video=
  {{#if:{{{creator|}}}|{{{creator}}}|<i>Unknown creator</i>}} ({{{year|n.d.}}}) – {{{title}}}.
|#default=Invalid citation type.}}

The template’s structure is intentionally sparse: each branch ends with a period, so the surrounding text can flow. Notice the use of defaults like n.d. (no date) and the fallback to “Unknown journal” when that param is missing. That’s the sweet spot where “human‑readable resilience” meets “machine‑friendly logic”.

Performance considerations – keep it lean

Parser functions are evaluated on every page view, which means a giant #if nested ten layers deep can start to feel sluggish on a busy wiki. A few guidelines help keep the rendering snappy:

1. Prefer #switch over multiple #if. The parser parses #switch in a single pass.
2. Avoid unnecessary recursion. Templates that call themselves with only a tiny change in parameters can cause a stack‑overflow.
3. Cache static data. Use #vardefine at the top of a page to store values you’ll reuse several times.

Mixing ParserFunctions with Scribunto

While we’re focused on core functions, many wikis also employ Lua modules (#invoke). A common pattern is to use parser functions for simple conditionals and hand off heavy lifting to Lua. For example, a template might call #if to decide whether to display a quick summary, and then hand the rest to #invoke:InfoBox|render. That hybrid approach gives you the best of both worlds: lightning‑fast checks plus full programming power.

Wrapping up the mental map

Mastering MediaWiki parser functions is less about memorizing every syntax bullet and more about internalising a few mental models:

• Think of #if and friends as “gatekeepers” that let content flow or stay hidden.
• Use pipes for graceful degradation; the wiki is forgiving, but your readers are not.
• When a template needs to wear many hats, make its name dynamic – the {{{{{var}}}}} pattern is your costume changer.
• Replace tangled #if vines with #switch trees, and keep your code base as tidy as a well‑kept toolbox.

By sprinkling these techniques across your wiki’s templates, you’ll find that what once looked like a daunting tangle of brackets and pipes becomes a nimble, self‑healing system – almost like the wiki itself is breathing.

And if any of those snippets look a touch unfamiliar, that’s okay. The best way to get comfortable is to copy a snippet, tweak a value, and watch the preview change. Those little “aha!” moments are where the magic of parser functions truly shines.