RELEASE NOTES
brXM V13.1
brXM Developer Edition V13.1
Highlights for V13.1
Hello all, we have released a new version of brXM (BloomReach Experience Manager). 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 open source code for all active releases will follow in about six weeks.
Everything mentioned is an integral part of brXM. If a feature also applies to the Developer Edition, this is explicitly mentioned.
What’s new for developers
Docker support (also applies to the developer edition)
We now provide Maven profiles that can build and run Docker images in your development environment. To build a Docker image containing your brXM project you use the new Maven docker.build profile. This compiles and packages the project, then builds a docker image from the packaged artifacts. Running the image can be done easily by executing the docker.run profile. You can connect your debugger to the running containers and the configuration is customizable to suit your specific needs. The system will use H2 as database by default, but secondary profiles for Postgres and mySQL are included. Of course, connecting to external databases is possible as well.
All our Docker and orchestration options are very much configurable and documented extensively to make it much easier to match your particular setup.
Support for custom selection of Campaigns
Version 13.1 supports implementing custom HstSiteProviders, which allows developers to customise the behavior of the HST in selecting Projects & Campaigns branches. The default behavior of the HST when using Projects & Campaigns is as follows:
- Select the Core branch of a channel when no Campaigns are running.
- Select the Campaign branch when one Campaign is running.
- Select the shortest Campaign if multiple Campaigns are running simultaneously.
With this feature developers are now able to implement a custom heuristic to override this behavior. For example, this enables you to decide what campaigns to serve based on, say, the location of the visitor (e.g. serve different campaigns in the US and in Europe). Other use cases include serving a different campaign based on visitor behavior, or connecting campaigns to A/B testing solutions.
Per HST Site webapp, one single custom campaign selector can be injected via providing a HstSiteProvider implementation.
Other news
- Platform plus site deployment working for relevance and projects. Support for running a cluster with delivery only cluster nodes (platform and site, no CMS) next to CMS cluster nodes is now also supported for the relevance and projects features (also available in 13.0.1)
- Support for site development config. It is now possible to add development-only site configuration data to a brXM project in multi-site mode for testing or demo purposes, as was previously possible in single-site mode. A new ‘repository-data/site-development’ module has been added to the default project structure for this purpose.
- We have added support for using HotSwapAgent (hotswapagent.org) next to our existing support for JRebel. With this tool, developers can avoid many change->restart&wait->check cycles and increase their speed of code development. Please keep in mind that our support for HotSwapAgent is maintained on a best-effort basis.
- Cloud Deployment Improvements. A new ‘hst:autohosttemplate’ feature makes it easier to support clustered cloud deployments with dynamically created host names.
What’s new for end-users
Scheduled campaigns
New in the Project perspective is the ability to schedule campaigns for being active. Every project you create can act as a scheduled campaign by adding start- and end dates, and time, for publication. In addition, all historical dates of the campaign running are saved and shown as well. As this feature is fully integrated in the Projects functionality, all workflow, review and approval mechanisms work like always. You now can also merge running campaigns. Color coding the schedule status for the campaign makes it easier to get a clear overview of the schedule.
Visual Editing improvements (also applies to the developer edition)
The visual editing capabilities of the platform have been increased. Static dropdown fields and value list-powered radio group fields are supported now to be used in the right side panel when editing content.
Usability improvements (also apply to the developer edition)
As part of the independent UX track that we have running to continuously improve our product usability, several small but very neat improvements have been made in this release:
- Component editor fields now can have hints/tooltips just like document fields or channel setting fields. This is available in the new component property editor in the side panel. When using relevance, the previous dialogs are used.
- In all CMS dialogs with multiple buttons, the affirmative button is on the bottom right hand side of the dialog.
- Search results in Sitemap and Components are kept while clicking Save or Save & Close in the Component Properties dialog. If you return after saving or closing, the search results are shown.
- The Translations menu is now ordered alphabetically. After you create a new translation, the document is opened in edit mode immediately.
- Several UI labels are improved for clarity. Long tooltips are now styled more appropriately.
- Aligned styling for dialog buttons. Some dialogs used the default browser styling for buttons.
- Validation messages moved from the top of the document to the validated field in the content perspective.
- We’ve fixed the broken radio group sorting.
- The Reports perspective for internal statistics has been updated to use the D3.js charting library, for improved usability and browser support.
Minor release
V13.1 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 update documentation for details.
Supported Technologies
The full system requirements can be found at https://www.onehippo.org/library/about/system-requirements.html . This page also includes a detailed table of maintained third party compatibilities.
Highlights
- From now on we will not explicitly mention the JDKs we support. Due to the current availability of a growing number of JVM flavours of third party JDKs and distributions of OpenJDKs, we will only mention that we run in Java 8. We support standard OpenJDK builds, including Oracle’s official build, alternative builds such as AdoptOpenJDK, and builds shipped with Linux distributions such as Red Hat Enterprise. All with current CPU (Critical Patch Update) and Hotspot that is actively supported by its vendor. We will not support Java 11 in the near future.
- For Ubuntu, we will not explicitly mention the versions we support, but will support the active - by Canonical - Supported LTS versions. Currently, these are 16.04 an 18.04.
- CKEditor is upgraded to 4.11.2 with added support for emoticons, mentions and autocomplete. For more information on these plugins please check https://documentation.bloomreach.com/library/concepts/document-types/html-fields/ckeditor-plugins.html
- We’ve upgraded the Camunda workflow engine which is used in the Projects feature to version 7.9.0.
Known issues
- We have found an issue with the enterprise-licensed Replication Add-on of Bloomreach Experience Manager, which makes it work less reliably in versions 13.0 and 13.1 than it used to in previous versions. While we are working on fixing this issue, we recommend users of this add-on not to upgrade to version 13 yet. We expect to have this issue fixed in version 13.2.
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 get help from the helpdesk when issues arise as described in the service level agreement 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 touched 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.
Availability
brXM 13.1 is available as from March 20, 2019 onwards. Please note that due to our release policy the release of the open source CMS / developer release will follow in about six weeks after this date.