BloomReach Experience Manager V13.3
BloomReach Experience Manager Developer Edition V13.3
Highlights for V13.3
Hello all, we have released a new version of BloomReach Experience Manager (brXM). This minor release introduces new functionality and a number of useful improvements. In this document we will give a brief overview of the highlights in 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.
You can also find these release notes at our documentation web site 
What’s new for developers (brXM and brXM Developer Edition)
Dynamic Content Beans improvements
The Dynamic Content Beans feature introduced in brXM 13.2.0 has been improved to support additional use cases with the Content Blocks plugin. The implementation has improved support for document multiplicity properties (from single- to multiple-value or vice versa), specifically when not all documents have been migrated to match the current document type definition.
Version 13.3 of BloomReach Experience Manager supports validators for fields, compounds and documents. These are supported in both the document editor (the Content perspective) and the visual editor (the Channel manager). Validation can now be implemented on several levels, which can include data from multiple sources, and additionally provides validation of a compound of document type. For example, an “address” compound validator could check whether a “street”, “number” and “postal code” field together form a valid postal address. Another example is to check whether the “start date” for an action is actually earlier than the “end date”.
All new validators are available via a service (the ValidationService), and their implementation is completely independent of the front-end frameworks used in the CMS UI.
Docker support improvements
In this minor release we have made a number of improvements to our docker support, based on feedback from customers and partners.
- Separate user identifier and group identifier for development and production deployments.
- As a developer you now can configure these identifiers so you can differentiate between these during build and deployment. For example, to avoid permission conflicts when using shared directories (while developing on a local system).
- Projects include docker-optimized log4j2 configuration out-of-the-box.
- By using separate configuration files for development and production (which applies to both traditional deployments and docker), you can set the Log4j2 behaviour depending on your environment. For example, the production docker configuration produces less output, but sends it all to stdout.
- Directly launching a container with ‘docker run’ is easier due to improved default values for environment variables.
- The documentation for using Docker has been improved .
Other news for developers
- The repository now logs an error log at startup if the admin password is still ‘admin’. This is backported to all active releases.
- Two new document type layouts are introduced, two column and two column-mirrored. These layouts are especially developed to carry valuelist information.
- If, for security reasons, you want the _visitor cookie to have the SecureFlag (OWASP), you can achieve this by configuration.
What’s new for end-users (brXM and brXM Developer Edition)
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:
- The left and right side-panels in the Channel Manager now highlight their border to indicate that they can be resized. This is consistent with the UX of other parts of the system. The resize handles are removed.
- The search fields in the Content and Admin perspectives support using the Enter key to submit the search. When the search result is shown, the cursor is now placed in the same position where the search began, instead of at the beginning of the term.
V13.3 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  for details.
The full system requirements can be found in the online system requirements . This page also includes a detailed table of maintained third party compatibilities.
End-of-life, support and maintained code
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.1 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.
This version of brXM is available as from July 10, 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.