Hotfix for AEM MSM Inheritance Breaking

Adobe Experience Manager (AEM) has a robust system for Multi Site Management (MSM). This system allows a company to have multiple versions of a site that all share content from a master “blueprint” site.

One of the features built into AEM MSM is the ability to determine which properties of a page are inherited (“rolled out” in AEM terms) from the master site to its child sites (live copies). Let’s say we have three page properties:
Contact Email (name=”./contact/email”)
Contact Phone (name=”./contact/phone”)
Copyright Text (name=”./copyright”)

In this example, the Contact Email and Contact Phone might be different on every site, but the Copyright Text the same for all sites. When Copyright Text is updated on the master site, we want the `./copyright` property to roll out from the master site to the child (live copy) sites so we do not need to repeat the update in all sites. However, if Contact Email or Contact Phone are updated on the master, we don’t want the `./contact/email` or `./contact/phone` properties to roll out and overwrite the site-specific values.

To support this scenario, AEM MSM implements a `cq-msm-lockable` attribute, documented under the “Configuring MSM Locks on Page Properties (Touch-Optimized UI)” section. Update your page property dialogs to include the `cq-msm-lockable` attribute, and authors will have the ability to determine which properties roll out from the master site and which ones do not.

Easy, right? Well, mostly. This works great for the `./copyright` property, but fails to work with the “deep” properties `./contact/email` and `./contact/phone`. Adding the cq-msm-lockable attribute to the dialog for these properties appears to work in the UI, as the dialog gives the author the chain icon that shows when inheritance is established and allows the author to break the chain to disable the inheritance. However, a rollout from the master site makes it clear that there are problems under the hood, as deep properties (any property with / in the name, putting it in a child node in the JCR hierarchy) are overwritten regardless of whether they have disabled inheritance.

Surprised? We were too. But then we read the documentation closer. Directly in Adobe’s documentation, it states “MSM does not operate with deep properties (e.g., ./image/fileReference), even though the dialog’s logic does. If the chain is opened, a rollout of the page overwrites ./image/fileReference, as the rollout of the image node will not "walk" up to the parent node to check cq:propertyInheritanceCancelled.” Well, there you go–it doesn’t work, and Adobe is aware of, and has even documented, the limitation.

Unfortunately for us, we stumbled upon this limitation when we were already well down the road on one of our projects, with numerous “deep” properties implemented on our page dialogs. Changing all of these properties to top-level (e.g., ./contact/email -> ./contactEmail) was going to be a nightmare considering multiple sites were already deployed and had values for these properties in the JCR. As such, we took it upon ourselves to fix the problem, rather than work around it.

We found the clue to the solution in the documentation–“the rollout of the image node will not "walk" up to the parent node to check cq:propertyInheritanceCancelled.” Updating AEM’s MSM system would have been a non-starter, but we noticed the back door: If the rollout will not walk up to the parent node to check cq:propertyInheritanceCancelled, then we’ll push cq:propertyInheritanceCancelled down to the child so MSM doesn’t have to! This solution worked flawlessly, allowing us to continue forward with deep properties without sacrificing MSM functionality.

Our solution is freely available for download and uses in your own projects at Github. We hope this package saves you in a pinch like it did for us!