The job nobody wanted

The live site had been compromised by pirate accounts and was running MediaWiki 1.26.4, released in 2015. A previous migration attempt had been abandoned halfway and left the database with mixed and missing tables.

More than one party had looked at it and said it could not be saved, and that starting again would be the sensible thing.

I did not say yes or no straight away. From the client’s database dump I rebuilt the whole site in a fully offline environment on my own machine, with no connection to the live site and therefore no risk. Only once that test showed the content could be saved did a plan and a quote follow.

That is how I work. I do not sell certainty I do not have yet.

The path ran from MediaWiki 1.26.4 to 1.31, to 1.35, to 1.39.10, with MySQL from 5.7 to 8.0 and PHP from 7.4 through 8.1 to 8.3. But the version numbers are not the work.

Over 8,000 duplicate archive revisions renumbered, on revision 149315 alone. A missing revision timestamp index restored. The actor model migration completed. The Multi Content Revision tables, the logging, the change tags, the file archive and the user talk pages repaired one by one.

Tens of thousands of spam pages removed, with the deletion list reviewed three times before anything went, because you do not get back what you throw away by mistake.

Then the content. On the order of 100,000 semantic entities regenerated. Over 4,200 images re-imported with their metadata rebuilt, after the media backend turned out to be hanging off the wrong tables.

Once all of that stood, the site was still slow. Repeat page loads ended up 26 to 64 times faster than the starting point, on the pages that were benchmarked.

That did not come from a trick. A two level cache around the upstream API and the SPARQL calls: memoisation within one page render, plus an on-disk cache that keeps for thirty minutes. Parser and page cache switched on, with a cache epoch to force a clean redraw without turning the cache off. Heavy galleries behind an IntersectionObserver.

And the removal of a construction where the server called its own web API. That one was slow, and under load it could exhaust the whole worker pool.

A migration is finished when the site runs. I did not think that was enough. I built six tools, and they all have the same purpose: that the platform keeps itself clean once I am gone.

AtlasQualite scans the whole catalogue, about 4,600 artwork notices, and scores each one for completeness against the fields that matter. Image, coordinates, author, date, description, Wikidata link. The result is a prioritised worklist for the editors. You cannot improve what you do not measure.

AtlasRepair clears up what old imports left behind. The pattern is deliberate: first a dry run that changes nothing and writes a report, then an overview with every proposed change from current to corrected value, and only then an application with attribution and a rate limit. On the last dry run it flagged 1,343 records.

Wikidata Enrich fills empty fields in one click, and only empty fields, always with a preview before anything is saved. AMAPIStatus calls the self test and shows per endpoint whether it works. For a platform being handed to a public institution, being able to point at a page where everything is green is worth a great deal.

MapSync rebuilds the map automatically on every save or import, in process, transactionally, with its own lock so two rebuilds cannot collide. AtlasNova is the new skin: 1,478 lines against 3,527 in its predecessor. Less than half, for something that is more modern and easier to maintain.

Together I wrote over 27,000 lines of my own code, inside an installation of more than two million lines and 43 extensions that each had to come along to 1.39 and to PHP 8.3.

This is the part a client can use. Every tool that writes is restricted to logged in editors. Nothing anonymous can start a change.

Bulk operations always run dry first and only write after a person has read the report. There is no path where a mass edit happens without someone confirming it. Every file I edited was backed up first with a timestamp, so each individual change can be rolled back. Error display is off for visitors and on in the logs for the administrator.

And one design rule that carries the rest: my own API layer reads MediaWiki only through the stable action API and never directly from SQL. A future upgrade therefore cannot break the backend. That is exactly what went wrong in the installation I inherited.

The project document also keeps track of what is not finished. The map table holds 988 rows where 4,537 have been in it, because a batch that timed out was once read as no more results. The guard against that truncation is in place now, so a rebuild is safe. And the coordinate property is an ordinary page property rather than a geographic one, so the radius search over our own data returns nothing.

I delivered a sixty page runbook with it, containing the full error catalogue and the open points. Not because I had to, but so the next developer does not have to work out again what I already know.