Bloomreach Experience Manager V16.9 Release Notes

Highlights for v16.9

We are pleased to announce a new version of Bloomreach Experience Manager (brXM). This minor release introduces a number of new features,  useful technical stack upgrades and 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 Release Notes Overview.

Everything mentioned in this document is an integral part of Bloomreach Experience Manager (brXM), unless mentioned otherwise. 

Significant Updates and New Features

Folder Limits: Protect Repository Performance at the Source

Large folders are one of the primary causes of CMS performance degradation. As editors create more and more documents within a single folder, search, navigation, and publishing operations all slow down. Bloomreach has long recommended keeping folders under 100 items, but until now there was no platform-level mechanism to enforce this. Teams could only react after performance problems appeared.

Starting with 16.9.0, the platform enforces a folder item limit of 100 by default, matching the long-standing Bloomreach best practice. When a folder reaches the limit, editors cannot add further content to it and are prompted to use a subfolder structure instead. The limit applies across all content creation paths and also to content imported via the Workflow API. The limit is configurable per environment and can be disabled.

Developer notes:

The folder limit is enforced in FolderWorkflowImpl, GalleryWorkflowImpl, and TranslationWorkflowImpl. A new FolderLimitException is thrown when the limit is exceeded, and the error is surfaced to the editor via the existing workflow error handling mechanism. The feature is disabled by default and configurable via Console. See the Folder Item Limit Configuration for configuration instructions. For background on recommended folder sizes, see How to structure your data and content.

Taxonomy Performance: Faster Editing and Publishing for Large Taxonomies

The Taxonomy plugin lets CMS administrators define category trees that editors use to tag and classify content. Organizations with large classification structures (hundreds or thousands of categories) have reported slow taxonomy editing and publishing delays that impact the whole editorial team.

Teams managing large taxonomy structures will see a significant improvement in editor speed and responsiveness. Large category trees open and respond faster, making it easier to navigate, search, and update classifications without delays. Publishing a taxonomy no longer holds up other editors' work, so teams editing content in parallel can publish independently without waiting for taxonomy operations to complete.

Developer notes:

The performance improvement comes from a new JSON-based storage model where the entire category hierarchy is persisted as a single hippotaxonomy:categories binary property on the taxonomy document, rather than individual JCR child nodes per category. This significantly reduces database operations on every taxonomy load and save. The feature is opt-in, controlled by taxonomy.json.tree.enabled on the taxonomy service configuration node. A TaxonomyJsonMigrator Groovy script is bundled for migrating existing taxonomies. Migration is one-way and cannot be reverted. See JSON Tree Introduction in v16.9 for configuration, migration steps, and important considerations.

Repository node type definition (CND) change

This release introduces the following node type definition (CND) change:

  • added property hippotaxonomy:categories (binary) to the hippotaxonomy:taxonomy node type

Important: simple rollback not supported
The above CND change means that an upgrade to 16.9.0 cannot be rolled back simply by redeploying the previous distribution on the already upgraded repository, by swapping binaries or containers.

If you need to downgrade, you must restore from a full repository backup taken before the upgrade.

Ongoing Enhancements and Fixes

For end users

Experience Manager

  • OpenUI extension dialogs rendered in a very small viewport when opened from within Experience Manager. Dialogs now render at the correct size.

Content Editor

  • Selected values in multiselect palette fields were visually cut off when option labels exceeded the panel width, making it impossible to confirm which value was selected. Selected values now display fully in all panel widths. 

For developers

Platform and stability

  • Intermittent 500 errors occurred in the CMS due to timing issues in the application bridge handshake between CMS frontend applications. Periodic handshake retries are now implemented, making the connection resilient under slow or unstable conditions. 

Content model and configuration

  • A new configurable MIME type resolution service maps file extensions to all known MIME type variants, ensuring consistent file upload behavior across browsers. Mappings are stored in JCR and changes take effect at runtime without a restart. This replaces the static MimeTypeMapper utility from 16.8.1. See MIME Type Resolution Configuration for configuration details and default mappings.

Bloomreach SPA SDK Updates

SPA SDK 27.2.0 – ImageSet Variant Access

v27.2.0 adds getVariant() and getVariants()methods to the ImageSet class, giving developers a direct way to retrieve custom image variants by name. See the SPA SDK 27.2.0 release notes for full details and code examples.

Professional Services Plugin Newsletter

Translations Add-on - v8.0.1

Compatibility release for brXM 16.7.x. 

See the Translations Add-on documentation for full details.

Get help from BrXM Experts for Upgrade

The Bloomreach Professional Services team possesses extensive expertise in BrXM and has successfully executed various project implementations. Our team can facilitate a seamless upgrade of your project to the latest BrXM versions.

Additionally, we offer an Upgrade Assessment service for your projects. In just 3 days, our comprehensive evaluation will provide you with invaluable insights into your investment requirements. Our team of experts meticulously assesses your existing systems and infrastructure to determine the necessary investment for the upgrade.

The resulting detailed report encompasses the following components:

  • Executive summary

  • Overview of major changes

  • Recommended upgrade procedure

  • A comprehensive list of findings

It's important to note that the evaluation fee* is fully refundable should you decide to proceed with our Professional Services for the actual upgrade. This ensures that you not only receive top-notch guidance but also keeps your best interests in mind.

If you're interested in availing the assistance of our Professional Services team for your upgrade, please get in touch with your account manager. We're here to support your project's success every step of the way.

Notices

There are no notices.

Minor release

v16.9 is a minor release, so it is backward compatible with the previous minor release. Also, updating to this version from the previous minor version should be of little effort. Specific instructions for upgrading from v16.8 to v16.9 are available for enterprise customers (login required). Please also find  the overview of minor version upgrade instructions in this major release in our documentation.

Supported Technologies

Full system requirements, including a comprehensive table of maintained third-party compatibility, are available in the system requirements documentation.

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 are 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 existing maintenance or support modes. 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.

Version

Planned end date of 
Standard Support 

Planned end date of 
Premium Plus Support

Original major version release date

Latest 14.x December 2024 December 2025 December 2019
Latest 15.x

December 2025

December 2026

April 2022

Latest 16.x December 2026 December 2027 June 2024

Figure: reference table of planned end of support dates based on current SLA terms. Supported versions may differ depending on contractual agreements.

The versions highlighted in orange are actively maintained and provided with bug fixes and product improvements.

Security notes

This release includes updates for third-party dependencies that have published vulnerabilities. We recommend that customers keep their systems up to date with announced product releases.

Availability

This version of brXM is available as of April 9, 2026 onwards, the release of the open source will be made available after approximately 2 years due to our release policy.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?