HST Workspace Configuration

This page explains the purpose and structure of the hst:workspace node in the HST configuration model. For an overview of the HST configuration model, see the introduction.

The following example shows a typical HST configuration structure:

/hst:hst
  /hst:configurations
    /example
      /hst:abstractpage
      /hst:catalog
      /hst:components
      /hst:pages
      /hst:prototypepages
      /hst:sitemap
      /hst:templates
      /hst:workspace
        /hst:channel
          /hst:channelinfo

Previous documentation covers all elements except hst:prototypepages and hst:workspace. This page focuses on hst:workspace.

The hst:workspace node separates:

Configuration changes made by developers (typically in local development) that require HST configuration updates in production.
Configuration changes made by webmasters in production using the Experience manager.

Before the introduction of hst:workspace, changes made by webmasters in production were stored directly under nodes such as /hst:hst/hst:configuration/example/hst:pages. Developers might also update these nodes, which required coordination between teams during deployments. The hst:workspace node addresses this by clearly separating changes made by webmasters from those made by developers.

The hst:workspace Node

The hst:workspace node stores configuration changes made by webmasters in the Experience manager.

Info: The hst:workspace node contains all Experience manager changes made in production.

With this structure, all changes made through the Experience manager are stored under /hst:hst/hst:configuration/example/hst:workspace. Developers typically do not make bootstrap changes under hst:workspace. As a result, developer changes can safely override the configuration under /hst:hst/hst:configurations/example during deployments.

Supported hst:workspace Nodes

The following nodes are supported under hst:workspace:

/hst:workspace:
  /hst:containers:
  /hst:sitemenus:
  /hst:abstractpages:
  /hst:pages:
  /hst:components:
  /hst:sitemap:
  /hst:channel:

The hst:containers node is described in the Containers configuration. Other nodes under hst:workspace—such as hst:pages, hst:sitemap, and hst:sitemenus—mirror their non-workspace counterparts. In the final HST model, workspace and non-workspace nodes are merged into a single sitemap, pages, and sitemenus section.

Starting with CMS 12.0.0, hst:workspace also supports hst:abstractpages, hst:components, hst:templates, and hst:channel. The hst:channel node is included because channels were moved from /hst:hst/hst:channels into the HST configuration nodes. The additional node types are required to support cross-channel page copy operations, where templates and other configuration may need to be copied into the workspace. In preview configurations (since CMS 12.0.0), only the hst:workspace is present, so all relevant configuration must be supported under hst:workspace.

Merging Rules for Workspace and Non-Workspace Nodes

The HST merges the hst:workspace configuration with the developer bootstrap configuration using a coarse-grained approach. A node under a workspace section (such as hst:sitemenus, hst:pages, or hst:sitemap) is included in the final configuration only if it does not already exist in the developer configuration.

For example:

/hst:hst:
  /hst:configurations:
    /example:
      /hst:sitemenus:
        /footer:
          /contact:
      /hst:workspace:
        /hst:sitemenus:
          /footer:
            /address:

In this case, the workspace node /hst:hst/hst:configurations/example/hst:workspace/hst:sitemenus/footer is ignored because /hst:hst/hst:configurations/example/hst:sitemenus/footer already exists. The merged configuration does not include address.

If the workspace node does not overlap, it is included:

/hst:hst:
  /hst:configurations:
    /example:
      /hst:sitemenus:
        /footer:
          /contact:
      /hst:workspace:
        /hst:sitemenus:
          /main:
            /home:
            /about:

The merged configuration is:

/hst:sitemenus:
  /footer:
    /contact:
  /main:
    /home:
    /about:

The same merging rules apply to hst:pages and hst:sitemap.

Inheritance of Workspace Nodes

The HST configuration model supports inheritance between configurations. For example:

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common]

By default, workspace configuration is not inherited. The workspace configuration is local to each configuration.

Hint: Workspace configuration is local by default and not inherited.

To inherit workspace configuration, explicitly include it in the hst:inheritsfrom property:

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common, ../common/hst:workspace]

Info: For more details, see Configuration Inheritance.

Workspace Inheritance with Cascading Inheritance

Consider the following configuration:

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common, ../common/hst:workspace]
      /hst:workspace:
    /subexample:
      hst:inheritsfrom: [../example]

In this scenario, subexample inherits the workspace configuration from common (due to cascading inheritance), but does not inherit the workspace from example because it is not explicitly included in the hst:inheritsfrom property.