XPM - Inline Editing BluePrint Context settings behavior

Question

I'm trying to understand the reasoning behind how XPM treats the Inline Editing BluePrint Context settings, because it’s not functional in its current form. If this behavior is by design, then XPM is lacking a core feature of the CMS. In that case, is there any workaround or fix available?

To keep things simple, let's take the default DXA Blueprinting with two additional Publications as illustrated below:

The test is performed on the two 500 publications with different Inline Editing BluePrint Context settings:

• ‘500 asos’ doesn’t have any set
• ‘500 pmarjanov’ has them set to:
  • ‘DXA 400 Example Site’ for Pages
  • and ‘DXA 200 Example Content’ for Components.

If the Inline Editing BluePrint Contexts are not set, XPM behaves normally and recognizes that an item is shared. This manifests by the padlock icon and the menu which offers to edit everywhere or localize (both on Components and the Page). Also, the breadcrumb has the correct Context Publication (highlighted below). New items (Components and Page) are created in the Context Publication (500 asos).

If the Inline Editing BluePrint Contexts are set, XPM behaves in a “weird” manner, where the items are directly editable even though they aren’t local in the Context Publication. I’m saying weird because this is opposite of how the CM works, but I guess this is exactly what was envisioned by the Inline Editing Contexts concept. Creating items happens at the Publications defined in the settings and not in the Context Publication.

Based on the analysis above, to me the Inline Editing BluePrint Context appear to be a mix of the following two:

1. Ignoring the Context Publication for items, sort of a shortcut for the ‘Edit Everywhere’ button
2. a shortcut for creating the items in their desired levels instead of the Context Publication

However, 1) is completely undesirable. Why is this even introduced into XPM? In reality, you would need only 2) in combination with the way how items are being treated when the Inline Editing Blueprint Context settings are left empty (the regular Blueprinting rules). Is there any way to achieve this?

Put into practical terms and scenario, now you have to choose between being able to localize an item from a “language website” and not being able to create new Pages or Components in their proper Publications, only local ones, or being able to create items in their relevant Publications, but never being able to change their Blueprint status.

• Tridion Sites 9.5, but it's the same behavior in previous versions as well (specific versions in which I recall observing this are 2013 SP1 and Sites 9)
• DXA .NET 2.2.6 (though not really relevant in this context)

Answer 1

@Rick gives the context on why Experience Manager has the context setting. I'll add a little more at the end of this answer.

Except for shared items that are owned in the same "context" Publication setting, the "regular" BluePrinting rules do apply for localized items. So though the setting mentions XPM will read from the configured Publication, this doesn't change the behavior for things like translated content. The XPM user will see the correct version of an item.

With an XPM Publication context set for a Publication, at least for preconfigured Content Types, new Components will be created in the same Publication as the prototyped Component. Pages will also be created in the same location as the Page Type (though I think this only works for Publications at or above the configured Page Publication context setting).

For example, you can have a "Local Article" Content Type as well as Content Types to create content in other layers in the BluePrint.

Otherwise, XPM editors still have the ability to use the shortcuts to the Content Explorer, Where Used, or the BluePrint viewer to edit, go to, or localize content and pages, albeit through a few more steps.

---

Interestingly, I'll add that when we revisited the concept of "context" for Experience Space, we considered making "edit (in) parent" the default behavior. When we asked what editors typically expected when they edited an item, most said they would automatically edit the owning (or parent) item. Localize would have been an explicit, separate action. But rather than making editing the default behavior, we showed editors items, possibly in "context" (on a page), where the editor can choose whether to localize or edit a shared item.

For XPM, for the trade-off between making the choice for the global or local editor versus nearly always prompting "do you want to edit everywhere," I think it's worth it, though I agree it's weird if you really know BluePrinting. Perhaps the next iteration or update to XPM could balance clarity and ease-of-use (please submit ideas!).

Answer 2

The idea behind XPM’s BluePrint Context is that in typical BluePrints, your Components (nor Pages) don’t reside in the Site Publication (rather the Site Publication inherits them from higher levels in the BluePrint), whereas that is the Context Publication when using XPM.

For example, even in the simple OOTB DXA BluePrint, the content Components reside in the “200 Example Content” Publication, whereas you use XPM on the “400 Example Site” Publication. You don’t want to localize nor create any content Components there, though; content Components should be created and edited in 200 Example Content.

If you add translations in the mix, you may have 500 Translated Site Publications underneath 400 Example Site, but you will also have 300 Translated Content Publications underneath 200 Example Content. So, still your Components are not in the Site Publication and now (most of) your Pages aren’t either.