Bricolage 1.9.1 Peeves Released

2005.10.28

The Bricolage development team is pleased to announce the release of Bricolage 1.9.1 Peeves, the second development release in preparation for Bricolage 1.10.0. This release adds many new interface and performance enhancements, most of them desiged to address the pet peeves of Bricolage developer David Wheeler. These include the ability to bulk edit an entire story in a single textarea box in the UI, simplified category permissions, and a great deal of refactoring and name normalization. The most significant changes include:

New Features

  • Added serialize_to_pod() and update_from_pod() methods to the container element class. These support a pseudo-pod syntax that enable a complete hierarchy of elements to be edited, including links to related stories and media, in a single stream of text. [David]

  • Converted Bulk Edit in the UI to use the new POD syntax supported by the element classes and eliminated the old Super Bulk Edit interface since it became redundant. [David]

  • Added diff support to the UI to see changes between versions of templates, stories, and media documents. [David]

  • Added JavaScript-powered Find/Replace dialog box to Bulk Edit in the element profile and to the template profile. The Replace All function should work very well everywhere, while the Find function relies on IE- and Mozilla-specific features to properly highlight found text in the textarea box searched. Other browsers will get an alert indicating at what character the match was found. [David]

  • Added new Code Select custom field allows you to add arbitrary Perl code to generate the items in a select list. This is great for dynamically pulling in choices from another database, LDAP directory, or anything else you can get at from Perl code. [Scott]

  • Added reset() method to Bric::Util::Job and a Reset checkbox in the job profile in the UI so that failed jobs can easily be re-attempted. [David]

  • Added Cheat Sheet dialog box to Bulk Edit that displays the entire hierarchy of available subelements and fields as the pseudo-pod tags available for use in bulk editing content. [David]

Improvements

  • Category and story URIs now all end in a slash. This is so that they all behave consistently with root categories and home page URIs, and so that they properly indicate directories. Note that this does not apply if the STORY_URI_WITH_FILENAME bricolage.conf directive has been enabled. Note to Templaters: You may need to modify your templates to take into account that story and category URIS now end in a slash, if you were appending a slash in your templates or searching on category URIs for related stories. [David]

  • Renamed Element to Element Type and Element Type to Element Type Set. This is to avoid confusing element types, which define the structure of elements, and elements, which are contain content and are based on element types. These are not ideal names, but at least we now have something different to call them. The old get_element() method and the accessors that get and set element_id or element__id have also been renamed to get_element_type() and to access element_type_id. [David]

  • Made the scroll bar sticky in the Story Profile, so that when you save a story, the reload will scroll back to the same spot in the story profile where you left odff. [Scott]

  • Normalized story and media elements and fields so that they no longer store copies of their names, key names, and descriptions—and, in the case of fields, the autopopulated and sql_type attributes—since these are actually element type and field type attributes easily referenced in the element type and field type tables. This change significantly reduces the size of the database and has the potential to increase performance when getting and setting field values, especially during publishes. [David]

  • Major refactoring of the field types class, Bric::Biz::ElementType::Parts::FieldType. Attributes that describe how fields should be displayed are no longer stored in a separate attribute object, but as true attributes of field type objects. This makes them much more efficient in terms of database access. [David]

  • Added much more fine-grained field type management to the Element Type SOAP interface. More field attributes can now be updated via SOAP. For example, one can now change the widget type from text to textarea. These improvements are thanks to the normalization of the element type and field type classes. Note that there are a number of new XML elements, and some of the existing ones have changed names, but we have tried to preserve backwards compatibility as much as possible. [David]

  • Renamed Element Data to Field Type. [David]

  • Renamed the Element and Element Type classes as follows:

    They now properly reflect what they’re called in the UI, in SOAP, and in the database. The old classes have been changed to simply inherit from the new classes, so as to maintain backwards compatibility. [David]

  • Turned Bric::Biz::ATType into an appendix: something that’s there, and may have served a purpose in the past, but isn’t needed now. All of its attributes have been moved to Bric::Biz::ElementType, and you should still be able to get the ATType object from existing elements, but new elements won’t need it anymore. It has been removed from the UI, but the SOAP interface and the class itself remain for now. Bric::Biz::ATType will be completely removed in a future version of Bricolage. [David]

  • Added support for typical Windows character encodings. This means that users can select Windows Western (CP1252) as their encoding in order to fix gremlin characters pasted from Microsoft Word. [David]

  • New categories now inherit all group memberships and permissions granted to access assets in the category from their parent categories. This makes it far easier for users with CREATE permission to categories to create new categories without having to then edit group memberships and user group permissions to make them the same as the parent’s permission, which is what is usually wanted. Of course, existing categories are unaffected, and if user needs different group memberships or permissions than the parent, she will still have to edit them. [David]

  • Users creating media documents from within a related media element (because the RELATED_MEDIA_UPLOAD bricolage.conf directive has been enabled and they have the proper permissions) are now redirected to the New Media profile when the new file has been uploaded, so that the element type, category, cover date, priority, etc. can be changed. [David]

  • Output channels are now associated with burners and can only include other output channels associated with the same burners. Element types are no longer associated with burners at all. [David]

  • Renamed Bric::Biz::Asset::Template to Bric::Biz::Asset::Formatting. [David]

  • Added the TT_OPTIONS bricolage.conf directive to allow Bricolage administrators to pass template toolkit directive options to the Template object when it is instantiated by the Template Toolkit burner. [David]

  • Searches now are remembered for each manager in the UI for as long as a session lasts. So if you perform a search for element types, and then do a search for stories or output channels, the last results you saw in the element type manager will be there again when you return to it. [David]

  • Any symbols exported by PERL_LOADER code, plus those exported by Bric::Util::DBI qw(:junction), are now imported into the Template Toolkit stash for direct use in Template Toolkit templates, and into the PHP global context for direct use in PHP templates. For example, the ANY function can now be used directly in TT templates and as $ANY() in PHP templates. The burner constants PUBLISH_MODE and PREVIEW_MODE can also be used $PUBLISH_MODE() and $PREVIEW_MODE() in PHP) if the default PERL_LOADER in bricolage.conf is left in place. But TT can’t have multiple symbols with the same names, so for each symbol exported, it adds to the stash the first one it finds in this order: CODE, HASH, ARRAY, IO, GLOB, FORMAT, and SCALAR. Use of imported functions in PHP templates requires PHP::Interpreter 1.1.0 or later. [David]

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.9.1 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, PHP5, 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 by eWEEK as quite possibly the most capable enterprise-class open-source application available.

blog comments powered by Disqus