Experimenting with DokuWiki

Wikis are just one more thing I’ve always wanted to play around with. And my job has, once again, afforded me the opportunity to do just that. We’re currently using an engine called DokuWiki, so I decided to kick its tires and see what it — and wikis in general — are all about.

DokuWiki’s front page describes it thusly:

“DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required.”

No Database
That last little bit — the lack of a database — is actually one of the things that makes DokuWiki unique. It is both its strength and its potential weakness, and one of its defining characteristics.

DokuWiki

DokuWiki

If you are looking to install a documentation engine for a small to medium-sized workgroup, it’s true: DokuWiki is great. It’s very easy to install and only requires Apache and PHP be running on your server. This means it can be installed on any Mac OS X machine without having to install or configure much beyond Personal Web Sharing. I say, “much” because you will have to activate (not install) PHP, which isn’t too hard for savvy users, but isn’t exactly mom-friendly either. Still, it beats having to also install and enable a database application like MySQL, which most other wikis require. So DokuWiki is relatively easy to setup.

That lack of a database is nice, in that it makes installation quick and easy. But it’s also a potential drawback, albeit a minor one. DokuWiki writes all its entries to flat files and that could affect scalability, and to some extent performance, if your wiki ever became extremely large. The merits of databases vs. flat files for storing data are debated all over the Internets, but databases usually only offer a significant advantage when dealing with complex, relational data, and that advantage is usually only seen by the developer. For small to mid-sized or even large-ish sites, DokuWiki is great. If you’re worried your wiki might need to grow very large some day (like, to the point where load balancing across multiple servers is required, for instance — we’re talking big!), DokuWiki may not be for you. Otherwise, the flat file system offers additional advantages, like easy-to-parse and repair backups, to name just one.

Wherefore Wiki?
That said, once installed, DokuWiki is very easy to use. It does use its own markup for page layout, but that markup is exceedingly sensible and easy to learn. My biggest stumbling block was getting started: How do you create a page? Well, once you know, it’s pretty simple, but figuring it out took me a minute. The easiest way to create a page, is to navigate to that page. If the page doesn’t exist, DokuWiki allows you to create it. See? Easy! Maybe too easy!

So what’s it for? Well, I’ll tell you, TASB was almost a wiki rather than a blog. While both are types of Content Management Systems (CMSes), and essentially do the same thing — allow a person to easily and rapidly build and read a structured store of text and media data — the difference is intent.

Blogs — and therefore blog engines — are geared toward personal, diaristic, periodic writing. They’re usually organized chronologically, like a diary, and require no special markup when creating entries. Entries, once made, are rarely revised. One of the things I enjoy about writing this blog is that it’s a bit more personal. It’s a record of personal experience as much as, if not more than, documentation. So I stuck with using the blog format. I like to be chatty.

Wikis, on the other hand, are made to be accessed like a reference, like an encyclopedia, for instance. They’re not chronological, but are usually ordered and read alphabetically; and wiki articles are made to be maintained and updated as information changes. Wikipedia is a great example of this. There is also a blog called the Tao of Mac that uses a wiki engine for content management, showing that, in the end, the two types of engines do essentially the same thing. They simply present different capabilities to their users based largely on the purpose of the site.

Conclusion
If you’re looking for a quick, easy-to-use and easy-to-maintain storehouse of information (either for yourself, or for use with others), a wiki is a great thing to have. Need to document a procedure for your workgroup? Put it on the wiki. Need to let everyone know where that essential file is? Put it on the wiki. Just want to jot down some notes for the general use? Put ‘em on the wiki.

After using one for a few days I can already see just how damn handy a wiki is to have. And DokuWiki is super-easy both to install and learn. If you just need something small to document procedures or productions — or if you’re just looking to dip your toe into the world of wikis — DokuWiki is very nice indeed.

UPDATE:
I’ve edited the article for clarity and accuracy regarding the use of flat file systems vs. relational databases. Thanks to DokuWiki’s author for pointing out the error.

9 Comments

  1. Lewis
    Posted June 26, 2009 at 10:59 AM | Permalink

    My trouble with wikis has always been getting everyone involved. A wiki is only as good as its contributors.

  2. Posted June 26, 2009 at 5:25 PM | Permalink

    > DokuWiki writes entries to flat files, which is much slower than writing to a database.

    *sigh* what do you think where databases store their data? That’s right – in files. There is nothing faster then storing a text in a plain text file on your hard disk (except storing in memory which isn’t exactly storing ;-) ). Databases do have some advantages also for wikis. Storing a text for sure isn’t.

    Read more about the reasons for not using a database in DokuWiki here: http://www.dokuwiki.org/faq:database

  3. Aaron Griffin
    Posted June 26, 2009 at 5:40 PM | Permalink

    As a proof of concept, make a DB with a single table, one column, and dump the contents of a large text file there.

    Now compare the time it takes to ‘cat’ said file, and to query it from the DB

  4. Posted June 27, 2009 at 11:58 AM | Permalink

    I use doku exclusively for system documentation, and then rsync the files back to my laptop. That way if we have a catastrophic failure in the most extreme sense all the txt files are human readable on my laptop to start rebuilding things.

  5. Posted June 28, 2009 at 11:08 AM | Permalink

    Andreas,

    I *really* don’t appreciate your snarky, condescending attitude. I just wrote a very flattering, positive review about your wiki engine and you sound annoyed with me over a single, extremely minor factual error.

    If you have a problem with something on this — or any other — blog, it’s appropriate to leave a polite comment describing the issue of contention. I always do my best to correct any errors on the site. But your exasperated sighs and condescension are not appreciated and will not garner any sort of action from me on the main article.

    That sort of behavior is borderline trolling, and the next time it happens I will ban you from commenting here. Because, frankly, I’m sick of it. And I’m not putting up with it anymore.

    -systemsboy

  6. Posted June 29, 2009 at 1:44 AM | Permalink

    I’ve used Dokuwiki a (small) number of times and found it excellent. I particularly like the way it allows you to easily include a contents box on the page – great for long pages!

    I’ve also found a number of excellent plugins for it.

    I’d recommend it.

    (BTW – I agree with your reply to Andreas’s comment)

  7. Posted June 29, 2009 at 8:38 AM | Permalink

    Yes, I like that feature as well. DokuWiki is great for rapid site documentation. It’s pretty amazing how fast you can get a great deal done. And it comes out very readable as well.

    Although I haven’t had a chance to play around with the plugins, a colleague of mine has done some nice things with some. There are certainly some additions that make the product more useful than it is out of the box, and I’ll have to check them out at some point.

    -systemsboy

  8. Posted June 30, 2009 at 2:30 PM | Permalink

    Hey systemsboy, I apologize if I came across too snarky. It’s just that I read that “databases are faster than filesystem” again and again and nobody seems to even think about that. I just wanted to straight that out, especially because you call the lack of database a “weakness”. Again, my apologies if I stepped on your toes.

  9. Posted July 3, 2009 at 6:29 PM | Permalink

    Andreas,

    Thank you for the apology. It’s much appreciated. I will amend the article to clear up the confusion as soon as I get a chance to read up more on it.

    I have to admit, I’ve heard that databases are faster than filesystems a lot too, and I was really just parroting back what I’ve heard. I’m glad to get a little better educated on the matter, particularly as I begin building and using sites that use databases.

    No hard feelings!

    -systemsboy

Post a Comment

Your email is never shared. Required fields are marked *

*
*