Plumbing Upgrade: We’re Using Bricolage For Content Management

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 redfindevelop.wpengine.com and some goes to seattle.redfin.com, sfbay.redfin.com, 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:

• Alfresco
• Drupal
• Joomla
• Mambo
• Plone

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.