Multi‑Site Management Inheritance in Adobe Experience Manager

November 21, 2022 | Hemanth Kumar Ponnuru
Multi-Site Management Inheritance in Adobe Experience Manager

Managing MSM Inheritance

This article is a continuation of An Introduction to Multi-Site Management in Adobe Experience Manager, covering a deeper understanding of inheritance.  The deep-dive includes how actions made in the authoring UI are processed and persisted to the JCR; ironing out typical concerns observed while managing MSM (Multi-Suite Management).

Synchronizing Content

Before we dive in let us be clear about a few basic terms, blueprint and livecopy. A blueprint is typically a source/original page. And a livecopy is a copy of the source page or blueprint.

When synchronized, a livecopy page inherits content from its source page. The inheritance is called a LiveRelationship. Synchronization can be achieved by utilizing the Rollout or Synchronize features of AEM . A rollout process is for synchronizing from the blueprint to the livecopy. It can be initiated either by an author on a blueprint page or by a system event defined in rollout configurations. And synchronize is a process initiated by an author from livecopy for synchronizing with updates made in the blueprint. Both rollout and synchronize can be executed at the component level too.

Inheritance Information in the Content Repository

Livecopy pages will have a mixin type cq:LiveRelationship & cq:LiveSync on its jcr:content node along with a cq:LiveSyncConfig child node under jcr:content with a type cq:LiveCopy.

  •     cq:LiveRelationship: This property exists only the pages created by Livecopy actions (create or rollout).

Following is cq:LiveSyncConfig information: 

  • cq:master : corresponding blueprint page of the Livecopy
  • cq:rolloutConfigs : defines the rollout configurations applied on the Livecopy
  • cq:isDeep : Set as True, a livecopy of a page, together with its child pages. If it is False, a livecopy of a single page
  • cq:excludedPaths : contains page path(s) to be excluded from synchronization.

Livecopy pages will have a mixin type cq:LiveRelationship on its jcr:content node. Below is an example cq:LiveSyncConfig node.


Breaking Inheritance

Based on the use case the relationship between livecopy and its associated source page can be broken. 

Suspending and Canceling Inheritance

Suspending the inheritance on the livecopy will result in the page properties and components no longer being synchronized with the source. Upon suspending the relationship of a livecopy page, jcr:content node will be updated with mixin type cq:LiveSyncCancelled

Authoring Interface Action: The author has to navigate from the Live Copy tab of Page Properties and access the Suspend button on the site action bar.


If the inheritance of a component on the livecopy page needs to be suspended then the component node will be updated with mixin type cq:LiveSyncCancelled & cq:isCancelledForChildren=true, no updates will be on jcr:content node

Authoring Interface Action: The author can choose the component for which inheritance needs to be suspended on the live copy page. Access the Cancel Inheritance from the component’s action bar. 

If the inheritance needs to be canceled for a particular page property,  the jcr:content node will be updated with mixin type cq:LiveSyncCancelled along with addition of property cq:propertyInheritanceCancelled containing canceled page property.

Authoring interface action: The author has to navigate to Page Properties of a given live copy page and choose the Cancel Inheritance option for the page property that needs the inheritance canceled.

Detaching a LiveCopy

Detach operation on livecopy will permanently eliminate the live relationship between a livecopy and its blueprint page. In doing so, livecopy pages become a standalone copy. The  jcr:content property cq:LiveRelationship defining the relationship will not exist anymore. 

Authoring Interface Action: The author has to navigate from the Live Copy tab of Page Properties and access the Detach button on the site action bar.


Restoring Inheritance and Re-Synchronizing Content

Upon restoring the suspended the livecopy page relationship, the jcr:content node will be updated to remove mixin type cq:LiveSyncCancelled. Restoring/Resume operation only reestablishes a broken relationship, for updating the content in livecopy page synchronization must be performed explicitly. Synchronizing will not update the canceled page properties or components inheritance in the livecopy.

Authoring Interface Action: The author has to navigate from the Live Copy tab of Page Properties and access the Resume button on the site action bar.


Potential Issues when Breaking Inheritance

Breaking the inheritance of any of the livecopy’s page properties or components, the rollout administration screen in the authoring environment on the blueprint page has only a simple indication about this. The indicator will provide no additional information, letting the author know which page properties or components are broken, which creates a content auditing issue.

When a livecopy page is deleted directly from Touch UI console, AEM will add the livecopy’s path in the cq:excludedPaths property of cq:LiveSyncConfig node to exclude it from synchronization. This hampers the author’s ability to restore the inheritance at a later point of time.

When dealing with multiple levels of livecopies, there is no (reliable) way of showing the pseudo relationships on more than the top level needed to create new pages via rollout in the trees.

MSM implements a cq-msm-lockable attribute. Updating your page/component property to include this attribute will give the ability to determine which properties roll out. However, this has limitations tackling deeper level ancestry. Read here for the fix.

MSM Rollout Conflict

This conflict can occur in a couple scenarios.

  1. If new pages with the same page name exist in both the blueprint and a dependent livecopy, and a rollout is triggered from the blueprint.
  2. If the livecopy page is detached, and rollout is triggered from the blueprint.

In both cases, AEM considers livecopy page to be a "standalone" page, and when rollout is triggered from blueprint, MSM chooses to rename this standalone page with “_msm_moved” appended, and create a new livecopy page with same name as blueprint with jcr:content node’s mixin type as cq:LiveRelationship. One way to resolve this issue is by updating the configuration Day CQ WCM Rollout Manager.

The Importance of Understanding MSM 

MSM improves content reuse and governance, and implementing it has a huge impact across the site. It is critical to understand AEM's built-in mechanisms (such as rollout configurations, synchronization actions) and their potential complications and limitations for managing content effectively. This article covered a few of the most important topics for maintaining MSM.