DokuWiki: A Versatile Tool for Developer and End-User Documentation

Years ago, I went looking for a way to create end-user documentation for one of my applications.

I looked into the old .chm (Compiled HTML) file format, which is what I believe Access was originally designed to work with.  I found it overly complicated and could never manage to create even a simple proof of concept.

I liked the idea of using a wiki, but I wanted to be able to create an offline version of the documentation without having to maintain two separate systems.  I also didn't like how most wikis used databases to store the page content.  I found such systems too opaque.

As I was considering my options, it occurred to me that I might be able to find a solution for both end-user documentation and developer documentation.

My list of requirements was eclectic.  I resigned myself to having to pick the least bad option.

And then, I found my unicorn: DokuWiki.

Key Features

DokuWiki is a powerful, yet lightweight, wiki software.

dokuwiki [DokuWiki]

DokuWiki

Its unique approach to storing content in plain text files, rather than relying on a database, sets it apart from other wiki solutions.

DokuWiki's key features include:

• Text-file and folder based content management (vs. database storage)
• A simple, intuitive syntax for formatting content
• Built-in access control and user management
• An extensive plugin system

Why I Went With DokuWiki

There were four primary reasons:

1. Text-file and folder-based system
2. Online and offline documentation from one source
3. Free and open source
4. Easily extensible via plugins

Text-File Based

By far, this feature is what sets DokuWiki apart the most from other wikis (at least the ones I researched at the time).  This feature also opens the door to some unexpected and intriguing use cases.

Version Control Integration

Longtime readers know how I feel about version control.

If there's a way to put something in version control, I'm all in.  By putting my documentation under version control, I'm able to maintain synchronized clones of my wiki on all of my local development machines as well as on my web server. Among other things, this means I have multiple backups of my wiki for disaster recovery purposes.

Automatic Help Generation From VBA

The other interesting thing this feature enables is the automatic creation of help files from within Access.

Using an AutoKeys macro and a consistent naming convention, I've set up a system where pressing the F1 key on any open form or report will take you directly to the wiki page associated with that Access object.

I use the labels, tool tips, and status bar properties to create a skeleton of the initial help page on my local machine, then use version control to push the changes up to the web server.  

Watch for more about this in future articles.

Single Source of Truth

The original application I wanted to create online documentation for was a tax collection program that was often used by customers working offline.

We had created an offline user guide in Microsoft Word that we would distribute as a PDF along with the software.  I wanted to make the documentation more context-sensitive, though.  When a user was on the Receipt Form, I wanted them to be able to press F1 and go directly to a related wiki page (for those connected to the internet).  

However, I did not want to have to maintain two sets of documentation.

DokuWiki fills that requirement by way of plugins that allow me to:

1. Create custom "books" that contain sets of ordered wiki pages
2. Convert the wiki pages in each "book" into a PDF that we can provide for off-line access

This gives us the best of both worlds:

• Online AND offline documentation
• From a single source of truth

Open Source

When I was younger, I thought the biggest benefit to open source software is that it was free.  With experience, I've learned the biggest benefit is not being subject to the whims of a third-party that's beyond your control.  Don't believe me?  Ask the legions of VB6 programmers that Microsoft left in the cold when they abandoned the language in favor of .NET.

So, while I like that DokuWiki has no ongoing subscription or licensing costs, I really appreciate that I don't have to worry that one day I might wake up and have to migrate–or worse, completely lose access to–my entire set of internal and end-user documentation.

Plugin Extensibility

DokuWiki is written in PHP.  While the syntax is different than VBA, the procedural style will feel familiar to most Access programmers.  It was relatively easy for me to create a few very simple plugins to fill in some gaps in functionality when I first started using DokuWiki.  

With the advent of AI tools like Codeium and GitHub Copilot, writing code in non-native programming languages is even easier these days.

While it's nice to know you can easily extend the application if you'd like, the good news is you shouldn't have to.  For a relatively niche product, DokuWiki has a vibrant community with a wide variety of existing plugins.

A few that I personally use are:

• IndexMenu Plugin
• BookCreator Plugin
• DW2PDF Plugin (DokuWiki to PDF)
• Image Map Plugin
• ImgPaste Plugin
• Copycode Plugin

One Tool in the Documentation Ecosystem

Not all documentation belongs in a wiki.

In fact, I use at least five six different types of systems for documentation:

1. Wiki
2. Issue Tracker / Bug Database
3. Public Websites (Forums, Stack Overflow)
4. Code Comments
5. Version Control Commits
6. A Programming Blog (like this one!)

5 Types of Documentation

Each type of documentation has unique strengths and weaknesses. Knowing when and how to use each is an important skill for every developer.

No Longer SetMike Wolfe

Hosting DokuWiki

I almost forgot.  You'll need somewhere to host your DokuWiki installation.

I'm a huge fan of Opalstack (it's what I use personally), but any web host that supports PHP will do (so, basically any shared web host).

Plus, since it's PHP, the resource requirements are quite low.

Reader Alternatives

Are you using a wiki for your internal developer documentation?  For your end-user documentation?  Are you using a non-wiki solution for your end-user documentation?  If so, what is it?

Inquiring minds want to know!  

Drop a comment below to let other readers know what alternatives they should be considering.