I have, for some time, been searching for a suitable Content Management System (CMS) to replace a very aging one I have at work. I surveyed a lot of potential open source ones, and finding one that met my requirements was really tough. I was ready to crowdsource suggestions. Then, I found something simple: DokuWiki.
Before I talk about DokuWiki, let me just share a bit of background. That CMS I have at present is built on Drupal 6. Prior to that, I was, as were others, editing HTML files. It was workable in the early ages of the web, but it needed some modernisation when we started creating and managing too much content.
There were already several good contenders at that time. Drupal 6 was chosen. It was brand new at that time. Yes, to be sure, we’re talking about 2008. New, of course, became old. Drupal 7 arrived. I evaluated Drupal 7, and concluded that the upgrade would be a mammoth project for us. Drupal 8 arrived. It’s no less difficult.
Of course our Drupal 6 got more and more out-of-date. It’s almost beginning to feel like manually editing HTML files with vi when the world has moved on to FrontPage or DreamWeaver. Or, maybe in this case, like still using FrontPage when the world has moved on to SharePoint. But moving is tough, and so we continued to be stuck.
On and off, I’ve been checking out to see what else is new. If it was so tough to move to Drupal 8, then perhaps we might as well consider any other type of CMS. The upgrade would mean setting up everything all over again, and porting over content pretty much manually from scratch.
I did go see what Drupal 8 had to offer. I was disappointed. In this day and age, Drupal 8 still doesn’t offer an integrated sort of diff-view of your revisions. One of the whole point of a CMS is to keep track of versions, and isn’t it a really basic expectation to be able to see what has changed between two versions of a document? Yes I know this functionality is available as a Drupal plugin, but you know what, that plugin is still in development at the time I was checking it out, although I note that now as I write this post, a release candidate for Drupal 8 has become available.
One of the big problems I’ve had with Drupal is their plugins. The plugins don’t keep up to the changes in Drupal. Perhaps it is tough for the plugin developers, because Drupal’s core code seems to change too much. This is one of the reasons I can’t easily upgrade my Drupal 6. I really don’t feel like getting caught in this upgrade nightmare again.
Back in 2008, I was highly averse to Joomla. It had a very bad security reputation. But I checked out Joomla again. I expected, as one of the core functionality in a content management system, to have the ability to attach content types that may not be HTML, like for example, PDF files, Word documents, Excel spreadsheets, and Autocad drawings. Unfortunately, in Joomla, file attachment is a functionality provided in a plugin. What?
It turns out that many content management systems are really designed only for webpage management. They might as well have been called a webpage management system. Joomla isn’t the only one here.
Suffice to say, I installed several to try. Concrete5, and Typo3, for example. Everyone had some show stopper.
One common problem is with the structuring of content. I’m not talking about structured content per se, but how content is itself organised in relation to each other. Most systems simply store all content as a simple list of pages, or articles. I, however, want things organised in a hierarchy. I want tree structures. For example, I want a top-level “InfraOps” page, with subpages for, say, “Network”, “Storage”, “Servers” and “Security”. Beneath “Network”, I want, say, “Engineering”, “Maintenance”, “Procurement”, “Projects”, “Recipes” and “Reports”. You get the idea.
Most systems have a way to present their pages in such a structure, but it’s still often the case that the pages themselves are inherently flat, while the structuring mechanism is disjoint and simply a means to display visually. Why is this so difficult to do?
What I want sounds like how a filesystem is organised. You have directories, and files within them. Directories can also contain subdirectories, which can have files as well as other subdirectories. I thought this was just a very natural way to organise things. We can also use tags and other keywords to facilitate search and other categorisation, but inherently, there should be some way to place content in a structure.
I finally got around to looking deeply at DokuWiki one day. Initially, I was quite apprehensive about any sort of Wiki system, and in particular, one that doesn’t require a database. That’s right, one of the features, or oddities as I initially considered it to be, is that DokuWiki requires no database at all. On the one hand, installing it is simpler because it has less dependencies. Yet on the other hand, seriously, no need for database?
Well, DokuWiki’s database is the filesystem itself. All page content is stored as plaintext files in the filesystem. For people so used to using a database in a web app, DokuWiki seems rather strange. I even misuse database as a filesystem from time to time, out of convenience or other reasons. Here, DokuWiki was doing things the other way around.
That’s not to say DokuWiki is wrong about it. There are good, valid, reasons why their choice to use the filesystem is right, and better. I won’t go into that. I just needed a few moments to think about this unusual design before evaluating DokuWiki’s fit for my requirements.
It turns out that DokuWiki works very well for me. It puts content into that structure I talked about earlier. In fact, because page content is stored in the filesystem, that structure literally translates to directories and files. Furthermore, because page content is simply plaintext files, if the web server is down for whatever reason, I can easily directly access the filesystem to get whatever I need. Non-page content (i.e. other attached content such as PDF files) are stored in a similar filesystem hierarchy under a different parent directory. It’s just as easy to find them.
DokuWiki supports rather flexible ACLs. You can do it at page level, or by trees, which DokuWiki calls namespaces. In fact, the inherent structuring of content in hierarchical trees makes ACL setup far more robust than flat systems. We have, more than once, made ACL configuration errors in Drupal 6 because, well, it is so easy to do it wrongly.
Out-of-the-box, the default DokuWiki theme is very pleasant, and perfectly usable. It’s already mobile friendly, adapting its display automatically to smaller screens. It looks to be reasonably easy to customise. Some elements can be changed through the web UI, but even if you have to go into the template files and PHP code, it seems easy enough for an average PHP programmer. Oh yes, it’s written in PHP, like most Wiki and CMS software, but it’s still worth mentioning because there are enough other worthy ones written in Python or Java or something I am not familiar with. (I’m fine with Perl, though, but I think it will be harder to maintain in the long term because there aren’t so many other people who know Perl well.)
The wiki features itself are up to expectations, supporting all the standard markups, automatic table of contents generation, etc. You can install a WYSIWYG editor plugin. You can upload attachments (i.e. other types of content), and ACLs apply to them as well. Again, because those non-page content are organised in the same hierarchical tree, you won’t easily get your access controls wrong. Pretty-diffs are in the core too.
I need LDAP authentication support, and thankfully that is bundled in the core. (I was rather taken aback that LDAP authentication is a paid plugin in Concrete5!)
I’m quite surprised with DokuWiki. The idea of plaintext files as a datastore makes me think the app is rather old-fashioned, but it’s actually still actively developed and rather modern. It’s not fancy for the most parts. But it does what it is supposed to do very well.
I’m still not sure if I’m done searching for the right CMS. However, it looks to me that DokuWiki is a very promising choice.
View Comment Policy