7.8.0 updater improvements - BloomReach Experience - Open Source CMS

7.8.0 updater improvements

Updater Editor

In Hippo 7.8, a new perspective is introduced: the Developer Panel. In this panel, we plan to make several tools available to developers allowing them to work more effectively directly from within the CMS. The first tool that is introduced is the Updater Editor.

The Updater Editor allows developers to create, manage and run updater scripts against a running repository all from within the CMS UI. Updaters allow bulk-changing existing content. You might for instance need to create a thumbnail of a particular size for every image of a certain type, or you may need to rename a certain field for all documents of type news.

Functionality-wise, this tool has many similarities with the JCR Runner Forge project, but the new Updater Editor has several big advantages.

  • Unlike for JCR Runners, you don't need to have console access to the server in order to be able to run your updater scripts.
  • Scripts run within the same JVM as the repository and do not have to connect over RMI, resulting in a performance boost.
  • As the updater scripts are written in Groovy, you don’t have to recompile and redeploy when you want to make a small change.
  • Developers can provide a revert operation that can easily be run from the Editor.

The updater scripts can be developed using the Groovy scripting language. Using the Updater Editor it is possible to control on which JCR nodes the updater script runs by specifying either a query or a path on which the script should work. It is also possible to control the speed in which the script iterates over the JCR nodes that need to be processed to ensure that the script does not overly tax the running repository. For modifying the nodes, the script has access to the full JCR API unlike the existing updater modules.

A lot of information about each updater run is collected and logged: how many nodes were visited, and how many of them were skipped, how many failed, or were updated; who started the updater and when; how long the updater took to execute; whether or not the updater run was cancelled and who cancelled it, etc.

The documentation on the updater editor can be found here.

Reload on startup

In general, the reload on startup feature allows developers to configure initialize items to be reloaded when the CMS is started. Usually initialize items are loaded only once. The reload is triggered only when the system detects a newer version of the initialize item than was loaded previously. This feature can help you get changes to your project or plugins through your DTAP environments.

A project can include multiple initialization modules, and each module has its own version number. New in 7.8 is that the initialize items that are listed within each module can now also have their own version number, allowing more fine-grained control over what is reloaded when. Another small improvement is that these version numbers can now also be Maven build numbers using a format such as 7.8.0, allowing a more simplified integration with your development environment.

The last improvement for the reload on startup functionality is that hierarchical dependencies between initialize items are correctly restored. The reload on startup mechanism first removes the context node and then reimports the initialize item. This means that other initialize items that contribute nodes that are a descendant of the context node have to be reimported as well. This is now all handled automatically by the reload on startup functionality.

The documentation on reload on startup can be found here.

Diff and patch tool

The last improvement in this section is a new tool in the console. This tool can be used to create a diff between the bootstrap content and the live content, to find for instance configuration settings that have been changed manually. This mechanism can be used for many different use cases, for instance for bringing configuration from the live environment back to the developer environment.

The resulting diff can be downloaded after which a developer can inspect the diff, if necessary edit the changes, and then apply them to his local development environment.

The documentation on this functionality can be found here.

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?