Version 13.2 of brXM has arrived - release notes


BloomReach Experience Manager V13.2

BloomReach Experience Manager Developer Edition V13.2

Highlights for V13.2

Hello all, we have released a new version of BloomReach Experience Manager (brXM). This minor release introduces great new functionality and very useful improvements. In this document we will give a brief overview of the highlights of this release.

Please note that due to our security release policy the availability of the community source code and artifacts for all active releases will follow in about six weeks. Customers have immediate access to new releases.

Everything mentioned is an integral part of BloomReach Experience Manager (brXM). If a feature also applies to the Developer Edition, this is explicitly mentioned.

Important upgrade notice (brXM and brXM Developer Edition)

A potentially critical problem was recently discovered when upgrading from v12 to v13 under specific conditions, which may lead to incorrect (partly reverted) node type changes.

The problem (REPO-2196 [1]) has been fixed in v13.2.0, and backported to the maintenance release v13.1.2, and includes repairing possible inconsistent node type definitions.

Customers that have already upgraded from v12 to a v13.0.x or v13.1.x version MUST upgrade to one of these latest releases at their earliest opportunity to mitigate this issue. Customers planning to upgrade from v12 also MUST target at least release v13.1.2 and preferably v13.2.0.

What’s new for developers (brXM and brXM Developer Edition)

Dynamic content beans at runtime

Content beans (for further information refer to our documentation [2]) allow Java developers to customize formatting and provide data-driven logic for content stored in the CMS. Before version 13.2.0, creating content beans was a required step during site development, and we provided tooling in the Essentials application to assist with generating the Java source code. Now the CMS will dynamically generate content beans with default behaviors on the fly without developer intervention. This allows developers to move more quickly to implement sites with less Java code, fewer redeployments during development, and a faster learning process. This new feature is turned on by default, but can be disabled globally or for individual document types. We have made it flexible so that developers can keep the level of control they need for a specific project and use Java code when needed.

OpenUI functionality

Open UI is a brXM framework that allows the display of, and interaction with, external UI extensions ‘in context’ of an end-user within the CMS UI. It was introduced in V13, enabling the creation of ‘Page Tools’. Now we have extended the functionality in two ways: extensions for document fields and enabling dialogs. Both supported by a Javascript client library. All OpenUI documentation can be found in the online OpenUI documentation [3].

Open UI document fields

The brXM developer edition will provide a new primitive field type called “Open UI String”. Fields of this type can be added to a document type in the document type editor. These special string fields enable the developer to write an OpenUI plugin for a document by writing a custom editor for this string. In the past this could be done in Wicket, but now this can be done in Javascript and any framework of choice.

OpenUI dialogs

OpenUI applications, both document field extensions and page tools, can now open a modal dialog ‘in context’ of an end-user. When an end-user is building a web-page by adding components, the functionality allows dialogs to appear within the Channel Manager with UI from a 3rd Party system. In this way, functionality like an image picker that enables selecting images from an external Digital Asset Management (DAM) system can be easily integrated. Content Authors can now work within a single view to increase velocity in their creation workflow, without having to switch contexts to another application.

OpenUI Example: Bynder plugin

As an example and guideline for best practices for OpenUI we provide a plugin for Bynder, a Digital Asset Management system, and a BloomReach Technology partner. The code and instructions to utilise this plugin is available at this github repository [4],

Other news for developers

  • Text fields support the maxlength property.
  • Essentials will show brand new icons, and for newly installed components so will the Components tab in the Channel Manager.
  • Functionality of the replication addon is restored, which was inactive since V13.0 release. This is brXM Enterprise only, and not part of the Developer Edition.

What’s new for end-users (brXM and brXM Developer Edition)

Usability improvements

As part of the independent User Experience (UX) track that we continuously run to improve our products usability, several small improvements have been made in this release:

  • When the CMS has only one single language installed, the language selection drop-down box will not be shown as it is not necessary and could confuse a user.
  • Validation when moving items to incorrect folders. When you are moving items to a different folder, the type of folder is checked and you will receive a warning.
  • Boolean Radio Group is now populated by a Value list instead of fixed one-language-only labels.

Minor release

V13.2 is a minor release so it is backwards compatible with the previous minor release. Also, updating to this version from the previous minor version should be of little effort. Please see the upgrade and update documentation [5] for details.

Supported Technologies

The full system requirements can be found in the online system requirements [6]. This page also includes a detailed table of maintained third party compatibilities.

Highlights in supported technologies

  • Charts in Reports and Relevance no longer require Flash to be activated in the client browser of the cms user.

End-of-life, support and maintained code

Nomenclature refresher

As the terms ‘end-of-life’, ‘supported’, ‘maintained’ are used in various ways in our industry, we clarify the nomenclature we use for this below.

Supported product version

When a product is supported, this means that the customer will receive help from the helpdesk when issues arise as described in the service level agreement (SLA) that the customer has with BloomReach. There are several service levels available.

Please note that if a bug is acknowledged in a supported, but not-maintained version, and a fix is needed, this fix will only be applied in the maintained product versions. This means the customer will need to move to a maintained version to receive the fix.

Maintained product version

When a product is maintained, the product code is updated and security- and bug fixes are made to the code. For maintained products, the system requirements for third party libraries and components is kept updated as well. Please note that we do not provide support for system requirement providers (e.g. databases, java, etc…), but we only support the usage for mentioned certified system requirement providers.

If a product is non-maintained, this means that the code is not maintained anymore and therefore might contain bugs and/or security vulnerabilities due to newly discovered issues in our code, or the libraries used.

End-of-life product version

Products that are not maintained and not supported are end-of-life. These might be available from our archives but could be removed without notice.

What does this mean for the current release?

Please note that this release changes the maintenance mode of V13.0 to ‘Not maintained’.

In the table below you can find the support status of your product and when support will end; this is dependent on the version currently being used and license level. Please note that versions that are not listed are not active and not supported, and therefore end-of-life.



brXM 13.2 is available as from May 20, 2019 onwards. Please note that due to our release policy the release of the open source CMS / developer release will follow in approximately six weeks after this date.