HowItWorks:MediaWiki: Difference between revisions

From Wikibase
Jump to navigation Jump to search
← Older editNewer edit →

Rongzhou (talk | contribs)

4 user groups
1,058 edits
Line 145: Line 145:
== MediaWiki in action ==
== MediaWiki in action ==


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


=== Page view ===
=== Page view ===


A page view passes through these stages:
<uml>
@startuml
!theme bluegray
title Page View Flow
 
|#LightGray|Client|
start
:Request page;
 
|#LightBlue|Web Server|
:Resolve title\n(check permissions);
 
|#LightGreen|Cache|
:Look up rendered\nHTML in cache;
 
if (cache exist?) then (yes)
  if (cache_timestamp > last_edit_timestamp?) then (yes)
  :Retrieve cached HTML;
  |#LightGray|Client|
  :Serve cached page;
  stop
  else (no)
  |#LightGreen|Cache|
  :Purge cache;
  endif
else (no)
endif
  |#LightYellow|Database|
  :Load raw wikitext;
  |#LightPink|Parser|
  :Preprocess + Convert\nto HTML (Sanitizer);
  |#LightBlue|Web Server|
  :Apply Skin & assets;
  fork
    |#LightGreen|Cache|
    :Store rendered output\nto cache for future;
  fork again
    |#LightGray|Client|
    :Serve fresh page;
  end fork
  stop
 
@enduml
</uml>
 
 


# '''The request arrives.''' The browser asks for <code>/wiki/Main_Page</code>. The web server hands it to PHP-FPM, which boots MediaWiki through <code>index.php</code>: security checks, default settings, then the site's own <code>LocalSettings.php</code>.
# '''The title is resolved.''' MediaWiki works out which page is meant (namespace, redirects, aliases) and checks the reader's permissions.
# '''The wikitext is loaded''' from the database — MediaWiki stores the source text, not the rendered page [1].
# '''The preprocessor expands.''' Template calls (<syntaxhighlight lang="wikitext" inline>{{...}}</syntaxhighlight>), 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 <syntaxhighlight lang="wikitext" inline>{{#switch:…}}</syntaxhighlight>.
# '''The parser converts to HTML.''' Wikitext syntax becomes HTML elements; the Sanitizer class scrubs any raw HTML for unsafe content [1].
# '''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].
# '''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 ===
=== Page edit ===


An edit is the mirror image of a view: instead of reading a revision, it writes a new one.
<uml>
@startuml
!theme bluegray
title Page Edit Flow
 
|#LightGray|Client|
start
:Open edit form\n(load wikitext);
 
repeat
  :Modify wikitext;
  if (Preview / Diff?) then (yes)
    :Show preview/diff\n(without saving);
  else (no)
  endif
repeat while (Continue editing?) is (yes) -> no
 
:Submit save;
 
|#LightBlue|Web Server|
:Check edit conflict\n(compare revisions);
 
if (Conflict detected?) then (yes)
  |#LightGray|Client|
  :Show merge screen\n(auto-merge unrelated sections);
  :Merge & resubmit;
  |#LightBlue|Web Server|
  :Re-check (no conflict);
else (no)
endif
 
|#LightYellow|Database|
fork
  :Store new revision\n(author, time, summary);
fork again
  :Update page history\nand RecentChanges;
end fork
 
|#LightGray|Client|
:Edit complete\n(page updated);
 
stop


# '''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].
@enduml
# '''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].
</uml>
# '''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].
# '''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.
# '''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 ==
== Key design decisions ==

Revision as of 16:18, 28 August 2026

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 thousands of wiki instances, such as Wikipedia, Wikidata — and this very site: RonzzWikiBase [5].

What is a wiki engine?

Wiki engine is the software behind a wiki: a website hosting static pages, usually informative, which contributors can edit within their browser, with every change tracked and reversible, hence allowing contributions from a large number of editors located anywhere in the world. In its most radical form, e.g., Wikipedia, anyone reading the page can make edits, quickly correcting errors and updating pages.

A wiki engine's job is to store wiki pages in a database, and pull them up for contributors to edit or for the renderer to render page to HTML for readers.

MediaWiki, one of the most well-known wiki engines, was originally built as a summer project by early Wikipedia contributor Magnus Manske in 2001 to support a growing Wikipedia. It went through multiple full/partial rewrites to reach 1.0 release maturity in December 2004, and it is today used by tens of thousands of wikis, private and public.

Components and interactions

MediaWiki in action

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

Page view



Page edit

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

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

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