MediaWiki Documentation Day 2017

It’s MediaWiki Documentation Day 2017!

So I’ve been documenting a couple of things, and I’ve added a bit to the Xtools manual.

The latter is actually really useful, not so much from the end-user’s point of view because I dare say they’ll never read it, but I always like writing documentation before coding. It makes the goal so much more clear in my mind, and then the coding is much easier. With agreed-upon documentation, writing tests is easier; with tests written, writing the code is easier.

Time for a beer — and I’ll drink to DFD (document first development)! Oh, and semantic linebreaks are great.

Move a DokuWiki namespace to a different wiki

I started using DokuWiki a few years ago, and didn’t think very correctly about how to organise the page and media hierarchies. Now I know more about what I want in and how I need to be able to give people access to it, I’ve decided to reorganise the whole thing. Namespaces shall now be used for access control, not topics. The problem with this change is that there would be a pile of namespaces that would no longer exist but which would still need to be protected (or have their revision history removed). Most of their content isn’t going to remain on the site (thanks to a pile of family history stuff being moved into Webtrees at and so it seemed easier to start with a clean slate and move only selected bits to it. Hence, how to move a namespace into another wiki:

  1. Copy the data/{attic,media,media_attic,media_meta,meta,pages}/nsname directories from the old wiki’s data directory to that of the new.
  2. Clear the new wiki’s cache.
  3. Run php bin/indexer.php.
  4. Browse the new wiki and check that all is okay.

Easy, really.

DokuWiki hackfest

The annual DokuWiki hackfest is on in a month or so. Wish I could go. Will do next year.

It’s going to be held in the brilliant-sounding LinuxHotel in Essen, Germany, from Monday 29 July to Sunday 4 August.

There’s been a bit of stuff written lately about grumpy meanness and less-than generous interactions in various open-source communities, and I certainly agree with some of that. I’ve experienced it in some places, but certainly never in the DokuWiki world. Everyone seems just rather normal there, and friendly. (Some of the terseness in the Kohana forums, for example, isn’t! Not that collaboration doesn’t need critique, but it also needs kindness.)

Last year’s hackfest sounds like it would’ve been fun. A chap from Southeastern Railway said:

The Hackfest is just starting to wind down and as the only ‘user’ here for the whole weekend it has been a fascinating experience. I am the host on this occasion and we are a big user of Dokuwiki which is the core application in our technical document management system, some 40,000 pages and 20,000 images.

I have been involved with technical document management for many years, in both aviation and rail. DokuWiki is the first really successful document management application I’ve implemented. Our user base has taken to it with ease and we continue to find new and innovative things we can do with the software.

forking wikis

I wish wikis were less collaborative! I wish they were more like software projects, where if one wants to modify anything, one gets one’s own copy and does anything at all to it.

No, I’m not really saying that there should be fewer centralised places of communal effort, these things are great… I just want a good way to branch and modify non-code content.

A cross between the Internet Archive’s system for uploading content into their collections, and Github’s user-centric arrangement.

The problem seems to often come back to the formats that things are in. It’s easy in the text-only code world; but wiki’s each have their own markup…

I wondered about the use of MediaWiki, and pulling in remote articles (periodic synchronisation), but of course there’s no merging in that idea, so it doesn’t work. It’s what Printable WeRelate does, but I’m yet to quite figure out how that’s going to deal with local additions to the data (probably, pages will be quite separate, with links only going from the local-only content to the remote-sync’d stuff; because we can’t modify the remote articles locally, and links in them when they’re elsewhere wouldn’t make sense).

So, there’s no solution: I’ll stick to centralised editing and storage, but carry on pulling backups (huzza to Wikiteam).

Freopedia advertising

Screenshot of the announcement in the Gazette, with fuzzy borders.
This week’s Gazette has an announcement about Freopedia and the editing sessions we’re holding at the Fremantle Library.

(That QR code, by the way, goes to; the code illustrating that article is for ‘Nastco stock photos’.)

Relatedly, here’s an interesting article from the Smithsonian Institute about why it’s nice to edit Wikipedia with friends, and in libraries.

Don’t Write Code (write descriptions of things)

I wish I didn’t know how to code.

For a programmer, the solution to every problem is to write more code.

But sometimes, all that is needed is to write proper words. To explain things and explore them through prose.

Not to remove oneself to the meta-realm of trying to understand the general structure of the problem and model it accordingly. (And then build something that resembles that model, and hope that the people using it see through the layers back to what the buggery’s trying to be done!)

Just write some nice, verbose, rambling blather about what it is and how it works and where we’re trying to go from here. Nothing too technical, and hopefully actually interesting to read. At least, linear, in that old-fashioned way of real writing. Interesting is probably too much to aim for… just words, then.

I was reading Phoebe Ayers recent post about the task of archiving the Wikimedia Foundation’s material. My first thought was “what sort of database/catalogue would be useful for this sort of thing?” Which is quite the wrong question, of course. There’s a whole world of wikis (both instances and engines) out there, perfect for this sort of variably-structured data. (If there’s one thing that constantly amazes me about Wikipedia it’s the fact that so much structure and repeated data is contained in what is basically an immense flat list of lone text files, and that it does rather work! The database geek in me shudders.)

I think a basic tennent for archiving physical and digital resources is that each object, and each grouping of objects, needs to have its own web page. In most cases, I use this both as a catalogue entry for the object or group, and as a printable coversheet to store along with the physical objects (or, in the case of digital-only objects, to be a physical placeholder or archive copy, if they warrant it).

The other thing I try to stick to is that a fonds and its catalogue (i.e. a pile of folders/boxes and the website that indexes them and adds whatever other digital material to the mix) should be able to be shifted off to someone else to maintain! That not everything should live in the same system, nor require particularly technical skills to maintain.

I know that there’s a dozen formalised ways of doing this stuff, and I wish I knew the details of them more thoroughly! For now, I’ll hope that a non-structured catalogue can work, and continue to write little printable English-language wiki pages to collate in amongst my folders of polypropylene document sleeves. And I’ll keep checking back to for instructions on how to do it better…

Wiki Wednesday

Because I never make the time elsewhere to get anything done, I have decided to schedule in an hour or so — just a tiny bit of time, but regular (and here I am, for the second time) — every Wednesday afternoon at the local library, to focus on Wikimedia stuff. Not that I’m very active, and who knows if I’ll succeed in getting anything done; but I’d like to. There’s a whole number of things I want to work on. This plan for QR codes in Freo is spurning me on for one, but today it’s just Geffrard that I want to focus on…

The Geffrard was a ship that sunk south of here in 1875, and my great-great-great-uncle was her master at the time. We (my mum and me, that is; she’s become rather a dedicated genealogist in the last year!) are gathering more and more sources, and soon there will be enough to write something up (whether notable or not, I dunno). Right now, we’re transcribing the inquiry into the shipwreck on Wikisource. So I’ll get cracking on with that…

* * *

Power point in the Freo library with a sign hanging over it prohibiting use for personal equipmentExcept! :-( Except that the library’s wifi seems to be failing me, and (worse) my battery is flat and this place doesn’t provide a single power point for laptops. I think that’s a shame. I mean, I know there’s some arguments around about libraries being places for books, and quiet reading, and whatnot… but really, I’d far rather they were places of general learning and exploration and intellectual inquiry and… well, y’know… all that. It seems that a library full of laptops (and this one, tonight, is just that; I counted eight just now when I went looking for power) is a pretty great thing; certainly on a par with a library full of noisy children (and this one is also that). So, are they just looked on as ‘distractions’? Or we don’t want the place filled up for twelve hours a day with pauper uni students looking for free wifi and some warmth? Or is there some OH&S ruling lurking somewhere? If I had my power cable tested and tagged, would that let me in?! Surely, nerding it up in libraries should be encouraged — it’s far cheaper, if nothing else, than the library service supplying all of these computers itself.

Anyway, don’t let me rant on about that. I’ll get back to preparing some scans of our captain’s Masters Certificate for upload to Commons, and I’ll be back next week with a full battery!

Upgrading MediaWiki and SMW

I was updating MediaWiki to 1.17 last night, and kept getting a::

  Fatal error: Call to undefined function wfWarn() in /var/www/w/extensions/SemanticMediaWiki/includes/SMW_Setup.php on line 49

because I was setting up SMW with $wgServerName:


and this has been deprecated in 1.17. As for why SMW is using the nonexistant mfWarn(), I haven’t got time to investigate.

FreoWiki is go! (Or GoFreo is a wiki?)

We had a great gathering last night at Little Creatures to talk about FreoWiki (including what to call it; one suggestion is GoFreo). Some topics…

  • It’s all set up and good to go, at;
  • The site overall is licenced under CC Attribution 2.5 Australia, but people can put whatever licences they want on individual pages or media;
  • Some ideas are being bounced around about alternatives to FreoWiki as a name;
  • The Fremantle Herald might be interested in adding their archival content to FreoWiki—at the moment they’re only keeping the four most recent editions on their site, and we could host a complete archive;
  • Personal, first-person content is desirable: people’s recollections of Fremantle, or visions for its future;
  • The entry page needs to look good, and (visually) convey what it’s all about;
  • We’ll make cards to hand out to people, with some small bit of info about FreoWiki, and a URL with a blank after it (i.e. in which we can write the name of the page that we’re suggesting people use; e.g. to a business owner, with the name of their business (then we scurry home and quickly add some content to that page);
  • Good thought needs to be given to ways of ensuring longevity of the project (if it takes off), both technical (backups etc.) and organisational;
  • We should enable using media from Commons (already done);
  • Plus lots of other stuff that I can’t right now remember!

So now it’s time to start adding content! :-) The easy bit, really.