Using DokuWiki is fun. It gives you all you need to manage different types of content like common text, quotes, files, data tables and source code. It displays your content in a proper way, including typography replacements and many other features (see Syntax for some examples). It is especially perfect to write about IT where console output or code snippets matter. You can even include RSS feeds and create galleries with a single line of text. Additionally, DokuWiki is very easy to administrate and maintain (this is my personal killer feature). Installing updates is damn simple (in principle, you just have to copy the new files over the old ones). And you can do backups by downloading everything from your webserver. No database dumps and stuff needed. Because plain text files are used as storage, you can even access the raw data offline with a simple text editor.1) So why not using DokuWiki as easy maintainable blog? Exactly!

There are two common ways to create a DokuWiki based weblog. The traditional one, using the Blog plugin in combination with a bunch of others.2) And the new BlogTNG plugin which is meant as successor of the Blog plugin and already contains components like comments and tags. The following text is about creating a cool WikiBlog with BlogTNG.

which is perfect e.g. if you screwed your webserver and documented its configuration in the wiki running on it. Just open the last backup and access the text files you need in the pages subdir of DokuWiki's data directory

Creating templates for most web applications is not really a hard task. But if you plan to share your work with the public you face a little problem every now and then, namely when there's a new version of the application available: you have to track down what has changed since the last release to be able to update your template accordingly. Sure, not everyone has the time to follow the development of an application close enough to notice every small change which affects his work. IMHO that could be the cause why some of the available DokuWiki templates are a little outdated and likely not 100% compatible with the latest release. However, I would like to show a way to take advantage of DokuWiki's stylesheet handling and to keep the effort needed to keep such a template up-to-date at a minimum (we're all lazy people, right ).

Creating a new template

The easiest way to create a new template is the Starter template by Anika Henke.3) Just download and extract it. Rename the folder, place it below <dokuwiki>/lib/tpl/templates and select it in the DokuWiki configuration manager.

The idea: taking advantage of DokuWiki's CSS handling

DokuWiki provides an advanced CSS handling system which uses a PHP .ini file named style.ini, which is part of the template. It is used to determine which files are getting loaded for a certain display mode. So lets have a look at the style.ini provided by the Starter template. Right now we're interested in the first section of the file:

The above describes which .css file gets loaded for a certain display mode. “screen” is the normal display mode when you watch the page in a browser, “rtl” is loaded for right-to-left languages, and “print” obviously when you like to print a wiki page.4) For more information regarding the loading order of stylesheets refer to the docs.

So here is the key part:

We're not gonna edit any of the .css files we copied over from the Starter template!

We just add our own .css files for each mode at <dokuwiki>/lib/tpl/template/<mytemplate>/css instead and modify the style.ini so they get loaded after the original ones:

Instead of editing any of the .css files we copied over from the Starter template we add our CSS rules to the files we just created and make use of a key CSS feature: the so-called cascade.5) Expressed in simplified terms, CSS rules simply override previous rules affecting the same element.6) And in some cases where the specificity of your rule is not enough, you may use !important7) or an own class to solve such problems.

So we just override any Starter template CSS rule we like to change in our own mytemplate_screen.css, mytemplate_rtl.css and mytemplate_print.css. Developing a stylesheet this way is a little bit more advanced than if you just edit the existing .css files. But it has an advantage as you'll see later. Additionally, you may noticed that I removed some original Starter template files which are not starting with an underscore (basic.css, structure.css, design.css, content.css and includes.css). The reason for this is simple: only the files starting with an underscore plus rtl.css and print.css are the important core styles, the rest is supposed to be adjusted. Therefore use them as starting point for your own mytemplate_screen.css.

Another thing you may like to consider while modifying DokuWiki's CSS is that it is best to access the elements the same way as done in the Starter template CSS files and prepend most ids or classes with .dokuwiki. And have a look at the color placeholders. If you happen to edit the main.php of your template to add or edit something you shouldn't remove the <div class="dokuwiki"> as it will break the whole stylesheet!

To get a clue about which rules to overwrite, it may help you to look at the CSS files of my templates prsnl10 and mnml-blog:

As you may have noticed, this approach has one drawback. The size of the final stylesheet delivered to the browser will be bigger than if you just edit the existing .css files. This should be around ~2kB till 15kB (uncompressed), depending on the things you are changing. Since the whole CSS gets compressed and is usually delivered only once and then cached I don't think it's that much of a problem.8) And it is not “unclean” or something like that because the Wiki's data is not affected and a template is not triggering any dependencies for your data in general.

Keeping It Up-To-Date

If you follow the approach given above, keeping your template up-to-date after a new DokuWiki release is a task that can be done very quickly! The only thing you have to do is to run a diff against all .css files you copied from the Starter template against the original ones (or have a look at the Commits, e.g. if you are not familiar with tools like diff). Checking the Starter template changelog is also a good idea. If there have been changes, just copy the changed .css files of the Starter template to your template folder overriding the old ones, and, only if needed, add some extra rules to your custom .css files to adjust everything to your needs. The best place to check if everything is OK is the syntax page included in every DokuWiki release.9) It is also recommendable to have a look at the .php files provided by the Starter template to determine if there are any changes needed for new features. The official Developers Changelog may help you to support new features, too.

Some additional notes

That's it! At least this approach works pretty well for me . Of course this only covers CSS issues but it assures that things don't get totally messed up. If you've added new functionality to a template you surely have to put more time into testing/debuging things. But if you create a different look for DokuWiki and like to share it, this is one way to keep things easy over time. Keeping things maintained is normally much harder than creating something new, therefore the additional work when starting a new template should pay off quickly. The approach is even powerful enough to make things like vector10) or this blog's template mnml-blog possible without getting to much trouble when a new DokuWiki version was released.

In the past, the best way to start an own template was to copy DokuWiki's default template. The reason is simple: there was no such useful thing as the Starter template. Therefore all of my existing templates were based on the default template CSS. But things changed a bit. First of all, DokuWiki will get a new default template called “dokuwiki” in the near future. Therefore I asked on the mailing list if it is better to use the “Starter” template CSS or wait for the new “dokuwiki” template CSS as technical base for the development approach described in this text. And the answer is clear: use the Starter template as the new default template is based on Starter, too. Therefore I switched all of my templates over from the old default template CSS to the Starter template CSS as technical base.11) I'm sure a comparable situation won't happen again. Relying on the default template simply was less future-proof than relying on the now existing Starter template which is just existing to make template developing easier.

This post is based on a text created by Michael Klier. He decided to shut down his blog. The unmodified text was originally posted on August, 16th 2007 and is licensed under the Creative Commons BY-NC-SA License and accordingly this text also is. I just took his post and changed the needed things to fit the facts of 2011.

Tip: open two tabs in Firefox (one for the old, one for the new version) and use Ctrl+Page↑ / Ctrl+Page↓ to quickly switch between them for a comparison. Use the headline navigation (e.g. :wiki:syntax#tables) to jump to the exactly same point in both versions.

WordPress 3.0 is out. Normally, nothing important to me because I never used WP for blogging or something else (I don't trust its security). But now, I'm puzzled: The new default theme “Twenty Ten” got a very similar look and feel compared to my “mnml-blog” DokuWiki template I created for this blog.

Don't get me wrong: No one copied something from someone. I saw “Twenty Ten” the first time today after reading the article about WP 3.0. Additionally, I'm pretty sure no WordPress developer ever visited my small blog and “Twenty Ten” was started far before I began to develop “mnml-blog”. But it is frustrating to me that thousands of blogs will now look similar to mine. Argh.

However, I have to live with it. It took a few days to create “mnml-blog” and I'm still very happy with it's look, therefore I will keep it. Shit happens.