Understanding MediaWiki's Revision History and Diff Features

What the revision history really is

Ever clicked that tiny “history” link on a wiki page and felt like you were opening a time‑machine? That’s the revision history – a chronological ledger of every edit, from the first shy line of text to the frantic last‑minute fix before a deadline. MediaWiki stores each change as a separate revision, complete with the editor’s name (or IP), a timestamp, an edit comment, and a unique rev_id. The magic lies in how the software stitches these snippets together so you can hop back, compare, or even roll the page forward again.

Why it matters

• Accountability. Every contribution leaves a digital fingerprint.
• Transparency. Readers can see how an article evolved, which is crucial for controversial topics.
• Recovery. Accidental deletions or vandalism? A few clicks, and you’re back in business.

That said, the history isn’t just a flat list. It’s a dynamic interface that lets you slice and dice revisions in ways that feel surprisingly flexible.

Browsing the list: the basics

When you land on a history page (usually https://example.org/wiki/Page_Title?action=history), you’ll see a table. Each row shows:

1. Timestamp – local time or UTC, depending on user preferences.
2. Editor – a linked username, or an IP address if the user isn’t logged in.
3. Comment – a brief note left by the editor, often starting with a “/* section */” tag.
4. Size change – a + or – sign indicating how many bytes the edit added or removed.

At the top, there’s a tiny filter box. You can type a username, a date range, or even a keyword that appears in edit comments. Handy when you’re hunting for that one tweak you made last Thursday.

Quick tricks while scrolling

• Press “Shift” and click two revision check‑boxes to select a range – MediaWiki will auto‑select everything in between.
• Click the “undo” link next to a revision if you want to revert to the state before that edit.
• Hover over a size change to see the exact byte difference in a tooltip.

Diff view: seeing the meat of the change

Once you’ve ticked two revisions and hit “compare selected revisions,” MediaWiki shows a diff. By default it uses the diff view, which highlights additions in green and deletions in red. The diff is generated on the fly by the RevisionDiff class, which runs a line‑by‑line comparison (or a word‑by‑word comparison if you enable it in LocalSettings.php).

<!-- Example: enabling word‑by‑word diff -->
$wgDiffEngine = 'wikidiff2';
$wgDiffEngineOptions = [ 'wordlevel' => true ];

There are a few variations worth knowing:

Side‑by‑side vs. inline

• Inline diff (the default) shows the old text, then inserts the new text right after, with <ins> and <del> tags.
• Side‑by‑side diff splits the screen into two columns, making it easier to compare long paragraphs.

You can toggle the style by appending &diffmode=sidebyside or &diffmode=inline to the URL. For example:

https://example.org/wiki/Page_Title?diff=prev&oldid=456&diffmode=sidebyside

Context lines

If you’re only interested in the changed snippet, turn off the surrounding context with &diff=cur&oldid=123&context=0. Some editors love a clean, cramped view; others, like me, prefer a few lines of context so you don’t lose the sentence’s meaning.

Special diff features you might have missed

MediaWiki isn’t just a dumb highlighter. Over the years, the diff engine has sprouted a handful of clever options that power users (and a few curious newbies) swear by.

Patrolling and flags

When you’re a patroller, the history page shows a little “patrolled” icon next to each revision you’ve reviewed. Clicking the flag toggles its status. This is especially useful on busy wikis where vandalism is a constant threat.

Tagging revisions

Admins can apply tags to revisions – things like “bot”, “minor edit”, or custom tags like “content‑migration”. Tags appear as small badges next to the revision entry and can be filtered just like usernames.

External diff tools

If you have a preferred diff viewer (maybe a Git‑style visualizer), you can set $wgExternalDiffEngine in LocalSettings.php to hand off the comparison:

$wgExternalDiffEngine = [
    'url' => 'https://mydiff.example.com/?oldid=$1&newid=$2',
    'window' => true,
];

Now clicking “diff” opens a new tab with your fancy external UI. I tried this once with meld on my desktop – feels like cheating, but it works.

Viewing a single revision

Sometimes you just want to see the page as it looked at a specific point, without any diff overlay. Append &oldid=12345 to the page URL:

https://example.org/wiki/Page_Title?oldid=12345

The page renders exactly as it did then, complete with templates and transclusions resolved at that time. Handy when you need to quote a statement that was later removed.

Common pitfalls and how to avoid them

Even seasoned editors stumble over a few quirks. Below is a short checklist that might save you a headache.

• Missing edit comment? MediaWiki will still record the change, but you lose context. If you’re fixing a typo, a quick “typo” comment is worth the few extra keystrokes.
• Accidentally reverted to a vandalized version? The “undo” link creates a new revision that undoes the selected edit, not a full rollback. If you need a clean slate, use the “rollback” option (available to admins and patrollers).
• Diff shows a huge chunk of text even for tiny changes? That usually means you’re comparing non‑adjacent revisions. Pick the nearest neighbours for a more focused diff.
• Templates and modules behave oddly in old revisions? Since templates are evaluated at render time, an old revision may display the current version of a template, not the one that existed back then. To see the exact old state, use the “stable” version of the template if your wiki supports it.

Advanced tricks for power users

Okay, this is where the rabbit hole gets deep. If you’re comfortable editing configuration files or writing extensions, these tips let you bend the revision system to your will.

Custom revision IDs in links

Every revision has a permanent URL. You can embed these in external documents so readers can reference the exact wording you cited. Example:

<a href="https://example.org/wiki/Page_Title?oldid=67890">See the statement as of 12 Mar 2023</a>

Because the URL includes oldid, it never changes, even if the page is edited later. It’s a neat way to create “stable citations”.

Generating a diff via API

If you’re building a bot or a custom dashboard, the MediaWiki API can return diffs in JSON. Here’s a minimal curl example:

curl "https://example.org/w/api.php?action=query&prop=revisions&rvprop=ids|timestamp|content&rvstartid=12345&rvendid=12350&format=json"

The response contains * fields with the raw wikitext of each revision. You can then feed that into any diff library you like – maybe difflib in Python or git diff for a familiar feel.

Limiting history depth

On high‑traffic wikis, storing every single tiny edit can bloat the database. Some admins set $wgMaxRevisionSize or enable revision pruning to trim very old, minor revisions. This is a trade‑off: you lose some granularity but gain performance.

Wrapping up: what to take away

Understanding MediaWiki’s revision history and diff features is like learning the chords of a song before you start improvising. Once you know the basics – the list view, the compare function, the URL tricks – you can start playing with the more advanced settings: external diff engines, API access, and revision tags.

In practice, the tools are there to keep the encyclopedia honest, to let contributors backtrack when they slip, and to give readers a transparent view of how knowledge morphs over time. If you ever feel lost in a sea of green and red highlights, remember that each line tells a story: a typo fixed, a source added, a controversial paragraph debated. And that story is exactly why the revision history matters.

So the next time you hover over “history”, take a moment to appreciate the silent ledger that’s keeping your wiki reliable, accountable, and, ultimately, a little bit human.