A Better Way To Deal With MediaWiki Extensions

If you've ever gotten around to installing and especially maintaining extensions or skins in MediaWiki, you know how cumbersome it can be. Every time you need to update an extension or skin, you have to check whether there's a newer version, then manually download it, extract it, and replace the old files. If the extension supports Composer, great! Less of a hassle, but let's be honest, not many extensions support Composer, and some would find it daunting to have to use both Composer and the manual method. Now do this for all extensions and skins you use, and you'll be wanting to break your keyboard.

What about Git? You say. Well, Git works for the most part, but it's not the recommended installation method for non-developers, is it? Most of the time, you should prefer the tarball method over Git, since tarballs often include vendored dependencies and usually take up less space. Also, this doesn't fix the issue of having a way to conveniently check and update all extensions and skins you use.

Because of those issues, I've spent years writing bash scripts to automate updating extensions and skins. They were never very 'reliable' or comprehensive, though, since they were tailored to the extensions I use: where to check for updates, which installation method they used, whether they required running the update maintenance script, and so on.

Code Is Being Pushed Way Faster

A lot of people, especially new sysadmins, often install extensions and leave it at that, no more work to do until the next MediaWiki upgrade. That's an easy habit to fall into, and obviously it means important updates might be missed, heck, the sysadmin might not even be aware there's an update!

But in the age where technology moves so fast, where code commits are in the billions per month, you really need everything to stay up to date, not just for the features but also for the security patches. (A popular extension has already been exploited on wikis that use it!)

We can't simply afford to leave everything as is much anymore; people are using agents to help make better extensions and skins, but people are also running those same agents to find and exploit vulnerabilities for their own gain.

It's Time to Change

I'm honestly surprised there still isn't a standard way to manage extensions and skins for one of the most used pieces of software in the world. There have been attempts over the years, like mediawiki-extension-command and mwman, but most are abandoned and not very robust. There's also Canasta CLI, but it's tied to their Docker setup, and ideally, I wanted something that works on any wiki, including the one I already have running.

So, I simply took a page out of the JavaScript ecosystem and adapted it for MediaWiki. Check out phuo, a dead simple package manager for MediaWiki.

As much as I dislike package managers since they also amplify security risks such as supply chain attacks, I think it's wrong to dismiss what they bring to the table; honestly, I'd argue that it has more advantages than disadvantages.

What phuo Does

phuo primarily banks on MediaWiki's extension distributor, similar to the npm registry. Of course, you can get extensions from other sources like GitHub; not having that would be a shame, haha.

One thing I didn't want was a tool that made you start over just to use it. You can run phuo init on a wiki that already has extensions and skins, and it takes stock of what's already there! No need to replace all the files or start with a blank setup. From then on, phuo keeps track of what's installed and, when it can identify it, which version or branch it came from. I wouldn't need to manually update my own bash scripts anymore, how lovely.

It reads the extension's own metadata to check compatibility and resolve its dependencies, including Composer packages. No longer does one have to hunt down the right release branch; when one exists for my wiki's MediaWiki version, phuo will pick it.

Anyway, the best part is that every time I update my extensions, and let's say an update causes trouble, phuo revert can restore the previous package state, thus making extension rollbacks extremely convenient. Currently, though, it only rolls back the extension, and it can't undo side effects like database changes; it's something I hope to change, but honestly? It's not that much of a big deal since most, if not all, breakage that you'll encounter is incompatibilities and not the database soiling itself.

There's plenty more in there (phuo doctor, phuo why, pinning branches, patching in place), though it's a lot for me to try and show off here.

Give It a Try

phuo is still young, so if you run into something odd or have an idea, open an issue. I think it has a lot of room for it to grow (pun intended), especially for setups with multiple wikis hosted.

If you've been maintaining your wiki with a pile of bash scripts like I was, perhaps it's time to retire them. It's very similar to npm and bun; surely you'll find it very intuitive.