Choosing a New Wiki Engine
For anyone following along my blog entry topics, I have been evaluating Wiki engines for internal use of ITS. Currently, we do have a Wiki — Kwiki. It was a nice first stab at setting up a Wiki, but the system is woefully suboptimal. While it's dead simple to install and use, it's lack of power and features become apparent rather quickly: it's slowslowslow, authentication/authorization options are limited, you can't use dashes in Wiki Nodes (weird), etc.
So, I have been looking to setup a new one. Right now, I have widdled down the field to two contenders: DokuWiki and TWiki, with DocuWiki slightly in the lead.
For those playing along at home, here are my general requirements:
- Must be written in a hack-able language i.e. one of the agile languages: PHP, Perl, Python, Ruby,... Fortran ;-)
- No unallowed character in the node titles
- Clean URLs i.e.
http://blahblah/WikiWordand nothttp://blahblah/index.cgi?style=foo&bar=baz&quux=whuffie... - Must have relatively easy to learn and use Wiki markdown language
- Should be able to include standard HTML tags to supplement or use in place of the Wiki markdown.
- Requires no RDBMS administrative overhead.
- Various means of controlling access to reads and edits
- Diff to previous versions of a node and revert to them
- Search functionality
- Syndicated feeds of recently changed nodes.
- Maybe some other requirements that I can't remember off of the top of my head.
DocuWiki seems real nice. You can check out its locally hosted (thus, biased, but still a bit relevant) Wiki Engine Comparison Chart. But, again, its authn/authz options seem hauntingly limited, too. TWiki, on the other hand, I have witnessed being used underneath a Shibboleth umbrella, so I know its authn/authz features are extendable/customizable.
In the end, though, there is nothing stopping me from digging into the DocuWiki code and getting that to work with Shibb. I'll consider it a learning experience; so that's the way I am leaning.
Post a comment