HowItWorks:MediaWiki

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

MediaWiki is the free, open-source wiki engine behind thousands of wiki instances, such as Wikipedia, Wikidata — and this very site: RonzzWikiBase [5].

What is a wiki engine?

A wiki engine is the software that runs a wiki: a website whose pages anyone can edit from their browser, with every change saved and reversible. The engine is the machinery behind that promise. It stores the pages in a database, shows the edit form, records each save as a new revision, and turns the stored text into the page the reader sees.

MediaWiki is one such engine — written in PHP, backed by a relational database (MySQL or MariaDB by default) [1]. DokuWiki, MoinMoin and TiddlyWiki are other examples of the same idea.

MediaWiki's origin sets it apart: it was built from the start to be Wikipedia's software [1]. Where a content-management system (CMS) usually has an editorial workflow and per-page access control, a wiki engine trusts its community instead. MediaWiki deliberately skips the usual CMS features, and puts its effort into the tools a live wiki needs:

Wiki engine (MediaWiki)	Typical CMS
no publication workflow — every edit is live immediately	editorial workflow and review [1]
no per-page access control (ACLs)	fine-grained roles and permissions [1]
built-in tools against spam and vandalism	focus on controlled publishing [1]

The result is a system optimised for a very specific job: a community creating and curating knowledge on an open platform, at enormous scale [1].

Components and interactions

The diagram below is the map for the rest of this page. It shows MediaWiki's main building blocks — entry points, storage, the parser, caching — and how a request moves between them.

MediaWiki in action

Everything MediaWiki does reduces to two flows: reading a page and writing one. Both go through the same machinery.

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 — MediaWiki stores the source text, not the rendered page [1].
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 [1].
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 [1][3].
7. The page is served. A repeat view can skip stages 4–6 entirely if the rendered output is still in a cache [1].

Page edit

An edit is the mirror image of a view: instead of reading a revision, it writes a new one.

1. The editor opens the page. Clicking "Edit" sends the stored wikitext — the source, not the rendered HTML — to the browser in a text box [1][4].
2. The editor changes the text. "Show preview" runs the new wikitext through the parser and shows the result without saving; "Show changes" shows a diff against the current version [4]. An optional edit summary (up to 500 characters) describing the change is saved with the edit [4].
3. The save is checked. MediaWiki compares the submitted text with the revision the editor started from. If someone else saved in between, the editor gets the edit-conflict screen and merges the two versions [6]. Changes to unrelated parts of the page are merged automatically [6].
4. The revision is stored. The new text becomes a new revision: author, timestamp and summary are recorded, and the page's "latest" pointer moves to it [1]. The old revision stays — that is what makes history, diffs and undo possible.
5. The change spreads. The edit appears in the page history and in RecentChanges, and the page's cached output is discarded [1].

Key design decisions

Six choices explain why MediaWiki behaves the way it does. None is obvious; each trades a little simplicity for a lot of power.

Content stays in wikitext, not HTML

MediaWiki stores pages as wikitext — a lightweight markup — and renders it to HTML only when a page is displayed [1]. Editors edit the source, and the source is what is stored.

Why does that matter?

• Editing stays easy. Wikitext is plain text a human can read and write; raw HTML is verbose and error-prone [1].
• The wiki stays re-renderable. Because the source is kept, the whole wiki can be re-parsed when the parser improves, a skin changes or a template is fixed. Nothing is ever frozen as HTML [1].
• History stays cheap. Every revision is stored as text, so any old version can be re-parsed and re-displayed — that is what makes diffs, rollback and undo work [1].

The parser is a stability contract

The parser turns wikitext into HTML, and MediaWiki treats its output as a promise: hundreds of millions of pages depend on it, so it changes slowly and conservatively [1].

The price is that wikitext never received a formal specification. It grew organically from the markup of an earlier engine, UseModWiki, so it cannot be described by a formal grammar — the unofficial spec is "whatever the parser spits out, plus a few hundred test cases" [1].

The clever part is how MediaWiki handles that constraint: it is building a second parser, Parsoid, alongside the classic one. Parsoid converts wikitext to HTML and back, which is what powers the visual editor [1].

Templates are DRY for wikis

Templates let a wiki define something once and reuse it everywhere — a navigation box, a banner, an infobox. A page calls a template with {{Name}}, and its content is expanded into the page at read time [1].

For Wikipedia this was transformative: the same boilerplate used to be copied onto thousands of articles. Templates gained parameters in MediaWiki 1.3 and default values in 1.6, and users pushed them hard — building near-programming constructs with the {{#if:…}} and {{#switch:…}} parser functions [1].

The price was performance: template-heavy pages became slow to parse. MediaWiki's answer was a rewritten preprocessor in MediaWiki 1.12 (2008): it parses templates into a tree and skips the branches that are never used, such as the un-taken cases of a #switch [1][7]. Template-heavy pages got much faster, without any change to the markup.

Skins separate content from presentation

A skin is the frame around the content: the header, footer and sidebar, plus the CSS and JavaScript that style them [3]. The parsed content HTML is the same under every skin; the skin decides how it is wrapped and presented.

The consequence is elegant: re-skinning a site never touches the content. Readers choose their skin in their preferences — the default is Vector [3] — and this very site offers both Vector and Timeless [2]. The same parsed page renders under either, without re-parsing [1].

Extensions plug in; the core stays stable

MediaWiki's core is deliberately small; almost everything extra lives in extensions. They attach to the core through hooks — places where third-party code can run before, after, or instead of MediaWiki's own behaviour for a given event [1]. Some hooks even let an extension add new wikitext syntax of its own [1].

This was not always so. Before hooks arrived in 2004, customising MediaWiki meant editing the core — fragile and hard to maintain [1]. The hook system turned that into a supported plug-in mechanism.

On this very site the pattern is visible: Cite, SyntaxHighlight, Wikibase — and Ronzz's own EmbeddableContent and WikibaseCitation — are all extensions, not forks [2].

Caching is the price of PHP

Every request boots PHP from scratch, so a busy wiki would be slow without help. MediaWiki answers with layers of caches [1]:

Layer	What it stores	Effect
Reverse proxy (CDN)	whole rendered pages	serves anonymous readers without booting PHP at all; most requests never reach the application servers [1]
Object cache (Memcached / Redis)	parsed page output	avoids re-parsing the same wikitext [1]
Opcode cache	compiled PHP	skips recompiling scripts on every request [1]

The clever part is that MediaWiki does not merely sit behind these caches — it tells them what to forget. When a page changes, MediaWiki purges it from the caches; when a template changes, every page that uses it is invalidated [1]. Correct invalidation is the hard part, and getting it right is what lets a constantly-edited site like Wikipedia be served from cache.

Try it yourself

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

# 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 wikibase.

# Preview without saving: run a snippet of wikitext through the parser
curl -sG "https://wikibase.ronzz.org/api.php" --data-urlencode "action=parse" --data-urlencode "text='''Bold''' and ''italic''" --data-urlencode "format=json" | grep -o "<b>.*</i>"

Output:

<b>Bold</b> and <i>italic</i>

# Every edit leaves a trace: the last three revisions of Main Page
curl -s "https://wikibase.ronzz.org/api.php?action=query&prop=revisions&titles=Main_Page&rvprop=timestamp%7Cuser&rvlimit=3&format=json" | grep -oE '"user":"[^"]*"|"timestamp":"[^"]*"'

Output:

"user":"Rongzhou"
"timestamp":"2026-08-24T14:55:13Z"
"user":"Rongzhou"
"timestamp":"2026-08-21T06:08:37Z"
"user":"Rongzhou"
"timestamp":"2026-08-19T18:59:55Z"

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.

References

1. Manual:MediaWiki architecture — the architecture deep-dive on mediawiki.org
2. This wiki's siteinfo API — version, PHP and database, extension list (fetched 2026-08-28)
3. Manual:Skins — skins documentation
4. Help:Editing pages — user documentation for editing
5. MediaWiki — the software project page
6. Help:Edit conflict — how conflicts are detected and resolved
7. Release notes/1.12 — the preprocessor rewrite
8. Revisions query (ids|timestamp|user|comment) — verified 2026-08-28
9. Parse API for Main Page — verified 2026-08-28
10. Parse API with raw text — verified 2026-08-28
11. Revisions query (timestamp|user) — verified 2026-08-28

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.

Wiki: wikibase.ronzz.org