Plumbing Upgrade: We’re Using Bricolage For Content Management

logo.png Believe it or not, but up until the beginning of March this year, we were not using a Content Management System (CMS). This post will take you through the reasons for needing a CMS, along with the process we went through to choose a CMS.

We needed a CMS for the following reasons:

  • We used to have to release a whole new version of our website to include content changes. With the CMS we’re able to just release content, without having to change any code at all.
  • We used to have a pseudo-CMS that required a lot of coordination at deploy time between staging and production. Moreover, we needed to be very careful that production changes weren’t overwritten when staging changes were copied over at deploy time.
  • Our developer bug lists used to be cluttered with content bugs.
  • Our marketing personnel could not directly change content, because they don’t have a build on their local machines and they don’t know HTML. Instead they had to hand off a content, layout, and design spec to a developer.

With all of these pain points in mind, we created some requirements:

  • Customizable workflow
    • Scenario: marketing submits content, PM approves content, then PM schedules the content for a release
  • Input forms for content contributers
    • Example: a developer defines a form schema for a particular abstract data type (e.g. a real estate agent or a press release)
    • A marketing contributor would then fill out this form without having to write any HTML
  • Output templates and static file generation
    • When content is submitted, templates get triggered to convert the abstract content into static files (HTML, XML, JSP, etc)
  • Staging preview capabilities
  • Mutli-site delivery
    • Some of our content goes to and some goes to,, etc
    • This content should all be housed in one repository
  • Multi-server deployment
  • URL Control
  • Versioning, release branches, and rollbacks

We chose some open source candidates:

We started off by looking at open source platforms, and we considered an insane amount of platforms by looking through a cms matrix. After some preliminary research, we narrowed our scope to a few candidates:

We found out right off the bat that Alfresco was the only enterprise-level CMS of the group. Drupal, Joomla, Mambo, and Plone were all lacking static content generation and URL control. They were also not capable of deploying to multiple web servers, hosting multiple sites. After a lot of fiddling, reading, and talking to support, we learned that Alfresco was not able to output static files in certain cases. For example, assume we have a collection of press release HTML files and a single page that lists each of these press releases. Alfresco required us to write our own JSP code using their API to create a dynamic list of press releases – they didn’t provide a template engine that could create a static list. We later learned that Alfresco is now able to create static files in cases such as the above, but we learned about this too late in the game.

We considered some proprietary candidates:

At this point we started researching proprietary CMS platforms such as Interwoven, RedDot, and CrownPeak, only to find that most of these services are insanely expensive. We needed something open source, but we thought we had considered all of them. During lunch one day I began ranting about my open source CMS frustration, when out of nowhere our Linux/data center operations magician says, “Why don’t you use Bricolage?” We took a look at Bricolage.

We found Bricolage!

It turns out that Bricolage has most of what we want. It uses a Mason templating engine that allows for static file creation, and it basically meets most of our other requirements.

Here’s a list of the things that it does very well:

  • Bricolage’s data modeling methods are insanely powerful. Not only can you define different types of pages (they’re called stories in Bricolage), but you can also create HTML components (sub elements in Bricolage) that can be included in pages in any way. For example, you can define a bulleted list, a link, etc, which makes data entry for non-technical folks very easy.
  • Similarly, Bricolage’s templating engine is insanely powerful. Each sub element only needs one template, and templates can be strategically chained to allow for very efficient template design.
  • Deployment is simple and powerful. Bricolage offers a well-documented API that makes deploying to multiple sites on multiple servers seamless.
  • Bricolage allows you to control URLs for each story by either putting the story in a particular category or by changing the slug of the story.

Here’s a list of the things that it does not do well:

  • Bricolage’s admin panel is totally usable but very clunky.
  • The mechanism for working with different branches (for example, one branch of production content and another for soon-to-be released content) is unnatural. Instead of being able to commit changes into different branches, you have to create a network of cloned stories and bucket these clones in different categories (ex: / is trunk, /dev/2.3 is 2.3_dev_branch, etc).
  • Bricolage is mostly geared for managing story-based sites such as MacCentral, so sometimes its naming conventions are confusing for non-news sites such as Redfin.
  • While the API is fairly well documented, discussions of the larger concepts and best practices are spread over multiple sites, mailing lists and power point presentations. This makes the learning curve fairly steep.

We’re very happy with our choice to use Bricolage. Our website is much more agile, and our engineering team is very happy to have our marketing team take over the deployment of new content.

Expect a post very soon talking about the details of how we implemented Bricolage.


  • savan

    You guys finally have this running now that I’m gone! Sometimes I think you were waiting for me to leave before rolling this out.

    Congrats! It’s been a long time coming.

  • Theory

    Hi Alex,

    Thanks for the great post! Since your developers no doubt now have a lot more time on their hands, I’d love it if they joined the Bricolage developers mail list and started a discussion on how to continue to improve Bricolage! ;-)


  • Jason


    Alex and I are on the mailing list and the wiki too. I won’t speak for Alex, but it’s definitely my intention to be more active in both places.

  • Benn

    I’m curious what you thought of plone, I’m really attracted to it for many reasons, but curious why you weren’t. Any thoughts?

  • Alex Loddengaard

    Hi Benn, the two main reasons why we didn’t choose Plone was firstly because our Linux master told us that it had very poor performance. I forget the exact number, but its query/second capabilities were less than ideal. Secondly, we didn’t choose Plone because it couldn’t output static content, which for us is very important.
    On a side note, I had a very difficult time figuring out the admin panel, which frustrated me :) .
    Plone is a great content management solution, but it wasn’t quite what we were looking for. I hope that helps! Let me know if I can answer any other questions.

  • Jon Stahl


    I’m sure you’ll be very happy with Bricolage; it’s a great system.

    I think you’ve gotten a couple of facts wrong about Plone though:

    1) It has great performance, and scales very well to multiple webservers via “Zope Enterprise Objects.” It’s true that an “out of the box” installation of Plone can be a bit slow, but so are all CMSes that serve content dynamically, and that is why virtually everyone uses caching. It takes about ten minutes of tuning with the CacheFu product to boost its performance 5-10x, and some *very* big websites like find Plone fast enough for them!

    2) Plone does indeed have static deployment options, but, unfortunately, not out-of-the-box. You can use the add-on products CMFDeployment and/or Entransit to accomplish both static deployment as well as deployment to a simple PHP/.NET/etc front-end. Bricolage is definitely stronger here, though, since static deployment is its only use-case.

    3) I’m not sure what “URL Control” means, but you can indeed set the “short-name” of every object in your Plone site and you can control the full URL of every page by choosing where to place it in your site hierarchy.

  • Alex Loddengaard

    Thanks for the corrections, Jon. It appears as though the research we did regarding Plone may have been incorrect. I appreciate your corrections here, and I’ll revise the post to reflect your input.

    Thanks again!

  • Sameer

    Haven’t you considered Liferay?

    It provides everything you need.

  • Alex Loddengaard

    Hi Sameer, we didn’t consider Liferay, and at this point it’s probably too late. Thanks for the recommendation, though! For everyone else, here’s the link:

  • Max Clark

    It’s great to see Bricolage being used more and more for sites with dynamic overlay. I’m curious if you looked at Krang during the evaluation process and what your thoughts were.

  • Alex Loddengaard

    Hi Max, we didn’t consider Krang at all. I hadn’t heard about it until I read your comment. At first glance, Krang’s admin panel looks very, very similar to the Bricolage admin panel. Moreover, it looks like Krang is meant for managing news websites, which is again similar to Bricolage. I think that’s about all I can say about Krang at this point; it definitely looks like a nice content management solution!

  • David B

    We’ve been seeking a CMS with static output too. I originally dismissed Bricolage because of Perl in a world of MVC and Java Content Repositories, but am going to review it now.


  • http://link name


  • http://link name

    really great sites, thank you,

  • http://link name

    Perfect work,

  • mathewhugar

    Just choose Drupal content management system. It can bend as you need it to and will fit perfectly to your needs. I am building the fourth website now. First three were personal projects and the latest is a commercial one. And it was really easy to use it so far.

  • nike sb shoes

    Hhe article's content rich variety which make us move for our mood after reading this article. surprise, here you will find what you want! Recently, I found some wedsites which commodity is colorful of fashion.

  • Oakland Plumbing

    I thought I was reading the plumbing for household but this was totally different. LOL!


  • Asamerkley

    Careful here: if the left goes after Joe it could win the election for McCain. All McCain has to do is keep mentioning him, playing you guys like a fiddle. San Francisco Plumbers

  • Rush Service

    Plumbing Minneapolis and St. Paul Minnesota Plumber Minneapolis, MN.

    Full Service Plumbing, Minneapolis, St. Paul, Minnesota, Twin Cities.

    Whether you have a plumbing emergency or a remodeling project, we will provide you with the qualified technicians and guaranteed work that is absolutely necessary when you need expert plumbing solutions for your home or business. All of our service technicians are Mn licensed Plumbers. Be assured when you hire us, you are a hiring a team of highly qualifies, efficient, licensed plumbers. Our friendly staff will provide you professional work done in a clean and tidy manner.
    Call us at 612-616-4000



    Please visit web-site: http://www.rushpointplumbing.c

  • Frankfurt hostels

    Thanks for sharing valuable information about master

  • Heating Problems

    This is a great article.I like this one.The written skill is so good.I am impressed to this post.This is a great article.I appreciate to this post.Thanks to share this great blog with us.Keep it up.

  • martin

    Great post i just loved reading your article from an expert with fantastic knowledge and thank you very much for sharing this  information with us.