This article covers a Bloomreach Experience Manager version 12. There's an updated version available that covers our most recent release.

Update CMS Configuration

Goal

Update project-specific CMS configuration in a particular server environment (e.g. production).

Stakeholders

Developer 

Prerequisites

All project-specific CMS configuration is stored and version-controlled in the project's repository-data/application module. 

CMS Configuration

Bloomreach Experience Manager configuration, stored under /hippo:configuration in the repository, contains settings for the CMS application and any plugins that might have been added. Normally, configuration nodes under /hippo:configuration are originally added by the CMS application itself or the relevant plugin. These are the default settings and they are usually only updated by a new version of the Bloomreach Experience Manager application or plugin.

However, an individual Hippo-based project might require modified or additional CMS configuration settings. Also, further releases of the project may want to modify these already project-specific settings again, in which case the CMS configuration in any target environment where the project is running, must be updated when such a new release is deployed.

The recommended procedure for modifying CMS configuration is described in detail below.

Making Changes to CMS Configuration Nodes

When making changes to CMS configuration, including adding, modifying, and deleting nodes and properties, Automatic Export can normally do most of the work for you.

The procedure is as follows:

  1. Enable the Automatic Export feature in your development environment to automatically export any changes to your CMS configuration as YAML sources in the repository-data/application module.
  2. Before you make any changes, verify that the nodes you want to modify, have not been modified in the target environment.
  3. Make the required modifications to the CMS configuration node(s) in your development environment. The changes will be automatically exported to the project's repository-data/application module.
  4. Verify the changes in your repository-data/application module and commit them to your Version Control System (as usual).
  5. Package the repository-data/application module with your release artifact(s) (as usual).
  6. Deploy the release artifact(s) in the target environment. Make sure bootstrapping is enabled. The affected node(s) will be automatically adjusted when the newly deployed release is started.

In rare cases, you might have to write and execute a custom Updater Script. The script is best bootstrapped to the "updater registry", and then manually executed by an administrator after the new release has been started. 

Summary

  • CMS configuration is normally added to the repository outside the scope of an individual project (i.e. by the CMS application or a plugin).
  • An implementation project can make changes to CMS configuration nodes using YAML sources that apply the required changes.
  • Automatic Export can handle most scenarios and export the changes to YAML sources in the project's repository-data/application module.
  • In rare cases, an Updater Script might be necessary to update CMS configuration.
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?