At the Forge - Bricolage

Over the past few months, we have looked at a number of different content management systems (CMSes) based on Zope. Of course, Zope is not the only game in town when it comes to open-source content management systems. One increasingly more prominent package is Bricolage, written and maintained largely by David Wheeler and based on mod_perl and PostgreSQL.

Bricolage is designed to be used by nontechnical people. True, it takes a fair amount of experience to modify and maintain Bricolage. But, whereas the people who use Apache or Perl generally are programmers or system administrators, the people who use Bricolage the most are the writers, editors and producers of a Web site.

Bricolage also has managed to acquire a fair amount of real-world experience. Apache and Perl needed to prove themselves for many years before they were accepted as part of the mainstream; Bricolage has been part of Salon magazine's CMS for a while, and sites such as eWeek and the Register are in the process of moving over. Moreover, professional publications not often known for their positive views of open-source software recently have begun to evaluate and review Bricolage. Most have found it to be an excellent package, one that rivals proprietary software costing hundreds of thousands of dollars.

This month, we take an initial look at how to install and begin using Bricolage. Over the next few months, we will look at it from a number of perspectives, examining ways in which we can customize and use Bricolage for different types of sites and publications.

The core of every CMS is a database. Commercial CMS software typically uses Oracle or Microsoft's SQL Server as the back-end database server. Many open-source projects, including many of the systems based on PHP, use MySQL. Bricolage, by contrast, uses PostgreSQL for its back-end storage.

PostgreSQL often is known as “the other” open-source database, and it has long supported the notion of a transaction, allowing you to group several database queries or commands into a single all-or-nothing group. PostgreSQL also supports other functionality that serious database operators expect, including views, user-defined functions, subselects, unions, foreign keys and integrity checks. PostgreSQL also supports Unicode, which is increasingly important for handling multilingual sites.

Bricolage uses PostgreSQL for its back-end storage, but the application itself is written in Perl. There are at least two ways to run server-side Perl programs for the Web: CGI, which is slow, safe and portable, and mod_perl, which is fast, potentially unsafe, and works only with Apache. Bricolage works under mod_perl, meaning that its code—which is written as a set of Perl modules—is compiled once, cached in memory as Perl “opcodes” and executed multiple times. As a result, Bricolage executes quickly.

As I mentioned above, mod_perl works only under Apache. Although constant development work is being done on mod_perl for Apache 2.x, you should expect to run mod_perl for only Apache 1.x as of this writing, in early June 2003. Because Apache 1.x runs as a set of processes rather than multiple threads within a single process, no way exists to do true database pooling among the various child HTTP servers. However, keeping an established database connection alive between Apache and PostgreSQL is possible using the Apache::DBI module. Bricolage does exactly this, ensuring that database connections do not need to be re-established each time a user makes a request.

Finally, Bricolage presents its data to the end user with a set of Perl/HTML templates. Many such templates are available for Perl in general and for mod_perl in particular. I have been a longtime fan of HTML::Mason.

As you can tell, one of the reasons I am so enthusiastic about Bricolage is it combines some of my favorite technologies—PostgreSQL, mod_perl, Apache and HTML::Mason—into a single application that is good for end users.

Installing Bricolage is not a simple process. This situation is not the fault of the Bricolage authors or maintainers but, rather, a result of Bricolage using so many different modules from the Comprehensive Perl Archive Network (CPAN). Currently, installation still is not as smooth or easy as it could be, but things have improved over time, with easier installation accompanying each version.

The easiest way to install Bricolage, after you have already installed Perl, Apache and mod_perl—as a static module, not as an Apache dynamic shared object (DSO)—is to use the pseudo-module Bundle::Bricolage defined in CPAN. Normally, you can install a Perl module with the interactive CPAN tool by first starting the CPAN shell with perl -MCPAN -e 'shell' and then typing install Bundle::Bricolage at the prompt. If you are running a relatively recent version of Perl, and if you have defined the environment variables PGINCLUDE and PGLIB, all of the modules should download, compile and install perfectly.

This is a long and involved process, however, and something is bound to go wrong, if you're like me, with CPAN and double-checking that you have installed everything you need by trying one last time to install Bundle::Bricolage. For example, I installed LWP and Bundle::CPAN using the interactive CPAN shell. I then tried to install Bundle::Bricolage; the installation (on a virtual colocation system running Red Hat Linux 7.3) failed for Cache::Cache the first time around but succeeded the second time. CPAN dependencies sometimes can be tricky, and not all modules clearly define and indicate theirs. It also failed on DB_File (because the RPM for db3-devel was not installed), causing problems with the installation of Apache::Session, which in turn caused problems with HTML::Mason, on which Bricolage depends. And, there were problems installing libapreq (because Apache was already running on the same port number) and XML::Parser (because the expat-devel RPM wasn't installed). Luckily, trying to install a CPAN bundle indicates (at the end) which packages didn't install cleanly. You always can try to re-install the bundle, in which case the CPAN shell tells you which modules already are installed and which still need to be installed.

Bundle::Bricolage does not install the Bricolage modules but the modules on which Bricolage depends. So after you have double-checked that Bundle::Bricolage is working correctly, download the latest Bricolage tarball from the Bricolage home page (www.bricolage.cc), open it up and type make. The Makefile checks to make sure all required and some optional Perl modules have been installed, and then asks if you want to install any that are missing. It also checks that mod_perl was compiled statically (and not as a DSO) and that PostgreSQL is installed. Finally, it asks for a number of user names and passwords that Bricolage needs in order to set up its databases and install its HTML::Mason components on the system.

Once you answered all of the questions, you can start the installation with:

make cpan && make test && make install