MSM Best Practices msm-best-practices

Carefully plan structure and content flows before starting implementation.

Customize as much as necessary, but as little as possible. While MSM supports a high degree of customization (e.g. rollout configurations) typically the best practice for the performance, reliability and upgradeability of your website is to minimize customization.

Establish a governance model early, and train users accordingly, to ensure success. A best practice from a governance point of view is to minimize the authority that local content producers have to allocate/connect content to other local users and their respective live copies. This is because un-governed, chained inheritances can significantly increase the complexity of a MSM structure and compromise its performance and reliability.

Once a plan exists for your structure, content flows, automation and governance - prototype and thoroughly test your system, before starting live implementation.

Keep in mind that Adobe Consulting and leading System Integrators have deep experience planning and implementing content automation with MSM, so they can help you both get started with your MSM project and throughout its entire implementation.

When creating a Live Copy

This can be considered as the more generic approach, allowing you to create live copies from any page. The content structure of a live copy exactly matches the source.

When creating a Site

This is a more specialized approach, primarily for creating websites with a multilingual structure.

To create a new site, you need a blueprint configuration.

To allow the selection of language paths to create in a new site, the corresponding language roots must exist in the blueprint (source).

Once a new site has been created as a live copy (using Create, then Site), the first two levels of this live copy are shallow. Children of the page do not belong to the live-relationship, but a roll-out will still descend if a live-relationship that matches the trigger is found.

It helps avoid:

• manually adding languages in the blueprint (below the first level)
• manually adding content directly below the language root,
• does not result in automatically carrying this new content over to the live copy on rollout.

When creating language masters.

• While MSM itself does not provide content translation, it can be integrated with third-party translation connectors that do. Please note that:

  • MSM allows you to cancel inheritance at the page- and/or component- level. This helps prevent overwriting translated content (from a live copy, with not-yet-translated content from a blueprint) on the next rollout.

  • Some third-party translation connectors automate this management of MSM inheritances.

    Please check with your translation service provider for more information.

  • An alternative approach for creating and translating language masters is to use language copies in conjunction with AEM’s out-of-the-box translation integration framework.

When rolling out content from language masters.

• For example, from the French language master to country-specific sites, such as France/French, Canada/French, Switzerland/French.

Creating new pages in a blueprint will result in corresponding pages being created in live copies after rollout with the standard rollout configuration.

Deleting pages in a blueprint will result in corresponding pages being deleted from live copies after rollout with standard rollout configuration.

Moving pages in a blueprint will not result in corresponding pages being moved in live copies after rollout with standard rollout configuration:

• The reason for this behavior is that a page move implicitly includes a page delete. This could potentionally lead to unexpected behavior on publish, as deleting pages on author automatically deactivates corresponding content on publish. This can also have a knock-on effect on related items such as links, bookmarks, and others.
• Content inheritance in the respective live copy pages is updated to reflect the new location of their sources in the blueprint.
• To fully realize a page move from a blueprint to live copies, consider the following best practices:

Create a custom rollout configuration:

• This new configuration must include the action:

  PageMoveAction

  Do not add other actions to this configuration.

Position the new configuration:

• To fully roll out the page move, while deleting respective pages at their old location in the live copy:

  • Position the newly created configuration before the standard rollout configuration.

    The standard rollout configuration will take care of deleting the pages in their old location.

• To roll out the page move while keeping respective pages in their old location in the live copies (essentially duplicating the content):

  • Position the newly created configuration after the standard rollout configuration.

    This will ensure no content is deleted in the live copy or deactivated from publish.

Automating rollouts with onModify triggers may have a negative impact on authoring performance as they trigger rollouts after every page modification.

The rollout result may differ from the one expected as:

• You cannot specify the order of the resulting modify events.
• The event-based architecture cannot guarantee the sequence of the events passed to the Rollout Manager.

Using such a rollout configuration could lead to commit conflicts if concurrent updates of the same resource occur.