MediaLoader extension

There’s a new MediaWiki extension that’s just been published: MediaLoader. It looks like it’s supposed to load media items such as images, videos, etc. on demand. I haven’t been able to get it to actually work (there’s some strange Composer loading stuff going on in its code) but I think it works by displaying a click-able bit of text such as ‘Load example.jpg’ (not actually a link) that, when clicked, turns into the image or whatever. All it’s doing for me right now is turning into the raw wikitext, but maybe there’s something I’m missing.

I guess the idea is to not download/display the image if its not wanted by the user?

Anyway, it’s new, and it’s always nice to see a new extension being made. Huzza!

MediaWiki with two database servers

I’ve been trying to replicate locally a bug with MediaWiki’s GlobalPreferences extension. The bug is about the increased number of database reads that happen when the extension is loaded, and the increase happens not on the database table that stores the global preferences (as might be expected) but rather on the ‘local’ tables. However, locally I’ve had all of these running on the same database server, which makes it hard to watch the standard monitoring tools to see differences; so, I set things up on two database servers locally.

Firstly, this was a matter of starting a new MySQL server in a Docker container (accessible at 127.0.0.1:3305 and with its data in a local directory so I could destroy and recreate the container as required):

docker run -it -e MYSQL_ROOT_PASSWORD=pwd123 -p3305:3306 -v$PWD/mysqldata:/var/lib/mysql mysql

(Note that because we’re keeping local data, root’s password is only set on the first set-up, and so the MYSQL_ROOT_PASSWORD can be left off future invocations of this command.)

Then it’s a matter of setting up MediaWiki to use the two servers:

$wgLBFactoryConf = [
	'class' => 'LBFactory_Multi',
	'sectionsByDB' => [
		// Map of database names to section names.
		'mediawiki_wiki1' => 's1',
		'wikimeta' => 's2',
	],
	'sectionLoads' => [
		// Map of sections to server-name/load pairs.
		'DEFAULT' => [ 'localdb'  => 0 ],
		's1' => [ 'localdb'  => 0 ],
		's2' => [ 'metadb' => 0 ],
	],
	'hostsByName' => [
		// Map of server-names to IP addresses (and, in this case, ports).
		'localdb' => '127.0.0.1:3306',
		'metadb' => '127.0.0.1:3305',
	],
	'serverTemplate' => [
		'dbname'        => $wgDBname,
		'user'          => $wgDBuser,
		'password'      => $wgDBpassword,
		'type'          => 'mysql',
		'flags'         => DBO_DEFAULT,
		'max lag'       => 30,
	],
];
$wgGlobalPreferencesDB = 'wikimeta';

New MediaWiki extension: AutoCategoriseUploads

New MediaWiki extension: AutoCategoriseUploads. It “automatically adds categories to new file uploads based on keyword metadata found in the file. The following metadata types are supported: XMP (many file types, including JPG, PNG, PDF, etc.); ITCP (JPG); ID3 (MP3)”.

Unfortunately there’s no code yet in the repository, so there’s nothing to test. Sounds interesting though.

Extension:DocBookExport

There’s a new extension recently been added to mediawiki.org, called DocBookExport. It provides a system of defining a book’s structure (a set of pages and some title and other metadata) and then pipes the pages’ HTML through Pandoc and out into DocBook format, from where it can be turned into PDF or just downloaded as-is.

There are a few issues with getting the extension to run (e.g. it wants to write to its own directory, rather than a normal place for temporary files), and I haven’t actually managed to get it fully functioning. But the idea is interesting. Certainly, there are some limitations with Pandoc, but mostly it’s remarkably good at converting things.

It seems that DocBookExport, and any other MediaWiki export or format conversion system, works best when the wiki pages (and their templates etc.) are written with the output formats in mind. Then, one can avoid things such as web-only formatting conventions that make PDF (or epub, or man page) generation trickier.

Display Title extension

The MediaWiki Display Title extension is pretty cool. It uses a page’s display title in all links to that page. That might not sound like much, but it’s really useful to only have to change the title in one place, and have it show correctly all over the wiki. (This is much the same as Dokuwiki with the useheading configuration variable set to 1).

This is the sort of extension that I really like: it does a small thing, but does it well, and it makes sense as an addition to the core software. It’s not trying to do something completely different and just sit on top of or inside MediaWiki. It’s also not something that everyone would want, and so does belong as an extension and not an addition to core (even though the display title feature is part of core).

The other thing the Display Title extension provides is a parser function for retrieving the display title of any page: {{#getdisplaytitle:A page name}}, so you can use the display title without creating a link.

Printable WeRelate

Last year I wrote a little script for producing GraphViz graphs, and LaTeX books, from werelate.org family history data. I’ve been tweaking it a bit now and then, and using it for my mum’s genealogical research. It works, but the more I want to do with it the more I think it needs a good ground-up refactoring. So, I’ve set to work turning it into a MediaWiki extension, so I can use an installation of MediaWiki as the cache (instead of text files), and update this installation in a separate operation to the tree-generation stuff. (I found that I was playing around with regenerating things more often that I wanted to be waiting for downloading modified data, and it was set to check for modifications if it’d been longer than a day since the last check…) The other big advantage of sync’ing into a local MW is that I’ll have a complete, working, backup of all our data.

The basic idea is that the ancestor and descentant lists, which define the starting points for the tree traversal, will be defined in normal wiki pages, and both the syncronisation and the tree-generation processes will read these and do what they need to do.

I’m setting up a test wiki at http://test.archives.org.au, if anyone’s interested.