case studies (ii): comparing #dokuwiki with #mediawiki


I’ve said on many occasions: I’m not a professional geek in any way whatsoever.

I think, in some way however, I am a natural geek.  That is to say, I like to look at a system and work out how it works – and then make it do the things I need it to do.

This I’ve done with lots of Linux installations in the past: from Red Hat Fedora in 2002/2003 to the Eee PC’s original bespoke implementations for the original netbooks to Ubuntu, of late, on an old Dell desktop.

I’ve also learnt how to use, install plugins, fiddle around with webpages – both HTML and now wiki markup.

dokuwiki vs mediawiki

The two wiki software environments I’d like to discuss today are DokuWiki and MediaWiki.  MediaWiki needs no introduction: it drives Wikipedia amongst many other very big sites.  I think it was specifically designed by those who needed it for these purposes.

DokuWiki is a newer application: technical comparisons between the two can be found here for DokuWiki and here for MediaWiki.  Its intended audience is small to medium-sized companies, mainly for documentation purposes (as befits its name!).

But my experience over at these last couple of months, and now with MediaWiki at [update to this post, 12/04/2015: is now running on DokuWiki – I had to give up altogether on MediaWiki; way beyond my skillset …] would seem to indicate DokuWiki deserves a much wider audience.


If we accept that wiki software can – or even should – form the engine which drives not just a beautiful web (it’s now becoming possible!) but also – more importantly – a beautifully engaged web, it needs to be as simple to install and use as possible.

These are my reactions – at that natural but not professional geek level which I suspect is about as technical as we should aim to get in this brave new world of devolved skills.


MediaWiki is the grand old uncle of wiki software.  But it is incredibly idiosyncratic.  The way it looks needs to be initially fixed by direct access to the server in a localsettings.php file, which can’t be edited by any old editor with any old encoding: you can actually break the whole interface and functioning of the wiki by failing to use utf-8 without BOM encoding and an editor like Notepad++.

Serious usability failings here, I know.

But then it gets even more completed.  MediaWiki has special MediaWiki: pages which contain messages to the system and can be used to modify not only the way things work but also the way things look.  So now we have two radically different places with totally different kinds of commands in order that we might control the way things behave.

Apart from that, what are called skins (a set of visual structures such as navbars, footers, stylesheets and so forth) need to be installed via the server and enabled via the localsettings.php file.  They in their turn can be modified either using css, .php or a combination of both plus the special MediaWiki: system message commands which need to be created and populated with information in the correct formats.

Compare and contrast with DokuWiki: I installed it in a morning, though left it for a while with the default skin (they call them templates) that comes with the site.  I was soon copying and pasting content from Wikipedia, respectful as always with the needs of copyleft and so forth.

At the beginning of April appeared a Bootstrap3 skin for DokuWiki whose installation involves the same graphical user-interface (GUI) as I was using for installing all the other functionality.  (In fact, you can now even upgrade DokuWiki from within DokuWiki – no server access required at all.  For a fan of Windows GUIs, which Linux often thoughtfully interfaces with in its clever approach to gaining adepts, this makes DokuWiki a far easier transition for amateur souls like myself.)

Anyhow.  Functionality in DokuWiki is expanded using plugins (or extensions) which are installed and configured via common GUIs for the whole system.  The WYSIWYG support, with plenty of one-click buttons to shape the markup (ie write the text with the size, font, position and colour you need; add images and video; add maps etc), doesn’t preclude powerful integration of things like columns and round-/square-cornered boxes of different colours.  You can create PowerPoint-style presentations on the fly; download pages in .pdf format … a whole host of lovely things which – despite their adding – don’t make DokuWiki more complicated for the straightforward user to get their head around.


Honestly.  Believe me.  Admin is far more complex for MediaWiki.  Getting your head round fundamental concepts which control the behaviour and functioning of the software is terribly complicated: the documentation for DokuWiki is far more structured and organised around user needs; far less a baleful history of disagreements splurging and taking you on a merry runaround everywhere.  Meanwhile, the markup (ie the text with commands which all wikis use) is much easier to use and generate for a DokuWiki site than for a MediaWiki site, especially for newbies and those who wish to remain so.

But the most important factor I’ve learnt from these past few months is that whilst DokuWiki does what it does in a light, structured, informative and planned way, giving you the sensation you’re working for and with people who have oversight on what they do, MediaWiki makes you feel you’re working for one of those bloated, corporate organisations that find it difficult to marshal their undoubted strengths in an organic and efficient way for the benefit of their employees as well as their end-users/customers.

You look at the highly structured documentation notes for DokuWiki plugins and compare them with the idiosyncratically Wikipedia-style support pages on MediaWiki – an example of bad corporate which anyone who’s worked frustratedly in a such an environment will recognise straight off – and quickly, we have to say “give me efficiency every time”.

I even understand, now, why people sometimes prefer not to work with me.  In many parts of my life, I am idiosyncratic too.

I shall strive to be less so in the future – at least as far as work is concerned … I now see how very demoralising it can become.



  1. […] bit good at working out how systems and software work at a fairly basic end-user level (though MediaWiki – Wikipedia’s engine – continues to have me sorely stumped).   I’m a kind of overviewer – a modern term for an unemployable jack-of-all-trades? […]

  2. Thanks for the run down, I’ve been looking at the two for an internal knowledge base and you’re experiences have matched what I have seen elsewhere.

      • Sorry, should have been clearer! I meant actually being able to tag pages and use tag/category hierarchy. The tag plugin gave me a warning that it was way out of date (not being developed?) and other systems seemed scarce. In the end I went with WikiMedia as it was simpler out of the box. The other thing that really put me off Dokuwiki was the search results it returned. I tried it on your site and the information is far from clear, plus starts mid-sentence or even has the start portion of words missing. This is the same on DokuWiki own’s site.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s