Intro

Some time ago I read a question on tridion.stackexchange about BluePrint Context feature in Experience Manager. Once more got proof that understanding this feature and resolving the right context for creating new Pages and Components in different BluePrint scenarios is a daunting task. So together with my colleague @Alvin Reyes we decided to share some light on the darkest corners of this feature. We will publish a series of blog posts that explain what BluePrint Context means as well as describe the expected behavior related to creating new Pages and Components in Experience Manager in various BluePrint setups.

 BluePrint Context feature in Experience Manager

Let’s start with some definitions.

Any given BluePrint structure can be presented as a chain - a flat ordered list. For instance, let's assume the following BluePrint structure:

The BluePrint chain for Publication G will look like this (taking into account inheritance priority shown as 1 and 2 on the branches):

And the BluePrint chain for Publication F will be:

To simplify the task of resolving the right context we will be presenting an original BluePrint structure as a flat BluePrint chain. Every Publication in the chain will have a priority. The higher the Publication is in the chain the lower its priority.

An Experience Manager user is always working in the context of a given Publication. We will be calling it a current Publication. The current Publication has the highest priority in the BluePrint chain.

It is possible to configure default BluePrint contexts for Pages and Components. These are Publications in the BluePrint chain for the current Publication where Pages and Components will be localized and edited by default. We will call them Configured Page BluePrint Context and Configured Component BluePrint Context. Configured BluePrint Contexts are defined for publication in the Experience Manager Settings panel.

BluePrint Context settings page in Experience Manager

If no BluePrint context is configured, the current Publication is used as the Configured Page BluePrint Context and the Configured Component BluePrint Context.

Every item in Content Manger has an Owning Publication. An Owning Publication is a Publication with the highest priority in the BluePrint chain where the item is localized or local.

In most cases we will be working with a resolved BluePrint context of an item – it's either the Configured BluePrint Context or the Owning Publication, whichever has the highest priority.

In the picture Configured BluePrint Context is set from publication D to publication C, having publication B as owning publication (where an item is local or localized). As a result resolved BluePrint Context will be used from C since it has a higher priority (shorter path) than Owning publication.

In the picture Configured BluePrint Context is set from publication D to publication B, having publication C as owning publication (where an item is local or localized). As a result resolved BluePrint Context will be used from C since the path to owning publication is shorter than Configured BluePrint Context that is set.

Summarising everything said above, BluePrint context can be used in Experience Manager to identify alternative publication(s) from which it should read/save Page(s) or Component(s). BluePrint context can be configured for a given publication by a customer using a setting page and set to a publication where it is expected that Pages and Components will be localized and edited by default.

By configuring them you are simplifying daily work for your Editors by allowing them to work in the context of a given page without the necessity to know that certain Components on this Page or even the Page itself are shared items that should be edited in a parent publication.

Hope it made it a bit clearer this time. In the next post, we will take a look on a Page creation using Page Types.