Pick of the Wikis: Dokuwiki

Been slowly evaluating some of the wiki’s out there over the past few months and going to (dare to) recommend one or two of the PHP wiki’s out there.

The main reason for shopping around is the current WACT wiki, which uses PHPWiki.

While there’s nothing fundamentally wrong with PHPWiki, the more documents and versions of documents you have, the slower it seems to get. Times I’ve tried to research why it’s getting slow, I’ve found the code to be lacking in transparency – could be that’s just me but really not interested in spending a lot of time getting to know the code base. So right now PHPWiki amounts to a “beast” I don’t want to messing around with.

Also, as Jeff mentions;

the wiki markup style seems almost non-deterministic. I never know what the page is going to look at when I edit it.

Another problem (a complaint we’ve had) is the lack of some kind of index / site map. There’s a more than a few pages in WIKI which aren’t referenced anywhere and to only way to make them discoverable is by manually building pages of links (as we’ve done here).

Otherwise, with the PHPWiki code base being a “thing” I don’t think any of us want to touch, we can’t really take advantage of it elsewhere, such as truly integrating the generated API docs with the wiki (there’s a separate blog here about integrating generated API docs with dynamic content,for user comments etc. that I’ll get to another time) or generating some kind of downloadable “manual” from it.

Finally I feel uncomfortable about the content being stored in a database – it makes difficult to modify the WIKI via anything but the web interface among many other things.

Anyway, one or two of the other WIKI’s I’ve looked at (these are all PHP based but others like TinyWiki were very tempting);

- MediaWiki – now Wikipedia is powered by MediaWiki (as they mention here – the ultimate case for PHP and scaling?) which clearly makes it a very strong candidate. It has some great features like docbook export and the code base is generally a pleasant to explore. What I don’t like though is it uses a database again (although it does come with an excellent selection of supporting admin tools) and get the general feeling that it would become “the center of the universe” if we used it, making things like integration with the API docs tricky.

- Yawiki, which is work in progress from Paul Jones who you may know from Savant. In general like where it’s going, particularly the clean code base. It’s using a DB again though and really looking for something more evolved (0.17 last time I looked). Way well take advantage of Text_Wiki when it comes to migrating from PHPWiki though.

- PmWiki is a files based wiki and almost the outright “winner” for what I’m looking for. Get a good feeling about the sanity of the developers exploring the code in the sense that they seem to have used the simplest implementation possible in all cases and I suspect it would scale well, in terms of the volume of information it is managing. Not so good is that keyword ‘global’ which is all over the code. Also I have my doubts about the format content is stored in; it’s a kind of ini-file, which is going to need a specialised parser in addition to the parser for wiki markup. Also changes (diffs) are stored along with the content itself (in a single file) which is likely to result in some pretty big files as a page undergoes multiple edits (note is does store the most recent version of the page as a single entity, which is good – it’s not reconstructing the page from the diffs). Otherwise the markup is similar to PHPWiki’s and may well lead to the problems of determinism again.

- DokuWiki – the more I look at it, the more I like it (the code is here). I think Andreas Gohr, the author, has managed to get the fundamentals exactly right…

+ It’s files based and what get’s stored is exactly what you typed in. That helps a lot if you need to use standard filesystem tools for editing. For example DokuWiki uses the Unix find(1) and grep(1), by default, for searching.

+ It uses namespaces when creating pages. Namespaces relate to the URL. Each namespace is a directory so if my page ID is wact:tags:list it will correspond to a file / directory structure like ./wact/tags/list.txt – that makes it possible to build useful indexes of the WIKI.

+ The wiki syntax looks deterministic plus Dokuwiki comes with an editing toolbar to help with markup and also supports keyboard shortcuts.

+ Old revisions of documents are stored separately in zipped archives. Online diffs are supported.

+ Dokuwiki manages conflicts, when two people are editing the same document, in a similar way to CVS – the second person to save their document is forced to manage the change (with help from a diff).

+ It’s buzzword compliant (CSS, XHTML, RSS etc.).

On the downside, it doesn’t seem to handle i18n character sets yet (which may involve re-writing it’s wiki parser which currently relies on PCRE) but the code base is (surprisingly) small and generally easy to understand – there’s some room from improvement in the code (seen from my angle anyway) but nothing major and I imagine it would be very easy to make changes incrementally. Because the fundamentals are right (in particular the way files are stored) can see myself being able to integrate this with WACT’s API docs.

Whether it scales is also an unanswered question. The index generation, for example, may need some examination and some of the configuration files (like the wordblock file) may need breaking into smaller pieces as they grow. Again, because I think Dokuwiki does the right thing in storing files, tuning it for capacity shouldn’t be a major issue.

Anyway – hope that’s some useful research. Thanks to Andreas for Dokuwiki – any chance of getting it on Sourceforge?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • lsmith

    We are using YaWiki for our documentation. We have added an export script along with some flat file OO.org wiki rules. We can therefore easily export to OO.org including with images, TOC and all.

  • pascal van hecke

    A favorite of mine is tikiwiki http://tikiwiki.org/tiki-index.php.
    The whole thing is probably a bit heavy if you only want a wiki (it’s scope is comparable to the *nuke-alikes), but I like the “structures” feature within the wiki, especially for working on technical documentation.

  • straider

    I’ve evaluated many PHP-based WikiEngines. The final contenders were PmWiki and DokiWiki, because one of the requirements was no DB requirements (which rules out WackoWiki, MediWiki and other great WikiEngines). There’s a comparison table in DokuWiki’s WikiSite, at http://www.splitbrain.org/dokuwiki/wiki:compare, which shows why I choose DokuWiki instead of other WikiEngines. As the author says: Thanks Andi, for this well done piece of software.

  • nucleuz

    Have worked a lot with mediawiki both at work and over at wiki.cc, ( and I did try out a lot of the wiki’s out there before settling on mediawiki in the end ) and I can strongly recommend that one.

    As long as you mark pages with category names there is a way of making categories, like this: http://www.wiki.cc/php/Category:PEAR but no automatic discovery of category like the namespaces mentioned above ( that would be good to see in mediawiki as well ). Anyway; good roundup of the wiki’s out there.

  • http://www.procata.com/ Selkirk

    It would be really nice to convert to a better wiki under active development with fewer bugs.

    The biggest problem I had with the markup non-determinism was inserting PHP code snippets, both multi line and less than one line.

    I just recently put up a mediawiki for another project. It seems to work well. Didn’t look at the code.

    I am not necessarily put off by the use of a database. I don’t think the database is the cause of the slowness, I think its built into the markup conversion. Larger pages means more markup means slower. I could be wrong.

  • Davey

    I’m using YaWiki for the Cerebral Cortex documentation.

    Whilst my preference is somewhat biased, as a PEAR developer used to working with code formatted and stored in a certain way, modifying YaWiki to my needs has been a pleasure (I didn’t modify much, just added a more capable text highlighter and a third level of navigation to the top).

    My only negative experiences with YaWiki was the BC break in recent versions (but its not marked stable, I don’t blame Paul for this, YaWiki is better for it) and when I had to move a page, I needed to edit the DB – though I am sure Paul will fix this at some point.

    Whilst I understand your need for real files, for those who don’t mind using a DB, I wholly recommend YaWiki!

    - Davey

  • lsmith

    arent these the days of sqlite? or is this no database stuff just a preference to be able to easily index stuff? anyways we are quite happy with being able to export the data from the database using any set of wiki rules we get or define ourselfs. especially using the areamaps things couldnt be more flexible.

  • thewebguy

    I know you guys are talking PHP wikis, but if you are more concerned with the wiki rather than with what it was developed in, can I recommend taking a look at Confluence – http://www.atlassian.com/confluence/. It’s a J2EE app but is pretty slick and has a nice feature set. It addresses some of your concerns mentioned here in terms of performance and indexing. They offer free Open Source licenses too :)

  • http://www.phppatterns.com HarryF

    The biggest problem I had with the markup non-determinism was inserting PHP code snippets, both multi line and less than one line.

    I guess to an extent that’s solved with the PHP highlighting plugin.

    I am not necessarily put off by the use of a database. I don’t think the database is the cause of the slowness, I think its built into the markup conversion. Larger pages means more markup means slower. I could be wrong.

    arent these the days of sqlite? or is this no database stuff just a preference to be able to easily index stuff? anyways we are quite happy with being able to export the data from the database using any set of wiki rules we get or define ourselfs. especially using the areamaps things couldnt be more flexible.

    Guess I need to qualify this in more detail, thinking as someone who’s not afraid of the command line (vs. someone who wants a friendly visual interface). It’s not really a question of performance but rather I think the filesystem gives you more flexibility / control where content / documents are concerned, in some cases.

    - Administration is easier with files in general (depending on their contents). In Dokuwiki I could create a new namespace and page like;


    $ mkdir tutorials
    $ vi tutorials/helloworld.txt

    The moment that’s stored, it’s online with ID ‘tutorials:helloworld’.

    Deleting stuff should also be easy. Managing revisions or moving documents is doable although I guess would need some simple shell scripts.

    Against that is DB’s don’t require managing filesystem permissions (which can be a big plus depending on your environment and the skills of those installing).

    - Hierarchical data doesn’t fit so well in a database. Meanwhile content (documents) tend to be structured in some kind of tree and that’s something a filesystem does well. I’ve always found hierarchical relationships in a database lead to performance bottlenecks and are hard to administer without specialised tools.

    More some other time. Someone’s crying…

  • Alan Knowles

    I did start investigating writing a wiki a while back, It’s pretty easy to throw one together.

    After a while though, I realized that alot of the core concepts of wiki’s are seriously flawed.

    a) markup :
    Inline HTML editors are pretty easy to add in these days, and with some clever parsing of the HTML, you get all the theoretical benifits of a wiki, without having to mess around with a non-standard, counter intuative markup language.

    b) auto replacing of Studlycaps with links – rarely works correctly, and generally causes more problems than they solve.

    They do have a few smart ideas, the simple 2 level directory structure is easy to manage and understandable to users.

    Yawiki’s idea of a map file (for navigation management), although it would be better using a xml format+simple editor.

  • http://www.phppatterns.com HarryF

    a) markup
    b) auto replacing of Studlycaps with links

    …like the original design decisions that made these worthwhile are no longer valid? Could be that’s true while everyone’s still copying the original approach because it’s The Right Way.

    I’d personally be happy with BBCode or similar, especially with stuff like Firefox’s BBCode extension.

  • Travis S

    I agree with Alan, a lot of the wiki formatting doesn’t seem to make sense. However, the ability to be able to create a new page just by having a link to it is valuable.

    I would suggest using something like Markdown for formatting (Markdown for the Perl version, PHP Markdown for the PHP port). Makes perfect sense if you’re reading it as plain text.

    The question that’s still unanswered, Harry, why do you want a text-based wiki?

  • http://www.phppatterns.com HarryF

    The question that’s still unanswered, Harry, why do you want a text-based wiki?

    You mean files based? To cut a long story short; because I think, in this case, it will make life alot easier in this case, from the point of view of code maintenance, administration and extending. Think I need to open up a long blog some time to explain.

  • http://maetl.coretxt.net.nz/ maetl

    I agree – I think file based systems make a lot of sense in terms of a ‘resource’ based model of content/server delivery, for text/page based sites or wikis…

    There are some advantages to using a DB in a wiki or a blog, but really, there isn’t a huge need for its relational power (except perhaps for version control/category management)…

    File based systems, whether they use XML or plain unambiguous txt like dokuwiki, seem to form a more logical architecture for this content domain – in the case of WACT, it’s documentation, tutorials, tag summary pages, etc. Its good to keep things as simple as they can be… one txt file for each ‘page’ or one dir for each ‘resource’ probably sounds like the web c. 1994, but it has the real advantage of transparency, which makes things easier for publishing as well as extending development…

  • Richard

    Take a look at Wikka Wiki: http://wikka.jsnx.com/HomePage . It’s simple and fast. I had little trouble figuring out how to extend it. It is database backed, though.

  • Anonymous

    I guess you’d be happy with Instiki. Pluggable markup syntax, no rdbms backend,full transactioning/versioning, export in latex/pdf, rss feed, password protection, keyboard shortcuts.. not php, tough..

  • http://www.phppatterns.com HarryF

    Instiki looks interesting – has some nice features I haven’t seen elsewhere – think the “See Changes” works really well like here.

    Doesn’t have to be PHP but here’s the killer (on Sourcforge);


    $ ruby --version
    ruby 1.6.8 (2002-12-24) [i386-linux-gnu]

  • lsmith

    Well a wiki is not a tree structure of documents by its very nature. Instead its just a ton of documents that can be linked. I think this is a very fundamental idea of the original wikis.

    What YaWiki does is ingenious because it keeps this idea, but allows you to put an optional map over your wiki.

    As to having more control over the wiki if its file based, well I think the benefits are very small, as long as you adhere to the above fundamental idea that you are not going to deeply nest your documents into directories.

    The benefits however are very great. You can have much nicer versioning imho. You get easier access from the outside. You get around the permission management issues.

  • kenp

    If you want an extremely extensible (plugin architecture), very simple, and flexible wiki, try the perl-based Kwiki (http://kwiki.org).

    In terms of set up, it couldn’t be simpler. Create a directory, cd into it, type kwiki -install. Done.

  • Mike Smick

    I’m using PMWIKI on a site and I am really pleased on how easy it was to embed it into a layout. There’s a template file and it’s farily obvious where the modules go. Also you don’t need to use all the modules. I wanted my page to have normal navigation and a wiki nav bar. I also wanted to put things in divs the way I like. Wasn’t a problem. I even eliminated the top wiki editing links and only kept them smaller at the bottom, making it look EXACTLY like the rest of the site. The only problem I encountered is that I had to change the width to my main content div because PMWIKI expanded it slightly and threw off the 3 column layout.

  • anony

    I shared your “which wiki?” dilemma and spent many an hour looking at different engines. My essential criteria were that the wiki engine be simple, well-coded, work with PHP 5, and preferably be attractive. I didn’t prefer database over filesystem storage.

    Like you, I quickly ruled out PhpWiki for its bloat, purported instability, and laundry list of crippling and unattended-to bugs. While MediaWiki has a nice setup, the interface out-of-the-box is lacking; it seemed too bloated for use by a small team. Wikka was simple and pleasant at the outset but its code is amateurish and riddled with bugs (ex: getting caught in “link-loops” where WikiWords get repeatedly appended to links). PmWiki is homely and relies too heavily on “CookBooks” to provide functionality that should be innate. YaWiki’s general methodology and operation didn’t sit right with me.

    I found coWiki (http://develnet.org/) very appealing, particularly for projects requiring heavy documentation and collaboration by a group of programmers. However, the project I was looking to support with this wiki was not technical, so I looked elsewhere.

    DokuWiki was the clear winner for PHP-based wikis with its easy setup, powerful features, attractive appearance, and sensible codebase. However, I felt it lacking in a kind of innate elegance – like coWiki, perfect for programmers, but not for a team of less technical users who likely won’t take advantage of its namespaces and other geeky features.

    So despite my love for PHP, I ended up installing the Ruby-based Instiki. It bothers me mildly that Instiki is its own webserver and doesn’t fit neatly in a LAMP setup, but the sheer pleasure of using it overwhelms any such concerns. I can’t reccomend Instiki enough! Just be sure to set to use Markdown syntax with it, as Markdown is infinitely more intuitive than other wiki markup syntaxes.

  • duncan

    dokuwiki is a *very* nice wiki, I’ve just written a little Python script to port all of my new email into dokuwiki and eventually I’ll get it to wikify all the proper nouns in each message body:

    http://www.suttree.com/blog/2004/10/heading-for-that-sea-port-town-called.html

  • smick

    I use pmwiki for a site and it’s really nice. I had to adjust the CSS file, there was some kind of width issue I had, but i totally put it in my own template. PMwiki, has been the easiest I’ve seen to create a customized look. some of the wiki’s support CSS, and -includes, but PM wiki will let you integrate into your site completely.
    http://www.kcjas.org

  • nauhygon

    I fell in love with DokuWiki because it was so easy to install, configure and maintain. What I would like it to have in the future is a plugin API (like the one WordPress has). So customized formatting for examle can be easily hooked up instead of hack into the “core” code.

    This may be off topic. Since I am also a WordPress lover, I made an attempt to integrate DokuWiki into WordPress. Probably off topic, but if you are interested, check it out: http://www.ezpdo.net/blog/?p=792.

  • Esther Brunner

    DokuWiki is really amazing: easy to install and customize and has a simple yet powerful formating syntax. But I’m looking for a way to use the same formating syntax in all user entry fields on my website, not textile for the blog, bbcode for the forum and dokuwiki syntax for the wiki as at the moment. Any idea?

  • http://www.solutionsphp.com/ solutionsphp

    This blog entry and these comments were exactly what I needed to read today. I’m wavering between MediaWiki and DokuWiki, but I believe this post has just put DokuWiki over the top. I was uncertain about the file based system, thinking it wouldn’t be as robust as MySQL, an found the comments pertaining to this to be quite interesting.

  • Ryan

    I’ve been looking at wikis for several weeks and tried many. I wanted nice diffs, intuitive page editing and toolbar (preferably full wysiwyg). The finalists were MoinMoin and Docuwiki. I’m not sure which I’ll use. MoinMoin has a very, very nice complete wysiwyg page editing tool based on FCKeditor, and since my users come from a word processing background, I think I’ll have to go with MoinMoin.

  • Pingback: ..

  • Paul

    Dokuwiki is fast, easy to install, and I intend to use it with my students to learn how to use a wiki.

  • kellp


    [url=][/url]