Dokuwiki – The Canonical Wiki

Dokuwiki, over the last 10 years, has become the canonical wiki. By this I mean that Dokuwiki is the go-to wiki for most uses. While there are many other wikis which are popular and in use (e.g., Xwiki, MoinMoin, TikiWiki, etc.), the competitors (other than Mediawiki) do not exceed half of Dokuwiki's popularity. The only real competitor in terms of global mindshare is Mediawiki, and the only reason for that is of course Wikipedia and the other wiki properties run by the Wikimedia foundation. Since Mediawiki is pretty much a shit show when it comes to management and resource consumption, Dokuwiki is the winner by default. Even with such a behemouth as a competitor, Dokuwiki has reached the point where it has more than half the generic searches in Google worldwide compared with Mediawiki. That said, overall attention on wiki software as a category has declined over time, perhaps by half in the past 5 years for Dokuwiki (and much more for Mediawiki). The wiki as a communication tool has many competitors these days, especially in terms of enterprise and cloud-based groupware. That said, the main reasons for the ongoing success of Dokuwiki, I believe are threefold: - Ongoing, consistent, quality, incremental updates; - Community-friendly architecture for plugins and themes; and - Minimalist resource requirements that includes a flat file-only data store option (as standard).

Wiki vs. Blog

My own emerging use case is something that I tried to do years ago with Mediawiki, but because of the nature of Mediawiki (impoverished community and technical incompetence), it ended in tears. That is, as of now, I intend to replace websites which have been maintained on a multisite Wordpress (+ Woocommerce in some cases). A Dokuwiki-based wiki farm along with a third party ecommerce service (Gumroad) should make things simpler, easier to maintain and extend, and escape MySQL hell. Note that I also intend to migrate off of a Mediawiki installation as well, but the multi-site blog replacement is as much of a pain point as the current Mediawiki is.

Desired Functionality

There are quite a few functions/services that are needed for full-fledged sites, including the following: - robots.txt - sitemap.xml + notification on updates - commenting system - user accounts, including email alerts, password mgmt - page and topic subscriptions - rename/rewrite/redirection on page name change - analytics (GA) - caching - ecommerce - Markdown extra - youtube video lazy load - anti-spam - contact form - quotes collection - widgets - cookie notice - seo metadata (Title, Description, norobots, noindex) - search (usable) - multi-site support -

File Locations

  • /etc/nginx/nginx.conf

Pre-Dokuwiki Installation

Some kind of Web server and some (recent) version of PHP. I used to use Apache and MPM Prefork with Opcache and Php 5.6. As of now it is Nginx with Php 5.6, PHP-FPM and APC Cache. All of these are hosted on AWS, either EC2 or Lightsail (preferably). For full instructions, see: - OpenVPN on Amazon Linux, and - Amazon Linux, Nginx, LetsEncrypt, PHP.

Dokuwiki Installation

Dokuwiki Configuration

Dokuwiki Architecture

Dokuwiki Farms

Important Dokuwiki URLs and Location Info

  • `` -
  • `` -
  • `` -
  • `` -
  • `` -

Limitations of Dokuwiki vs. Mediawiki

Limitations of Dokuwiki compared with Mediawiki, what can Mediawiki do that Dokuwiki cannot: - Dokuwiki cannot read DJVU files and generate images and pages that can then be edited using the Proofread extension. This is a key part of the workflow on Wikisource. I think that's it.

Comments are closed.