HowItWorks:MediaWiki

From Wikibase
Revision as of 09:46, 23 August 2026 by SeedBot (talk | contribs) (Standardize: add copy button to block code snippets)
Jump to navigation Jump to search

Languages: English · français · Esperanto

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. A wiki is a website whose pages anyone can edit in a lightweight plain-text markup called wikitext, with every save kept as a revision and the full history always available. MediaWiki is the machinery that turns that wikitext into the HTML pages you see in your browser.

The parts

Part Role
wikitext the content format: plain text plus light markup — '''bold''', [[links]], {{templates}}
database (MySQL / MariaDB) the single source of truth: page wikitext, every revision, users, permissions, categories, queued jobs
preprocessor front stage of parsing: expands templates, parser functions and magic words into expanded wikitext
parser converts wikitext into HTML; since MediaWiki 1.44 a second parser (Parsoid, bundled as a PHP library) handles visual editing and the REST API
Sanitizer scrubs raw HTML for unsafe content before it reaches the page
skins wrap the content HTML in the site's chrome: sidebar, header, footer, personal tools
extensions PHP plugins that hook into core events to add features without forking the core
web server + PHP-FPM receive HTTP requests and run the MediaWiki application
cache layers skip re-parsing and re-rendering on repeat views

How it works

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.

Editing runs the pipeline the other way: the editor posts wikitext → MediaWiki stores a new revision (old ones stay, giving every page a full history) → the page is re-parsed → link tables, recent changes and the search index are updated. Heavy follow-up work (search indexing, notification e-mails) is queued into the job queue so the save itself stays fast.

Why it works that way

  • Content stays in wikitext, not HTML. Diffs, history and collaborative editing fall out naturally — and when the software changes its HTML output, no content has to be rewritten.
  • 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).

Diagram

The wikitext → HTML pipeline
Stage What happens
preprocessor {{templates}}, {{#if:…}}, magic words → expanded wikitext
parser expanded wikitext → HTML (via Sanitizer)
skin content HTML + chrome + ResourceLoader CSS/JS → complete page
cache the complete page is stored; repeat views skip the stages above

Gotchas & myths

"MediaWiki is a CMS like WordPress."

Myth Reality
publication workflows, per-namespace access control, WYSIWYG-first editing a wiki engine: open editing, per-action permissions, a stable text markup. The visual editor is an extension, and access control beyond "everyone can edit" is not the default.

"Editing wikitext is editing HTML."

Myth Reality
<script>alert(1)</script> would run raw HTML is only allowed in limited forms; the Sanitizer strips anything unsafe — a <script> tag never survives into the page.

"A template change instantly updates every page using it."

Myth Reality
save the template → all pages render the new output immediately transclusion happens at parse time; already-cached pages keep the old rendering until their cache is invalidated. A widespread template change can need a purge or a cache clear.

"Every page view runs PHP and re-parses the page."

Myth Reality
PHP boots and the full pipeline runs for every hit cached pages short-circuit before the application; only uncached requests run the full pipeline.

Try it yourself

All commands below were run live against this wiki (MediaWiki 1.46.0) while writing this page. 

# 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":"[^"]*"'

Verified 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>[^<]*"

Verified output: 

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

# See the preprocessor stage directly: Special:ExpandTemplates
#   https://wikibase.ronzz.org/wiki/Special:ExpandTemplates
# paste {{HowItWorks}} into the input box and click "Expand" —
# you see the expanded wikitext before the parser turns it into HTML.

# The database schema updater — any maintenance script runs the same way
php maintenance/update.php --help

Verified output: 

MediaWiki database updater

And in the browser: edit any page on a wiki where you can edit, save it, then open View history — you will see every revision kept, one per save.

Further reading

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

Retrieved from "https://wikibase.ronzz.org/index.php?title=HowItWorks:MediaWiki&oldid=1540"