Why MediaWiki permanent links aren’t fully permanent

, .

MediaWiki, the software behind Wikipedia and many other wikis, allows visitors to copy a “permanent link” (or “permalink”) of the article they are currently viewing.

As English Wikipedia’s help page on permanent links notes, these links aren’t fully “permanent”: visiting these links later is not guaranteed to show the exact same content. I thought it would be useful to list some of the different ways in which differences can appear.

What a permalink is

While the permalink shown in the sidebar (or “tools” menu) contains both the title= and oldid= URL parameters (example: https://en.wikipedia.org/w/index.php?title=Wikimedia_Commons&oldid=1185477778), only the oldid= is actually required (equivalent example: https://en.wikipedia.org/w/index.php?oldid=1185477778). The value of this parameter is the revision ID of a page, and it tells MediaWiki to use the content of this revision of that page instead of its latest revision. For normal wiki articles, this content is the wikitext (the source code of the article), which is then rendered and shown to the visitor; you can also see the content unrendered by adding &action=raw to the URL (example).

Changes in on-wiki content

Let’s start with the biggest one. Visiting a permalink only loads the content of the page itself as of the revision specified in the URL. Any other templates, Lua/Scribunto modules, or other transcluded pages are loaded, parsed / evaluated and shown using their latest revision, not whatever was their latest revision when the permalink’s revision was created. Templates may look and behave very differently from what they used to do; their parameters also may or may not be compatible with the template invocation in the old revision, depending on how the community edited the templates.

In fact, it’s not even guaranteed that the page will show the same templates at all. Templates are looked up by their name according to the old revision’s wikitext, but templates can be deleted, recreated, or renamed. For instance, several wikis now have templates like {{Q|Q123}} and/or {{P|P123}} to show Wikidata items and/or properties; but in the past, “Q” or “P” may have referred to different templates that were later deleted, as e.g. on Esperanto, Chinese or Spanish Wikipedia. (These are conveniently short names, after all! On English Wikipedia, {{P}} is still a smiley 🙂)

A more niche phenomenon is redlinks (h/t Antonin Delpeuch for this one). MediaWiki shows internal links to existing pages in blue, and links to pages that don’t exist in red; but when rendering a permalink, this refers to whether the page currently exists, not whether it used to exist when the old revision was saved. (You can actually see this in the example permalink from earlier, where a “not to be confused with” hatnote points to a redlink that was evidently deleted in the meantime.)

Articles may also be affected by changes in the wiki’s default interface JavaScript and CSS and default gadgets, which may interact with page contents. For example, styles for frequently used templates are sometimes moved into common.css (or out of it), and some templates may rely on gadgets for interactive functionality (like – CW for some medical imagery in the next link – Wikimedia Commons’ Imagestack). As with templates, it’s ultimately up to the community whether changes here are backwards compatible or not.

Changes in content on other wikis

Articles can also use content from other wikis, the most prominent example being Wikimedia Commons images (which, thanks to InstantCommons, are used not only on Wikimedia wikis but also many other wikis using MediaWiki). A permalink will show the latest version of an image on Commons, which is not necessarily the same version as was shown when the old revision was saved – although, due to Commons’ don’t be bold policy, the differences should usually be minor (e.g. a higher-quality version or a slightly improved crop).

The image on Commons may also have been deleted in the meantime, e.g. because it turned out to be a copyright violation. In this case, the permalink will show the image as a redlink.

There are also other ways for wikis to refer to Commons. Prior to its undeployment due to security issues, the Graph extension could load data from the Data: namespace on Commons, and show it e.g. as a line chart.

And then there’s Wikidata. Wikipedia editors can, at their discretion, make an article read information from Wikidata; this has a number of benefits, but is also another case where visible parts of an article aren’t part of the article’s source code and viewing old revisions will still pull the latest version from the referenced place.

Changes in the software

Finally, the software which actually renders the old revision’s content is also subject to changes. MediaWiki sees roughly two thousand code changes per release, and any of them might affect the way an article looks. While the parser is developed fairly conservatively (as nobody wants to break millions of existing pages all at once), there are sometimes breaking changes to it; many of them may be preceded by on-wiki fixes to avoid the breakage (e.g. using the Linter to locate problematic constructs whose behavior will change in future), but this doesn’t help when looking at old revisions.

Also, similar to the earlier point about the wiki’s default CSS and JS, the old revision may also have relied on CSS or JS included in MediaWiki, which is subject to change. For example, many articles rely on collapsible elements (which is an intentional feature offered by MediaWiki which has stayed very stable so far), and many pages (help and project pages more so than articles, I believe) rely or relied on styles from the OOUI or MediaWiki UI interface libraries, a practice that is increasingly discouraged as these libraries are being phased out in favor of Codex (though the replacement is not yet clear).

Now what?

If you want to create a new link to some wiki content as you currently see it: you can use a permalink as offered by MediaWiki (it’s a pretty “lightweight” solution), but if you want to be absolutely sure that everyone else will see the same content, I believe the only way to do that and avoid all the issues here is to grab a snapshot of the rendered wiki content and distribute that. You can do this via a trusted intermediary, such as the Internet Archive’s Wayback Machine, or you can save the page yourself.

If you’re looking at a permalink that you found somewhere else, I think it’s worth keeping in mind that there are some caveats to it, but 99% of the time it’s fine – in practice, I think most of the issues listed here are more theoretical than practical concerns. If you really want to be sure you’re seeing a page as it originally appeared, you can try to find a snapshot on the Wayback Machine or another web archiving site.

There is also a proposal for a Wiki Timeslicer tool which would bypass some of these problems. (Personally, I’m skeptical how feasible it is, to be honest. But it probably is possible to improve on MediaWiki’s own functionality, at least.)