Some Wiki evaluations (finally!)
lizardo at linuxfromscratch.org
Sun Apr 11 21:11:42 PDT 2004
Last week, I installed locally and evaluated the first two Wikis from the
original list (see
plus TWiki (http://twiki.org/). See below why I've inserted TWiki on the
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
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,
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.
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
I found this one when trying to find out how freedesktop.org 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
(http://www.gnu.org/software/rcs/rcs.html). 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
http://twiki.org/cgi-bin/view/Plugins/PublishAddOn). 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 http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules), 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 test.linuxfromscratch.org. It has all features we may
need, specially full ACL support (which I've not tested yet; see
http://twiki.org/cgi-bin/view/TWiki/TWikiAccessControl for a nice guide).
lizardo at linuxfromscratch.org
More information about the website