Some Wiki evaluations (finally!)

Anderson Lizardo lizardo at
Sun Apr 11 21:11:42 PDT 2004

Hi Jeroen,

Last week, I installed locally and evaluated the first two Wikis from the 
original list (see 
plus TWiki ( See below why I've inserted TWiki on the 

1. PhpWiki

Our already-known wiki implementation. It's an example of a traditional Wiki, 
with a simple authentication mechanism as WikiCulture mandates. I specially 
like its simple and easy to learn formating rules. Easy to install, and has a 
friendly default interface. OTOH, I found PhpWiki's documentation spare and 
sometimes hard to understand.

From the original requirement list for our CMS implementation (without 9 and 
11, as requested):

- The generated website should be mirrorable without requiring the CMS 
on the mirror (eg. generate static pages)

Can be done by using "Dump pages as XHTML" feature from PhpWikiAdministration 
(BTW, be cautious with this feature, if used by non-Admins it can largely 
increase our montly bandwidth usage)

- It should manage all our content so I don't have to edit all files if 
I want to add a header element.
- Total freedom in the templates (eg. no fixed content and valid markup 
by default)

It has templating support as you may already know ;-)

- Readable URL's

Yep, If properly setup.

- Poll system

Yep, through plugins.

- Version control of the content (or integratable into CVS)

Yep, though I found it a bit weak. Eg. it doesn't have indefinite revision 
storage like CVS.

- The possibility to hook our search system, user database, CVS 
changelogs, Wiki, etc. into it. Extendability and well-defined interfaces.

I don't see how it _cannot_ be done.

- It should allow a user policy similar to Wordpress (eg. admins, 
category owners, category news poster)

Here is the problem. Although the current CVS version has some code to manage 
ACLs, it is not enabled by default and, when I tried to enable it, it didn't 
work. So this is a major point against using it as our main wiki system, as 
this was a requirement to achieve major acceptance and, of course, security.

- It should be Open Source and be actively maintained


- Automated and customizable RSS generation (for different categories, 
all-in-one, etc.)

Not necessary? As you've said, the website may become less news oriented. This 
way, I think we should use the RSS format to write the actual news items, and 
then use RSS agregation (which most CMSes and Wikis have) to integrate the 
news on the site.

Conclusion: I suggest we don't use it as our main wiki installation (i.e. to 
maintain the website). As I could remember, the ability to control who and 
what can be modified on certain pages was a plus to achieve more acceptance 
of the Wiki inside the comunity, and this is not PhpWiki's strength. Note 
that I'm not suggesting to lock down all pages for edition, but IMO we should 
at least have this ability in hands if we decide it's necessary to do so.

2. TikiWiki

Not actually a Wiki, but a CMS with a Wiki plugin. Very easy to install, 
various nice features, but I don't think we should use it, as we are not 
looking anymore for a traditional CMS. Even if we still wanted a 
full-featured CMS, there are other CMSes (like Plone :) which are better than 
TikiWiki, IMO.

3. TWiki

I found this one when trying to find out how made a so good 
wiki-based website that, at a first look, doesn't look like a wiki. So I 
discovered they've used TWiki (and not TikiWiki :) to accomplish this.

TWiki is a classic, but still featureful, Perl wiki implementation. In resume, 
it has all PhpWiki's features plus those PhpWiki still plans to have (like 
ACL, including per user and per group permissions). What I most liked was its 
subtle bar having the Wiki-related operations (Edit, Attach, Diffs etc.). 
Removing that bar, you have no way to indentify the site as being managed 
with a Wiki.

Another very interesting feature of TWiki are the "webs". You can split the 
Wiki installation into webs which are like sections. We can have webs like 
LFS, BLFS, HLFS, FAQ and so on, each one having different admins. The 
built-in search engine can also limit the range of webs to be searched, so 
you can search only on LFS and BLFS, for example.

The installation is somewhat complex, because it envolves many steps (but all 
very well documented). There is no need for a MySQL database, each topic 
(i.e. Wiki page) has its own file on a special data directory.

Revisions are managed through the rcs 
( rcs is very similar to cvs, but 
has no central repository. The files under revision control have an 
additional <filename>,v file which stores revision information.

Mirroring can be done by using the PublishAddOn plugin (see Although it seems to be 
mainly designed to convert pages to HTML on a per-page basis, we can modify 
it to make a standalone script that periodically converts the entire website 
to static HTML for mirroring.

Some things I didn't like on TWiki (they all have solutions, though :): the 
default template is ugly, but I'm sure we can fix this; its formatting rules 
are not so intuitive like on PhpWiki (it's a matter of personal taste, 
though; see, but we 
can add some more simple syntax if we feel necessary.

Conclusion: I think TWiki should be our first Wiki installation to be 
publically tested on It has all features we may 
need, specially full ACL support (which I've not tested yet; see for a nice guide).

Anderson Lizardo
lizardo at

More information about the website mailing list