At the Forge - Bricolage

The content management behind Salon and other popular sites is friendly to use for your Web site's writers and editors.

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.

Foundations

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.

Installation

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:

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.