Manage Content

Bloomreach Content separates configuration from content using its configuration management system. Configuration is managed in the hcm-config folder, while content is managed in the hcm-content folder. This approach uses the same concepts of Groups, Projects, and Modules described in Manage Configuration.

Configuration definitions allow fine-grained changes to the Configuration Model, such as overriding property types or inserting child nodes at specific locations. For details, see the YAML format. In contrast, content management is more coarse-grained. Content is defined as trees, each identified by a base node.

As with configuration sources, the file name and location within the hcm-content folder do not affect processing. You can organize content source files as needed. However, each content source file must define exactly one content tree. The YAML format for content sources is simplified, since only a single definition is present per file. A typical content source file uses the following structure:

/path/to/base/node:
  jcr:primaryType: <basenode:type>
  <...child properties and nodes...>
copy

Ordering Content Nodes

To insert a new content node at a specific position among its siblings, use the order-before operation. Specify the sibling node name before which the new node should be created. The order-before operation must be set on the base node of the content source.

/path/to/base/node:
  jcr:primaryType: some:type
  .meta:order-before: sibling-name
  <...child properties and nodes...>
copy

If the node /path/to/base already contains a child node named sibling-name when this definition is applied, the new node is inserted immediately before sibling-name. If sibling-name does not exist, the content source processing fails and the content definition is not applied.

Content Bootstrapping

By default, content definitions in the hcm-content folder are bootstrapped into the repository if all of the following conditions are met:

1. The Configuration Model categorizes the base node as content.
2. No previous content load operation has occurred for the base node.
3. The base node does not already exist in the repository.

If any of these conditions is not satisfied, the content definition is not loaded unless it is referenced by a content action.

Configuration bootstrapping is all-or-nothing, but content bootstrapping is handled per definition. If bootstrapping a content definition fails, Bloomreach Content logs a warning and continues with the next content definition, as long as its base node is not a child of the failed definition's base node. Successfully bootstrapped base node paths are tracked to prevent duplicate bootstrapping.

Content Actions

In addition to the default bootstrapping behavior, Bloomreach Content supports content actions for modifying repository content during bootstrapping. Specify these actions in an optional actions file named hcm-actions.yaml, located alongside hcm-module.yaml (typically at /src/main/resources/hcm-actions.yaml in the relevant Maven module).

Supported actions:

• delete
  Removes the base node and its content subtree at the specified location. If the node does not exist or is not categorized as content, no action is taken. Do not include a content source with a matching base node in the module when using a delete action.
• reload
  Deletes the specified base node and then loads a new tree from the corresponding content definition. If no matching content definition exists, the action is skipped.

In most cases, the default content bootstrapping is sufficient, and a content actions file is not required.

A sample content actions file:

action-lists:
- 1.0:
    /content/documents/my-site/new: reload
    /content/gallery/my-site/cleaned: reload
- 1.1:
    /content/documents/my-site/new/obsolete: delete
copy

The content actions file organizes actions by version sequence number. The sequence number applies at the module level and ensures each action is executed only once. If a deployment environment has already executed actions with a given version (for example, 1.0), only actions with higher version numbers are executed on subsequent deployments. Version number ordering follows Maven conventions. For details, see the ComparableVersion documentation.

Note: When a new action replaces a previous one, or when an action is no longer needed in all relevant environments, remove the obsolete action from the actions list and delete any corresponding content source files.

For example, in the following actions list, after action 3 is added, remove action 2 and delete the source file c.yaml:

action-lists:
- 2:
  /a/b/c: reload # -> c.yaml
- 3:
  /a/b: reload # -> b.yaml
copy