secluded/content/posts/documenting-with-mediawiki.md at 366a9f4f66da4a242c45a8159e9e589affe53b2c

10 KiB

Raw Blame History

title

description

cover

date

URLs

The first thing in LocalSettings.php is $wgScriptPath. Different wikis take vastly different approaches for this. Some fill that variable with "/w" (default), some with "/view", and some with something entirely different. Wikipedia and all of its children use "/wiki". While well and good, the default configuration will have your URLs appearing as example.com/wiki/index.php?title=<page> and this is bad practise for SEO; if you want your pages easily discoverable, the URLs need to be a bit shorter. The easiest way I've found to do this is add all of six lines to my NGINX config and set $wgScriptPath to "" (an empty string).

location / {
    try_files $uri $uri/ @rewrite;
}
location @rewrite {
    rewrite ^/(.*)$ /index.php?title=$1&$args;
}

The snippet above tells NGINX to rewrite all of your site's base URLs and remove index.php?title= from them. This is a similar approach to what Mozilla has done. The result is cleaner URLs that comply with SEO best practises and a setup that avoids moving MediaWiki to the site's root.

Mobile view

I see a lot of MediaWiki instances without a good mobile version and, other than keeping the number of extensions down, I don't really understand why. Setting it up is incredibly easy and gives everyone a much better experience. The Minerva Neue skin is designed specifically for use on mobile devices and is also much more aggressive about optimisation. Though editing is a terrible experience, it also looks great on desktop. The MobileFrontend extension is used to detect the reader's device and serve them either the configured desktop skin or Minerva Neue. You could serve a different skin on mobile but I've found that Minerva Neue looks the best by far.

To set them up, you'll need to download the skin and the extension. From there, you'll need to add a few lines to your config file. On a side note, I love how dynamic MediaWiki can be, especially with downloads; providing a copy/paste extraction command that doesn't use wildcards and puts it in the correct directory is awesome.

# I recommend putting this with the rest of your extensions
wfLoadExtension( 'MobileFrontend' );

# These can go wherever you want but together is better
$wgMFDefaultSkinClass = 'SkinMinerva';
$wgMFAutodetectMobileView = true;

With the skin and extension in place and those lines in your config, save and reload and there should be a link at the bottom of your wiki called Mobile view. Click it and you'll see Minerva! On a phone, MobileFrontend will automatically serve it but you can force your default theme by clicking Desktop view in the same location.

Left is Vector (default) and right is Minerva Neue

Discussion pages

The default discussion page for MediaWiki works but, unless you're already used to it, it can be quite odd for new people. That's where the StructuredDiscussions extension comes in. Here's a comparison of before and after enabling it.

Left is without StructuredDiscussions and right is with

As I said, the left works but most people wouldn't know what to do when given the default MediaWiki editor and it raises the barrier for entry. The right is much more user-friendly and works exactly how one would expect. StructuredDiscussions does have a few dependencies but they're easy to add. Echo is for notifications and the others are included by default. After installing it, and StructuredDiscussions, add the following lines to your LocalSettings.php.

# With the rest of your extensions
wfLoadExtension( 'Echo' );
wfLoadExtension( 'Flow' );

Running the following commands is necessary because MediaWiki's database needs modification to support the extension. General talk pages are --ns=1 and User:Talk pages are --ns=3. If you only want Structured Discussions enabled for one of them, only run that one. I personally recommend doing it for all.

php maintenance/populateContentModel.php --wiki=somewiki --ns=1 --table=revision
php maintenance/populateContentModel.php --wiki=somewiki --ns=1 --table=archive
php maintenance/populateContentModel.php --wiki=somewiki --ns=1 --table=page

php maintenance/populateContentModel.php --wiki=somewiki --ns=3 --table=revision
php maintenance/populateContentModel.php --wiki=somewiki --ns=3 --table=archive
php maintenance/populateContentModel.php --wiki=somewiki --ns=3 --table=page

After that, add these to actually enable the extension. To temporarily disable it, you can comment them out but I don't know how that will affect talk pages that already exist.

# Flow (discussions) configuration
$wgNamespaceContentModels[NS_TALK] = 'flow-board';
$wgNamespaceContentModels[NS_USER_TALK] = 'flow-board';

Subpages

One of the features I'll be making heavy use of for my Privacy Policies and Terms of Service pages is Subpages. This allows you to create pages entitled Parent/Child and the child automatically links back to the parent at the top. This can be seen in Mozilla and Arch Linux's wikis right under the header and in mine as well. Enabling it is quite simple; just add the following line to your config.

## Enable subpages for all namespaces
$wgNamespacesWithSubpages[NS_MAIN] = true;

Syntax highlighting

The final configuration change I've made (so far) has been to enable syntax highlighting in the default editor with CodeMirror. After installing it, add these lines to your config and you're done!

# Place with the other extensions as always
wfLoadExtension( 'CodeMirror' );
# Enables it by default but allows users to disable it
$wgDefaultUserOptions['usecodemirror'] = 1;

Editing in Vim

The final tip I have is that you can edit pretty much any MediaWiki instance in Vim, including Wikipedia itself, with a simple plugin. The only drawback I've found is that, unless you store your password in your config, you'll have to enter it every time you close and reopen Vim. You can also give Vim Wikitext syntax highlighting for creating MediaWiki pages when offline. A few days ago, my wiki was completely offline while taking a disk image backup but I still wrote the majority of the libvirt and Debian pages while I waited and the highlighting was really nice.

This was posted as part of #100DaysToOffload, an awesome idea from Kev Quirk. If you want to participate, just write something every day for 100 days and post a link on social media with the hashtag!

If you're having issues, feel free to contact me and I'll help where I can. ↩︎

10 KiB Raw Blame History