Bloomreach Experience Manager V14.4
Bloomreach Experience Manager Developer Edition V14.4
Highlights for V14.4
We are pleased to announce a new version of Bloomreach Experience Manager (brXM). This minor release introduces new functionality and a number of useful improvements to the product. In this document we will give a brief overview of the highlights in this release. You can also find these release notes at: https://documentation.bloomreach.com/about/release-notes/release-notes-overview.html
Please note that as a result of our security release policy the public availability of the community source code and artifacts for all active releases will follow in about six weeks. Customers however, have immediate access to these new releases at the release date.
Everything mentioned in this document is an integral part of Bloomreach Experience Manager (brXM) and the developer edition, unless mentioned otherwise. If a feature only applies to brXM and not to the developer edition, this is explicitly mentioned. Features that are mentioned as part of brXM also apply to brX.
Key New Features
Further investments into Experience Pages
The Experience Pages feature - shipped in v14.3 - has changed the way our users are able to edit and work with pages in Bloomreach Experience Manager. In v14.4 we’re continuing this investment in advanced page management use cases and have added a number of significant improvements:
- It is now possible to accept and reject publication requests on Experience Pages from the Experience Manager perspective as well. This was previously only possible from the content perspective.
- We’ve added options to copy, rename, delete and move an experience page to the Page menu. This means that all page actions are now available directly from the Experience Manager, without having to switch to the content perspective.
- Publishing a page and taking it offline are now enabled while the editing side panel is opened. This was a known limitation in the v14.3 release, which created some confusing interactions for users. From now on users shouldn’t run into these issues anymore.
- We’ve added several improvements with respect to how Experience Pages are used in projects - it’s easier to add an Experience Page to a project from the Experience Manager, we’ve solved several issues with publishing the core version without publishing the project, and added a notification in the notification bar when a page is part of a project
- Experience Page template configurations can now be inherited, making it easier to share templates with different channels without duplications.
Hierarchical sitemap in Experience manager
One of the easiest ways to navigate between pages in the Experience Manager is through the sitemap view in the left-hand panel. It helps users understand their site structure as well as navigate quickly between relevant pages. With the addition of Experience Pages, we noticed that users need to be able to switch between pages more often, since it has become easier than ever to create them. The previous URL based sitemap view exposed these pages in a huge list, without any grouping. This made it very hard to navigate and consequently difficult to manage.
To solve this issue we have redesigned the sitemap structure into a hierarchical tree based on the page URLs. As seen in the example above, this creates a sitemap hierarchy, similar to a folder structure in the content perspective. We have made sure that the list is clickable, scrollable and searchable.
Decoupled front-ends & SPA integration improvements
As part of our ongoing efforts to improve the way brXM integrates with decoupled front-end applications and SPAs, we’ve implemented a significant number of improvements and fixes in this area.
- The Angular SDK now has support for Angular 11 and Ivy.
- The Angular SDK has been improved to perform rendering earlier, leading to better performance.
- Pagination with Dynamic components is now supported.
- We’ve added support for channel info properties in the SDKs.
- We’ve fixed an issue with empty no markup containers not being editable.
- TypeScript 4 is now supported.
- The SDKs now have support for unknown/unresolved link types.
- The SDK now automatically redirects to a default endpoint if no value is configured in the front-end application. This enables front-end applications to be connected to brXM with zero configuration.
For end users
- Taxonomy plugin search bar - Some projects use a very large taxonomy tree, making it difficult for editors to find the key they want to apply to a document by browsing through the tree. To improve this, we added a search bar to the taxonomy picker with similar behavior to how document search in the documents tree works.
- Performance improvements to Projects feature - We’ve implemented several changes leading to a vastly reduced time for Projects updates and merges to complete.
- Updated links - The documentation links in the help menu have been updated to reflect the correct urls.
- Hook for asset/image preprocessing - An extension point for including custom pre-processors for uploaded images and assets has been added, to enable developers to add custom code before an uploaded file is stored in the repository. The main use case we aimed to solve was providing an extension point for removing (personal or unintended) metadata of assets, but the functionality can be used for other use cases as well.
- Active logout in console - In 14.3, we saw an issue with the active logout not working as expected in the console. This has now been fixed.
MVCC parameter removal from H2 database connection URL
We removed the MVCC parameter in 14.0.0 (see v14.0 upgrade instructions at ). With the security-driven h2 update to 1.4.200 in brXM v14,4 the MVCC parameter is no longer supported and must be removed if it is still present in the conf/context.xml file.
V14.4 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. Specific upgrade instructions for this release can be found in our documentation  for enterprise customers (requires a login). An overview of all upgrade instructions for minor versions in this major release can be found in our documentation  as well.
The full system requirements can be found in the online system requirements . This page also includes a detailed table of maintained third party compatibility.
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 does not change any maintenance or support mode.
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.
Several security fixes have been implemented in brXM v14.3. Per our release policy, these will be disclosed to customers first, and shared publicly approximately six weeks later.
This version of brXM is available as of December 8th, 2020 onwards, for both enterprise customers and the open source community.