TWiki Extensions and Other Wikis

In last month's LAMP Post column (available online at http://www.linux-mag.com/2002-12/lamp_01.html), we looked at TWiki, a popular web collaboration tool. This month, let's dig a bit deeper into TWiki, and consider TWiki alternatives.

In last month’s LAMP Post column (available online at http://www.linux-mag.com/2002-12/lamp_01.html), we looked at TWiki, a popular web collaboration tool. This month, let’s dig a bit deeper into TWiki, and consider TWiki alternatives.

You may recall that TWiki bills itself as a “platform for collaboration.” What makes it a “platform” rather than a mere “application” is that anyone can extend it, build upon it, change its appearance, or otherwise modify it’s behavior.


TWiki plugins are the most common way users add features to TWiki. Plugins are to TWiki what PHP is to Web development: plugins provide easy access to the rest of the non-TWiki world. You can write a plug-in to add new syntax, interface with a proprietary database, or do just about anything you want. After all, plugins are just Perl code, and Perl is a very powerful language.

To get an idea of what plugins are already available, start with the TWiki Plug-in Repository (http://twiki.org/cgi-bin/ view/Plugins/WebHome). The Repository has an official list of TWiki plugins, instructions for writing your own plugins, and more.

The variety of plugins is impressive. As we go to press, there are over 50 plugins available, representing a wide range of enhancements. Here’s just a sample:

  • The BugzillaLinkPlugin makes it easy to link to Bugzilla (http://www.bugzilla.org). Once this plug-in is configured with information about your Bugzilla server, you can easily link to bugs using syntax like %BUG{123}%, where “123″ is the bug number.

  • ChartPlugin, a charting plug-in, can generate PNG and GIF images on the fly to visually represent data that’s already in a table in your TWiki.

  • The DatabasePlugin harnesses the power of Perl’s DBI and provides read-only or read-write access to data stored in just about any relational database (e.g., MySQL, Oracle, PostgreSQL).

  • Using the Headlines plug-in, you can dynamically pull RDF Site Summary (RSS) feeds from other Web sites and display the resulting headlines in TWiki. The plug-in has several configuration options, but it can be as easy as adding %HEADLINES{ href=”http://slashdot.org/slashdot.rdf” }% to display the latest headlines from Slashdot.

  • There often comes a time in on-line projects that decisions need to be made. The easiest way to collect input may be to use a simple poll. That’s just what PollPlugin does for you.

  • The SablotronPlugin allows you to harness the power of XML and XSL to generate HTML on the fly in TWiki. After storing some XML data in one TWiki topic and an XSL style sheet in another, you can ask the Sablotron plug-in to call XML::Sablotron and render the data as HTML.

  • Probably the most needed plug-in, SpellCheckerPlugin provides an interface to check the spelling of TWiki content. It can use either ispell or aspell behind the scenes. (Why don’t more web browsers come with built-in spell-checking?)

Graphics, networking, database support, XML, and more. TWiki’s growing list of plugins is a great resource when you’re looking to extend TWiki’s reach into your existing infrastructure.

Installing plugins is usually a three step process:

  1. Download the plug-in.

  2. Unzip the plug-in in your TWiki directory. All plugins are distributed as zip files that assume a standard TWiki file layout. If you’ve heavily modified the file locations of your TWiki install, you may need to do a bit of hacking to get plugins working properly.

  3. Test and optionally configure the plug-in.

It can’t get much easier than that! Well, self-installing plugins would be nice, but that’s probably a bit too dangerous.

Creating a Plug-in

Having a repository of plugins is great, but a corollary of Murphy’s Law dictates that, “You’ll need a plug-in that hasn’t been written yet.” When that happens, don’t worry. Writing a new plug-in is not difficult.

The TWikiPlugins topic (http://twiki.org/cgi-bin/view/ TWiki/TWikiPlugins) describes the plug-in API, explains how to get started, documents plugins extensively, and describes how to bundle your plug-in for distriibution. Let’s look quickly at what you need to know.

TWiki comes with three plugins: DefaultPlugin, EmptyPlugin, and InterwikiPlugin. The Empty plug-in was designed to serve as a skeleton for writing your own plugins. The other two can serve as working examples of live plugins. Read them over to get a feel for how TWiki plugins are coded.

Plugins, at the most basic level, are made up of a Perl module (a .pm file) and a text file (.txt) that documents your plug-in. It’s best to start with the Empty plug-in as a template for your own. To do so, copy its Perl module to your own:

$ cp lib/TWiki/Plugins/EmptyPlugin.pm \ lib/TWiki/Plugins/MyPlugin.pm

The Empty plug-in is heavily commented, and seasoned Perl hackers should be able to jump right in and start coding. First, the plug-in contains a list of subroutines that exist in most TWiki plugins:

initPlugin ($topic, $web, $user, $installWeb)
commonTagsHandler ($text, $topic, $web)
startRenderingHandler($text, $web)
endRenderingHandler ($text)

Each of the routines serves as a callback that TWiki calls at the appropriate time. Only initPlugin() is required. Notice that it’s called with a fair amount of “context” — those arguments are required so it can perform any initialization tasks necessary. Since TWiki is often run under mod_perl, be mindful of what you do in initPlugin().

The remaining callbacks are called at various times during the process of rendering a request in TWiki. In each case, you’re given $text, which contains the text in question.

If your plug-in needs additional files, place them in a directory named lib/TWiki/Plugsins/MyPlugin.

To interface with the rest of TWiki, you’ll need to familiarize yourself with TWiki’s core API functions, provided in lib/TWiki/Func.pm. It contains over 40 functions, many of which are useful for getting additional information about the topic or URL being viewed.

You can read more about the TWiki Plug-in API at http:// twiki.org/cgi-bin/view/TWiki/TWikiPlugins#PluginAPI.

After you’ve written a useful plug-in and gone to the trouble of documenting it, consider making it available to other TWiki users on the TWiki.org web site.


Plugins are not the only way in which TWiki can be extended. Add-ons are larger packages that add significant features.

A good example add-on is GenHTMLAddon (http:// twiki.org/cgi-bin/view/Plugins/GenHTMLAddon). It provides a way of generating a static HTML snapshot of your TWiki topics. This is helpful in cases where TWiki cannot be run directly — maybe because of a corporate firewall, or because you’d like to burn the TWiki content on a CD.

MailInAddOn illustrates yet another way to integrate TWiki into your existing infrastructure. MailInAddOn provides a mechanism for submitting topics to TWiki via e-mail.

One of the most intriguing TWiki add-ons is the WebServicesAddOn. It’s relatively new, but has a lot of promise. The goal is to expose many of TWiki’s services as Web services. Doing so opens up an entirely new way of interacting with TWiki. Imagine being able to write Python, Ruby, or even Visual Basic .NET code to manipulate TWiki content without having to resort to “screen scraping.”


To make TWiki feel like it’s part of your organization, it ought to look like the rest of your web content. Luckily, you can create skins or SkinPackages (http://twiki.org/cgi-bin/view/ Plugins/SkinPackage) for TWiki.

Skin packages customize the overall look and feel of your TWiki content. By customizing the headers, footers, and style sheets you can go a long way toward making TWiki fit in with the rest of your site.

As with plug-ins, it’s best to start with an existing skin package and modify it to your liking. Documentation for creating your own TWiki skins is available at http://twiki.org/ cgi-bin/view/TWiki/TWikiSkins.

Other Wikis

Though we’ve spent two months looking at TWiki, it’s by no means the only Wiki in town. It seems as if a new Wiki clone appears every month or so. Many Wiki clones are written in Perl, but quite a few have also been developed in Python (often in conjunction with Zope), PHP, and even Ruby. A few brave souls have even built Wikis using C or C++. There’s even a Wiki build to run within Emacs (further proof that Emacs really is an operating system).

There are groups and individuals experimenting with combining Wiki technology and more traditional content management systems, discussion boards, and even weblogs. The resulting hybrids are sure to be interesting.

Jeremy Zawodny uses Open Source tools at Yahoo! by day and is writing “Advanced MySQL” for O’Reilly & Associates by night. Reach him at: Jeremy@Zawodny.com.

Comments are closed.