Editing MediaWiki pages in an external editor

I’ve been working on a MediaWiki gadget lately, for editing Wikisource authors’ metadata without leaving the author page. It’s fun working with and learning more about OOjs-UI, but it’s also a pain because gadget code is kept in Javascript pages in the MediaWiki namespace, and so every single time you want to change something it’s a matter of saving the whole page, then clicking ‘edit’ again, and scrolling back down to find the spot you were at. The other end of things—the re-loading of whatever test page is running the gadget—is annoying and slow enough, without having to do much the same thing at the source end too.

So I’ve added a feature to the ExternalArticles extension that allows a whole directory full of text files to be imported at once (namespaces are handled as subdirectories). More importantly, it also ‘watches’ the directories and every time a file is updated (i.e. with Ctrl-S in a text editor or IDE) it is re-imported. So this means I can have MediaWiki:Gadget-Author.js and MediaWiki:Gadget-Author.css open in PhpStorm, and just edit from there. I even have these files open inside a MediaWiki project and so autocompletion and documentation look-up works as usual for all the library code. It’s even quite a speedy set-up, luckily: I haven’t yet noticed having to wait at any time between saving some code, alt-tabbing to the browser, and hitting F5.

I dare say my bodged-together script has many flaws, but it’s working for me for now!

New feature for ia-upload

I have been working on an addition to the IA Upload tool these last few days, and it’s ready for testing. Hopefully we’ll merge it tomorrow or the next day.

This is the first time I’ve done much work with the internal structure of DjVu files, and really it’s all been pretty straight-forward. A couple of odd bits about matching element and page names up between things, but once that was sorted it all seems to be working as it should.

It’s a shame that the Internet Archive has discontinued their production of DjVu files, but I guess they’ve got their reasons, and it’s not like anyone’s ever heard of DjVu anyway. I don’t suppose anyone other than Wikisource was using those files. Thankfully they’re still producing the DjVu XML that we need to make our own DjVus, and it sounds like they’re going to continue doing so (because they use the XML to produce the text versions of items).

Abandoned code projects

One of the sad things about open source software is the process of working on some code, feeling like it’s going somewhere good and is useful to people, but then at some point having to abandon it. Normally just because life moves on and the higher-priority code always has to be the stuff that earns an income, or just that there are only so many slots for projects in my brain.

I feel this way about Tabulate, the WordPress plugin I was working on until a year ago, and about a few Dokuwiki plugins that I used to maintain. All were good fun to work on, and served reasonably useful places in some people’s websites. But I don’t have time, especially as it takes even more time & concentration to switch between completely separate codebases and communities — the latter especially. So these projects just languish, usually until some wonderful person comes along on Github and asks to take over as maintainer.

I am going to try to keep up with Tabulate, however. It doesn’t need that much work, and the WordPress ecosystem is a world that I actually find quite rewarding to inhabit (I know lots of people wouldn’t agree with that, and certainly there’s a commercial side to it that I find a bit tiring).

Not this morning, though, but maybe later this week… :-)

Manually upgrading Piwigo

There’s a new version of Piwigo out, and so I must upgrade. However, I’ve got things installed so that the web server doesn’t have write-access to the application files (as a security measure), and so I can’t use the built-in automatic upgrader.

I decided to switch to using Git to update the files, to make future upgrades much easier and without having to make anything writable by the server (even for some short amount of time).

First lock the site, via Tools > Maintenance -> Lock gallery, then get the new code:

$ git clone https://github.com/Piwigo/Piwigo.git photos.samwilson.id.au
$ cd photos.samwilson.id.au
$ git checkout 2.8.3

Copy the following files:

/upload (this is a symlink on my system)

The following directories must be writable by the web server: /_data and /upload (including /upload/buffer; I was getting an “error during buffer directory creation” error).

Then browse to /upgrade.php to run any required database changes.

I’ve installed these plugins using Git as well: Piwigo-BatchDownloader, Flickr2Piwigo, and piwigo-openstreetmap. The OSM plugin also requires /osmmap.php to be created with the following (the plugin would have created it if it was allowed):

define( 'PHPWG_ROOT_PATH', './' );
include_once( PHPWG_ROOT_PATH . 'plugins/piwigo-openstreetmap/osmmap.php' );

That’s about. Maybe these notes will help me remember next time.


The internet has arrived. I’ve been haggling for two months to get connected, but at last (and two days before scheduled) I’m actually at home and online and not going over my mobile data limit. Even better, I’m getting 6.2 Mb/s. (Which is good, for Fremantle.)

I shall now resume my various web-scraping and archiving activities…. :-)

Marking time

When the sun gets over the yardarm here (when it’s about level with the top of the Port Authority building), it gets into my eyes and I have to close the blind. So, does that mean it’s beer o’clock? Probably not, but it must surely be time to skive off on some nice code that makes sense and feels calmer and more testable? I reckon so.

My dream job

So I’ve started a new job: I’m now working for the Wikimedia Foundation in the Community Tech team. It’s really quite amazing, actually: I go to “work” and do things that I really quite like doing and would be attempting to find time to do anyway if I were employed elsewhere. Not that I’m really into the swing of things yet—only two weeks in—but so far it’s pretty great.

I’m really excited about being part of an organisation that actually means something.

Imagine a world in which every single human being can freely share in the sum of all knowledge. That’s our commitment.

It’s a bit cheesy to quote that I know, but still: how nice it is to think that there’s something higher up the orgchart than an ever-increasing concentration of money.

Enable Left Win as the Compose Key on Ubuntu

It is very easy to type “special” characters on Linux (i.e. those that aren’t printed on the keyboard). It’s called the Compose or Multi Key, and it’s brilliant.

First, enable it in ‘Keyboard settings > Advanced > Position of Compose Key’. I’ve got it set to Left Win because I never use that for anything and it’s in a similar position to the key on Apple computers that serves a similar purpose (but whose name I cannot remember).

If the Left Win option is missing (as it seems to be on some Ubuntu installations), you just need to edit /etc/default/keyboard and set:


Then run:

sudo dpkg-reconfigure keyboard-configuration

Once it’s all working you just need to look up the characters you want (Tim Starling also has a good list).

Running tests on WordPress coding standards

The docs for WordPress-Coding-Standards assume that one is installing things globally, but I don’t like my hacking on phpcs to break my usage of it elsewhere, so I wanted to cordon things off in their own little dev area. This is how.

Clone the two required repositories to directories next to each other:

cd ~/public_html/wordpress/
git clone https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git
git clone https://github.com/squizlabs/PHP_CodeSniffer.git

Mostly you’ll be working from the PHP_CodeSniffer side of things. Change into that directory and set up its dependencies:

cd PHP_CodeSniffer
composer install

Set up phpcs so that it can find its tests and the WordPress coding standards:

cp phpunit.xml.dist phpunit.xml
./scripts/phpcs --config-set installed_paths ../WordPress-Coding-Standards/

And now you’re ready to run the tests (still from the PHP_CodeSniffer directory):

./vendor/bin/phpunit --filter WordPress

Spaces around dots

One of the first odd things that one finds when starting to work with WordPress code is the excessive use of spaces. Something like:

do_something('Words of '.$widget->noun($attrs['ish']));

becomes the the stretched out:

do_something( 'Words of ' . $widget->noun( $attrs['ish'] ) );

Which is fine, and actually now I’ve been using it for a decade I’m pretty comfortable reading it. But it’s uncommon in the PHP world. (And note the singular place in which spaces aren’t used: the array key, iff it’s a string.)

Not only that, but I just recently realised that the PHP CodeSniffer sniffs for WordPress don’t actually check for the spaces around the concatenation operator. I’ve filed an issue for that.