Hands on: Running a wiki
- By Joab Jackson
- Aug 16, 2006
Perhaps the chief benefit of a wiki is that it's easier to update than regular Web pages. You don't need to know HTML, nor do you need specialized Web design software such as Adobe ColdFusion, Microsoft FrontPage or any of a number of different Web content management programs. With those applications, you add content to a copy of a Web page and then upload the finished product to the Web server.
With a wiki, you simply click on the Edit button of a live wiki page and make the required changes right there. No more uploading. Hyperlinking is just as easy'it just requires pasting the URL into the text.
And linking to another wiki page is simpler still. Wiki software automatically creates new pages out of any phrase rendered in CamelCase'compound words with the first letter of each word capitalized. For instance, type 'TestPage' and the wiki software creates a link to that new page with that name ready to edit.Building a wiki'GCN's experiment
However easy to use, setting up a wiki can still take some system administrator chops and a bit of time, if our test run was any indication.
When we set out to deploy a wiki for a small group project, we found no shortage of free wiki packages that we could use. The helpful WikiMatrix (www.wikimatrix.org
) Web site stepped us through a Wizard-like process to determine which best suited our needs. We wanted a free version that could run on a Linux server that we'd leased from a Web hosting company. We had access to Perl and to CGI services, which resided on that server, but did not have access to a database. WikiMatrix returned a list of wiki software packages that met our criteria: DidiWiki, KeheiWiki, KWikiKWiki, MoinMoin, Oddmuse, ProWiki, TiddlyWiki, TWiki and UseMod.
We randomly chose ProWiki (www.prowiki. com). German developer Helmut Leitner created ProWiki and made it available free, but he also offers a commercially supported version.
The software we downloaded came in a 'tarball,' which meant it had to be unzipped in our user account. Overall, the setup took a few hours and consisted mostly of mundane tasks such as renaming and moving folders around and setting permissions for each folder.
Understanding how Unix file permissions work is essential for setting up a wiki. At its most basic, a wiki takes Web-accessible file folders, usually marked as read-only, and changes their permissions for others to write to them. It then provides a set of scripts, in ProWiki's case Perl scripts, that can transform user changes into fully designed Web pages.
Giving the world (or at least everyone on your intranet) universal permission to read, write and execute files on your server is a dangerous proposition. ProWiki comes with a spam-blocking feature that prevents unauthorized users from adding material. The authentication functionality for declaring authorized users is precarious at best, though, since user names and passwords are saved in unencrypted text files elsewhere in the user account folders.
Another time-consuming task was setting up symbolic links. Perl and CGI were available to all users of our Linux machine, no matter what folder they used.
However, we still needed to root around the server to locate Unix utilities such as diff, rm and RCS, all of which the software depends on. Once located, these utilities had to be linked to the wiki folders so that they could be called upon.
We wouldn't advise someone with no Unix experience to tackle a ProWiki installation, but your system administrator should have no problem, even if Leitner's text-based installation instructions were a bit fuzzy in spots. We suspect most commercial wiki offerings, if you budget for them, could eliminate a lot of installation drudgery.