HowItWorks:MediaWiki

Explains how things actually work — part of our technology dissections collection.

MediaWiki is the free, open-source wiki engine behind Wikipedia, Wikidata — and this very site.

Components and interactions

MediaWiki in action

Page view

A page view passes through these stages:

1. The request arrives. The browser asks for /wiki/Main_Page. The web server hands it to PHP-FPM, which boots MediaWiki through index.php: security checks, default settings, then the site's own LocalSettings.php.
2. The title is resolved. MediaWiki works out which page is meant (namespace, redirects, aliases) and checks the reader's permissions.
3. The wikitext is loaded from the database — always the stored source, never a pre-rendered copy.
4. The preprocessor expands. Template calls ({{...}}), parser functions and magic words are resolved into expanded wikitext. This stage walks a tree and can skip dead branches, such as the unused cases of a {{#switch:…}}.
5. The parser converts to HTML. Wikitext syntax becomes HTML elements; the Sanitizer class scrubs any raw HTML for unsafe content.
6. The skin frames the page. The content HTML is wrapped in the skin's chrome (sidebar, header, footer) together with CSS and JavaScript delivered by ResourceLoader.
7. The page is served. A repeat view can skip stages 4–6 entirely if the rendered output is still in a cache.

Key design decisions

• Content stays in wikitext, not HTML.
• The parser is a stability contract. Hundreds of millions of pages depend on its output, so it changes slowly and conservatively. The price: wikitext grew organically, is complex, and cannot be described by a formal grammar.
• Templates are DRY for wikis. One source of truth for repeated boilerplate (navigation boxes, banners, infoboxes), expanded at read time.
  • The preprocessor rewrite (MediaWiki 1.12, 2009) exists precisely because template-heavy pages had become a parsing bottleneck.
• Skins separate content from presentation. The same content HTML renders under any skin without re-parsing.
• Extensions plug in; the core stays stable. Hooks let third-party code run before, after or instead of core behaviour — the citation and embed systems on this very site are extensions, not forks.
• Caching is the price of PHP. Every request boots PHP, so MediaWiki layers caches: reverse proxies serve whole pages, an object cache avoids re-parsing, an opcode cache skips recompiling PHP. The tradeoff is cache invalidation (next section).

Try it yourself

All commands below were verified to work at the time of writing (2026-08) against this wiki (MediaWiki 1.46.0).

# Which version is this wiki running?
curl -s "https://wikibase.ronzz.org/api.php?action=query&meta=siteinfo&siprop=general&format=json" | grep -o '"generator":"[^"]*"'

Output:

"generator":"MediaWiki 1.46.0"

# See the parser's HTML output for a page (the raw pipeline result, before the skin)
curl -s "https://wikibase.ronzz.org/api.php?action=parse&page=Main_Page&format=json" | grep -o "<p><strong>[^<]*"

Output:

<p><strong>Hi, welcome to Ronzz.org's own wikibase.

See the preprocessor stage directly: Visit Special:ExpandTemplates

• paste {{HowItWorks}} into the input box and click "Expand" —
• You see the expanded wikitext before the parser turns it into HTML.

Further reading

• Manual:MediaWiki architecture — the canonical architecture deep-dive (also a chapter of the Architecture of Open Source Applications book)
• Manual:Contents — the technical manual of the software
• MediaWiki — the software project page

The reference layer for this site's own data lives in the SPARQL cheatsheet: the sheet is the syntax, this page is the machinery.