[su_note note_color=”#fafafa”]Sitecore 8 comes loaded with new features. In this blog post I want to focus on Versioned Layouts. Please follow the link if you haven’t yet read about what it is and how it works. You will need some background knowledge to follow along.
UPDATE: I have continued looking into versioned layouts and posted part 2 and part 3.
[/su_note]
In A Nutshell
Presentation Details have been shared before. No language variance (almost). No workflow support. Sitecore 8 changed that. The __Renderings
field did not become a versioned field overnight. Instead, a new __Final Renderings
field was added to the Layout section of the Standard Template. This new field is versioned like most of your own data fields. There’s now also one more layer of layout delta to calculate before a page presentation is fully assembled.
Simple and Powerful. Right?
Well, let’s see.
Experience Editor
Sitecore 8 promoted Page Editor to Experience Editor but it’s still a good old Page Editor in a new suit and with some new tools. It’s a user-friendly visual editor that, when properly built for, empowers content editing teams to own their sites and enjoy the power of Sitecore’s marketing features (e.g. personalization, testing). Here at BrainJocks we always build Sitecore solution PageEditor-first and that’s why we created SCORE (here’s our short video from the most recent Sitecore Virtual User Summit).
Question Of The Day #1
What layout do you modify when you edit a page in Page Editor?
Before Sitecore 8 it’s an easy question to answer. Regardless of the language or item’s version you always modify the layout (it’s a shared field after all). When you open the __Standard Values
item in the Page Editor it’s that item’s __Renderings
field value. When you open the actual page item – you will create a delta against what’s on the template. You will be presented with the actual page layout with the delta merged in and then everything you modify will go onto the page item’s __Renderings
field.
It’s kind of the same in Sitecore 8 and yet it’s very different. You are sill presented with the actual page layout with all deltas merged in. Everything you modify will still record as a delta but this time it will land on the __Final Renderings
field. Which is versioned hence different per language. This is very important and I will get back to it. You no longer create a delta against your data template’s standard values. You now create a delta against the Shared Layout (aka __Renderings
).
Question Of The Day #2
Can you modify the shared portion of the layout?
Sure you can. But not in the Page Editor. The only place you can modify the shared portion of your item’s presentation details is the Device Editor dialog (aka Presentation ->
Layout ->
Details in Content Editor and Advanced ->
Layout ->
Details in Page Editor) which is not visual (not WYSIWYG) and not really user friendly if you go granular with your components (more than a few on the page) and/or use Dynamic Placeholders. When you modify the Shared Layout you create a delta against your template’s standard values (which itself is now also two values – shared and final – merged in together)
Let’s Break It Down
- Experience Editor always modifies the
__Final Renderings
field. It will be the latest version in the current language. You should always be aware of that and tell your editors. A rendering added to a placeholder in EN won’t show up in DE or JP or RU unless you either repeat your action or do so on the Shared Layout using the Device Editor. This is true for your template’s standard values as well.[su_note note_color=”#fafafa”]Always remember that visual editing in Sitecore 8’s Experience Editor creates a delta in the current language against the item’s shared layout.[/su_note] - When you migrate your content to Sitecore 8 from earlier versions your existing layout details will show up in the Shared Layout. Once you start modifying it in Experience Editor you will be creating delta (Final Layout) for the current version.
- Be aware of the API changes if you work with the layout field directly (
FieldIDs.LayoutField
)
One More Thing
I don’t believe it was ever possible to modify anything other than the latest version in the current language in Page Editor when it comes to content (the fields of the page item and the datasource items). I believe, however, that the Page Editor itself is technically capable of doing it. The artifacts produced by the renderField
pipeline can modify any field of any item in any given language/version combination. Content on a page (i.e. fields) can be coming from the page item or from the renderings’ own datasource items that are all versioned independently so that’s why Page Editor needs a fully qualifying URI to denote a field. An excerpt from the ChromeManager.js
:
this.setFieldValue = function(itemUri, fieldID, value) { // ... var id = "fld_" + itemUri.id + "<em>" + fieldID + "</em>" + itemUri.language + "<em>" + itemUri.version + "</em>" + revision + "_999"; // ... }
The “latest version in the current language” part is now also true for the item’s presentation details. Which leads me to another observation about the new Page Test feature. When you create a new version of the current page to test:
- You create the new version in the current language only. Any modifications in Page Editor will be recorded as delta in that version.
- You don’t have a way to go back and modify the original version in Page Editor. You can only get to that version in the Content Editor and modify it via the Device Editor dialog.
Thoughts
Versioned Layouts is a powerful feature. It enables things that were simply not possible before – language variations of the layout, workflow support for layout changes, versioning (with roll back) of the page look & feel, editing of multiple versions of the same page at the same time. Not everything is Page Editor enabled and that’s why I titled this post the way I did. I do have mixed feelings about it but it’s definitely progress.
That said, I am optimistic. Page Editor has always been not easy to architect and build for but it was and remains ours and our clients’ favorite content editor in Sitecore. We have built SCORE and have been enjoying making Page Editor even more pleasant for the editors and way more approachable for developers. We are committed to doing it in Sitecore 8 and beyond.
Until then, remember that Page Editor manipulates the layout delta for the latest version in the current language and use Device Editor to modify Shared Layout and/or other versions of the item’s layout.
I am kind of stating the obvious, but the consequences for larger multilingual platforms are also there in terms of multi variate testing and personalization.
As layouts are now managed on culture versions, so are the changing datasources of a multivariate test and personalized components. This is following the concept of versioned layout and in that way correct.
Though, platforms that rely on content marketers that add most page designs from the headquarters (whereas the languages themselves get translated locally or by translation agencies) would require them also to add personalization and tests for every individual language. The amount of work could be enormeous.
Do you know OOTB ways to apply these tests and personalization in a shared way?
MVT used to be shared pre-7.2. Starting with 7.2 it’s by language within the shared presentation details field. I blogged about it in another post of mine – https://jockstothecore.com/mvt-in-mvc-a-history-lesson/.
I haven’t looked into whether it is possible (or rather – how difficult and how custom will it have to be) to share MVT conditions across languages. In the shared pre-8 layouts you know the renderings the MVT conditions apply to are there. In 8+, however, final layouts per language versions can be different enough for an MVT condition not to make sense in all versions. You see what I mean? It will have to go into the shared layout portion to be applied across languages. Haven’t looked long enough into 8 to tell you whether you can do that but I don’t see why you wouldn’t be able to. Just not in Page Editor as that one works with Final Layouts only. You may have more luck with the Device Editor.
Pingback: Rock, Paper, Sitecore
Thank you for sharing the article.
I have a Sitecore 8.2 build which is behaving quite opposite way.
When I am making a second version for an item and making changes to the final layout, it applies the changes to all versions of that item.
Example. I added a new component on to the final layout of version 2 and the component appears in version 1 also.
Is this versioning enabled by default in 8.2 or should me manually change some config to enable it.