The Bricolage development team is pleased to announce the release of Bricolage 1.8.6. This maintenance release addresses numerous minor issues in Bricolage 1.8.5 and adds a number of improvements, including SOAP, document expiration, and bric_queued fixes. The most important changes include:

Improvements

• Added JavaScript code to validate that the username in the user profile does not have leading or trailing spaces. [David]
• Events in the event log are now returned (and displayed) in reverse chronological order. [David]
• The SOAP server now uses a user’s template sandbox when executing previews (such as with bric_soap --to-preview workflow publish). Reported by Marshall. [David]
• Bric::Biz::Workflow now caches calls to allowed_desks(). This will allow desks to render much Faster, since most assets on a desk will list the same desks in the “Move to” select lists. [David]
• When the PUBLISH_RELATED_ASSETS bricolage.conf directive is enabled, aliases are now also republished. Only aliases that have previously been published will be republished, and only the last published version will be republished, rather than any versions created since the last publish. Suggested by Serge Sozonoff. [David]
• A story or media document published with an expire date earlier than the scheduled publish time no longer bothers with the publish but just expires the story or media document. [David]
• Media documents without an associated media file will no longer be displayed in the search results when attempting to relate a media document to an element. Reported by Adam Rinehart. [David]

Bug Fixes

• Form validation and group management now properly work in the user profile. [David]
• The SFTP mover now works with bric_queued. [David]
• Cloned stories now properly set the published_version attribute to undef rather than the value of the original story, thus preventing the clone from having a published version number greater than its current version number. Reported by Nate Perry-Thistle and Joshua Edelstein. [David and Nate Perry-Thistle]
• When a category is added to a story that creates a URI conflict, the new category does not remain associated with the story in the story profile after the conflict error has been thrown. Reported by Paul Orrock. [David]
• Contributor groups created in the contributor profile are no longer missing from the contributor manager search interface. Reported by Rachel Murray and Scott. [David]
• The favicon.ico works again. [David]
• Stories are now properly expired when the BRIC_QUEUED bricolage.conf directive is enabled. Reported by Scott. [David]
• When a template is checked out of the library and then the checkout is canceled, it is no longer left on the desk it was moved into upon the checkout, but properly reshelved. Reported by Marshall. [David]
• Super Bulk Edit now works for media as well as stories. Reported by Scott. [David]
• When a template is moved to a new category, the old version of the template is undeployed when the new version is deployed to the new category. The versions in the sandbox are properly synced, as well.

For a complete list of the changes, see the changes. For the complete history of ongoing changes in Bricolage, see Bric::Changes.

Download Bricolage 1.8.6 now from the Bricolage Web site Downloads page, from the SourceForge download page, and from the Kineticode download page.

About Bricolage

Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason, HTML::Template, and Template Toolkit support for flexibility, and many other features. It operates in an Apache/mod_perl environment and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage has been hailed as “quite possibly the most capable enterprise-class open-source application available” by eWEEK.

Looking for the comments? Try the old layout.

Jeffrey Veen posted some of his thoughts on the (dreary) state of open-source CMSs. So I just thought I’d comment on his thoughts. Keep your salt grains handy.

As a CMS developer, my point of view is quite naturally biased. However, I agree with some of Jeffrey’s points, and disagree with others. Well, not disagree so much as wish to qualify. Many of your points betray a certain perspective that does not (and, naturally, cannot) apply to anyone and everyone who is evaluating content management systems. So let me just try to address each of your points and how they related to Bricolage.

Make it easy to install. Well, yes, of course, and I’ll be the first to admit that Bricolage is difficult to install. But your requirement that you be able to install it from the browser just isn’t feasible with a CMS that aims to scale to the needs of a large organization. The security implications alone make give me the heebee-jeebies. It’s fine if you want to just manage your own personal site, but not if you’re aiming to serve the complex needs of the corporate marketplace.

That said, it might be reasonable to create a simple installer that’s useful for doing a local evaluation of a major CMS, one that doesn’t rely on an RDBMS and an Apache Web server installation. (RT (not a CMS) has been working on a simple executable that uses an embedded database and Web server for those who want to evaluate it. For Bricolage, we at one time had a KNOPPIX CD that one could use to try it out. But for the rest, the best solution is probably an RPM, BSD Package, Debian package, or the like–something that can integrate the application into the base operating system.

Make it easy to get started. Bricolage is pretty bad about this, mostly because the default templates that come with it suck. That will change eventually, but the bigger issue is that when you have a complex, flexible application, it’s tricky to present a simple getting started configuration without locking the user into just using that configuration (witness all the identical Microsoft Home Page sites on the ‘Net to see what I mean). But that’s no excuse for a system like Bricolage–those who need the more advanced features could take advantage of them when they’re ready. It’s just a matter of finding the tuits (or the volunteer) to make it happen.

Write task-based documentation first. In my experience, most complex open-source applications that have task-based documentation have it when they author a book. Yes, most of these systems have grown organically, and documentation gets written as volunteers make the time. But the best documentation I’ve found for open-source software has tended to be in published books. Though I think that trend is gradually changing.

Separate the administration of the CMS from the editing and managing of content. In Bricolage, you do not have to switch accounts to have access to the administrative tools. And although the administrative tools are part of the same UI, they have an entirely different section and set of navigation menus. Users who don’t have permission to use those tools don’t notice them.

Users of a public web site should never–never–be presented with a way to log into the CMS. Amen, brotha.

Stop it with the jargon already. Finding good terminology is hard, hard work. Bricolage is broken in this respect in a few ways, but I’m thinking of replacing “jobs” with “fembots” in 2.0. What do you think?

But seriously, we try to match the terms to what is commonly used, such as “document”, “site”, “category”, “keyword”, “template”, etc. Other terms, such as “element” (the parts of a document are its elements) are well-integrated into the system, so that users pick up on it very quickly.

Why do you insist Web sites have columns? I’m in complete agreement with you here. In Bricolage, you can write templates to output any kind of content you want, in any format you want. If you want columns, fine, generate them from Bricolage. If you want a standards-compliant layout, generate it from Bricolage. You can have 1998-era tables with Flash and you can have RSS feeds. Do what you want, make it flexible or make it complex.

But note that the flexibility comes at the price of complexity. And try as we might to make Bricolage “The Macintosh of Content Management Systems,” as long as the definition of the term “Content Management System” is all over the map, commonalities of metaphors, interfaces, and, well, philosophies between CMSs will continue to be all over the map.

But that’s just my opinion.

Looking for the comments? Try the old layout.

Perl.com has published the first in a series of articles I’ve promised to write, “Content Management with Bricolage.” The article is targeted at organizational decision makers who need to evaluate Bricolage as part of their selection of a content management solution. So I’ve spent some time discussing what content management is and how Bricolage fits in. I mention a lot of other CMSes as for comparative purposes, to try to really give people a feel for how Bricolage can meet their needs.

I also go over some of Bricolage’s most important features, such as multisite management, document modeling, Perl templating, meaningful URLs, workflow, and any number of outputs via “output channels.” The article concludes with a list of sites known to be managed by Bricolage, as well as the promise for more.

The next article in the series will cover installation and configuration. Subsequent articles will cover document analysis and modeling, Mason templating, and fun with the SOAP server. Enjoy!

Looking for the comments? Try the old layout.