4

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:

Content Context Selection 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,

  • With regards "intercepts the component Save event and reassigns the context (Containing Folder) in the right level of the blueprint" - the big thing to watch for here is when dependant items have been added at the child-level (such as local images etc.) which will conflict with changing the context - I've come a cropper with this bugger before. Of course, the same of templates and keywords (and even schema if created lower down the publication). – Dylan .. Mark Saunders Feb 2 '15 at 8:58
3

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.

| improve this answer | |
1

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...

| improve this answer | |
  • 1
    I don't think it is a conceptual problem, rather a design 'choice', the use case is simple: I want to manage content and/or pages using experience manager and want to make sure that when I create components and/or pages they are created in the right publication within the Blueprint Structure. Experience Manager is "the" tool, since there is certain functionality that is only exposed through it, so it should be the unique UI used by content authors and/or editors, but that's my opinion, and that's what SDL (and I) believe in. – Jaime Santos Alcón Feb 4 '15 at 12:31
  • But how will XPM know where to create a new component when an editor uses that option? XPM would have to understand how your organization uses your blueprint model and map the user to the correct part of the organization and the correct publication in the blueprint. XPM is designed around the paradigm that you will be editing/creating content in one publication only (even though it supports creating pages or publishing in another publication). – Bjørn van Dommelen Feb 5 '15 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.