How can I manage multiple content contexts in Experience Manager?

Question

This is a question I've always been asked but never really implemented a solution for it. The scenario is that I have multiple content publications (each division in the company creates content in their specific publication) but they are all merged later on in a common web layer. When implementing experience manager you can only specify one content level for each web level within the Experience Manager Settings:

Now, my answer on how to allow multiple content contexts was by using some kind of event system that looks at the folder location and based on something (metadata, naming convention, etc...) intercepts the component Save event and reassigns the context (Containing Folder) in the right level of the blueprint.

Is there anything like this already implemented somewhere? Any recommendation/best practice? Is this something that can be done out-of-the-box (other than by using the out-of-the-box Event System):)?

Thank you,

Answer 1

Two things I've seen:

1. Internal websites for parent Publications to let certain groups create content and pages meant to be shared to child Publications.

2. Custom Page Types and Content Types. Depending on where the "prototypes" for these live, you'll get content or pages created in a different Publication than the contexts set in XPM.

Localization also affects context since editors are prompted to localize or "edit everywhere" (edit the parent) in XPM.

I've even heard that some customers will localize the "prototype" pages for XPM Page Types to take advantage of BluePrinting and localization--so editors will get a default page based on the right language in the right Publication.

Tip: as you work out your scenarios, look at the breadcrumb, use the BluePrint viewer, and see what opens using the Open (in form view) option to confirm the context for individual items.

Answer 2

What you are asking is a technical solution for a conceptual problem: the component publication is an attribute of the page; meaning that any component creation and/or edits on the page will take place in the configured publication.

Having multiple source content publications would therefore have to mean that only one of them is the "changeable source" publication for the current page as the system couldn't possibly know which publication to add newly created content to without having an actual brain...

A similar problem exists with localized pages and global content and structure masters; when adding content does one intend to add local or global content? And is a change to be applied locally or globally?

In general in such multisite/multilanguage implementations inline editing should be to change the published site (and not any of it's masters) as otherwise the paradigm of inline editing no longer holds (making the gap between editing and end result as small as possible); you might be editing master content that gets overridden along the way...

To make master content inline editable the master site should be published (internally only obviously) separately. I think the same will have to apply in your situation; give each department their own inline editing version of the site which makes only their "owned" content editable and has "their" publication as a context publication for the content.

To conclude: inline editing is designed as a lightweight solution for changing the end-result of authoring and editing; if authoring and editing are separate responsibilities in the organization (which is what I would conclude from your scenario) inline editing may not be the right tool for the job...