A critical portion of understanding Site Clusters is wrapping your head around Shared and Final layout, and understanding the impact this has on your content authoring experience. The concept of Shared and Final renderings was introduced in Sitecore 8, and added to the Experience Editor ribbon in Sitecore 8.1. Since then, I’ve seen many people who are confused about what these features actually provide and who struggle with understanding the implications of using one over another.
Accessing Shared and Final
First of all, accessing Shared and Final presentation is pretty straightforward. In Experience Editor for Sitecore 8.1+, you will see a toggle switch for Shared and Final presentation:
This toggle was introduced in Sitecore 8.1. If you’re on Sitecore 8.0, and using SCORE, then SCORE will provide a similar toggle under the Home tab.
Also, when you check out the presentation details of a page you will see two tabs in the renderings dialog now, Shared and Final:
Additionally, in the Reset Presentation Details dialog, you should now see options for resetting both the Shared and Final presentation of an item:
Wait a second! I can reset versions of Final?
That’s right. This is the key difference between the Shared and Final renderings. The Final renderings are language dependent and versionable. Changes to Final renderings go through workflow, and they’re translatable.
As you can see, the Shared renderings are… shared…
This means that Shared renderings (or just ‘Renderings’) apply to all language versions. Final renderings apply to the specific language version that you are currently editing.
On a side note, Sitecore is storing XML in these fields. When we change presentation details (moving components, adding components, etc.), we’re updating this XML.
The real take away here is that Final Presentation is used for two primary things:
- Support a different look and feel for different language versions of the same page.
- Use publishing restrictions and versioning to gain fine-tuned control over page presentation.
What’s actually happening here?
I didn’t want to get too deeply in the weeds on how this works inside Sitecore, but what you should know is that Sitecore introduced “Layout Deltas” to achieve this. The Final Renderings field is basically a set of instructions on what to change from Shared presentation. The other piece that you may want to consider is the order in which Sitecore calculates presentation:
- Apply all renderings from Standard Values in Shared mode, then…
- Apply renderings from Standard Values in Final mode for the current context language, then…
- Apply Shared renderings from the current page item in Shared mode, then…
- Apply Final renderings for the current page in the current language context.
This means that if you want to absolutely ensure that something appears on a page, the Final Presentation is the last piece that Sitecore considers and changes to final presentation will win out over changes to shared presentation or standard values.
Editing fields vs. editing presentation
One critical distinction that most people miss is understanding when they’re actually editing the presentation. If I open a page in Experience Editor, for instance, I may see lots of information like so:
If I select an individual field to edit, it doesn’t matter if I’m in Shared or Final presentation. When I’m editing a field, I’m editing that datasource (or the current page, if it’s a page-level field) in the current context language. I’m not actually changing presentation at all. This is an important distinction to make, and you should always keep presentation and data separate when conceptually thinking about Experience Editor. Of course, to change language in Experience Editor, I can use the Versions tab.
When I initiate an “Add here,” “Move to here,” or edit component properties, I am editing the presentation of the page. You can see these below:
What we’re actually doing here is changing the XML that is stored in the Shared or Final Presentation fields for the page. For instance, when I add a new component to a page, I’m adding an entry to the presentation XML field that specifies which rendering and which datasource is being used. This is where understanding the difference between Shared and Final is critical.
Understanding Shared and Final presentation
When I am editing Shared presentation, I am editing the renderings that will appear across all languages and all versions of the current page. When I am editing Final presentation, I am editing the renderings that will appear in the current language and current version of the current page. It’s that simple.
Need to add a 2 column structure to all language sites? Do it in Shared.
Need to remove a highlight for Spanish specifically? Do it in Final.
Here’s a chart to help you understand what changes in Experience Editor affect your Shared and Final presentation fields:
| Action | Affects Shared/Final Layout | Where should you do this? |
|---|---|---|
| Editing a field on the page (image, text, etc.) | No | Doesn’t matter |
| Switching from the English Language to the Spanish Language | No | Doesn’t matter |
| Changing text in a field in the Spanish language | No | Doesn’t matter |
| Removing a component (rendering) for Spanish only | Yes | Final Presentation |
| Adding a component (rendering) for Spanish only | Yes | Final Presentation |
| Moving components on the page for all languages | Yes | Shared Presentation |
| Editing Component Properties (rendering parameters) for all languages | Yes | Shared Presentation |
| Editing Component Properties (rendering parameters) for the Spanish language only | Yes | Final Presentation |
| Changing a personalization rule for all languages | Yes | Shared Presentation |
| Changing a personalization rule for Spanish only | Yes | Final Presentation |
Strategies for managing presentation in a Site Cluster
So you’re going to build a Site Cluster. Did you think about your presentation strategy? It’s easy for this consideration to fall through the cracks. Here are some strategies which may help you moving forward:
Option 1: Everything in Shared until your site is launched
With this strategy, you will build your Standard Values, Branch Templates and Content Tree in the Shared presentation mode. Then, during the launch phase of your site, you:
- Completely disable access to Shared presentation and force all users to only be able to edit Final presentation;
- Enable workflow across all items and page types.
I recommend this strategy if you’re focusing on a single language website first, and then moving on to adding multilingual support in the near future. One of the major selling points of this strategy is that you can assemble your site completely for your first or “primary” localization, and then worry about your other languages later. When you eventually switch to editing your other languages, you’ll already have a good starting ground to build your pages from.
This strategy also works out very nicely for sites that you think are going to be for a target localization, but end up targeting other localizations in the future. For example, you’ve built your website and launched it for the US. Two years later, Marketing comes to you and says they need to launch the same site for Mexico and French Canada. Good thing you did your assembly in Shared!
Option 2: Templates in Shared, and Content Tree in Final
With this strategy, you restrict access to Shared presentation from the start. The only users who can really touch Shared presentation are the developers, and they’re only using it to configure their templates. This strategy works extremely well when you need the ability to change presentation across all of your pages in one place. You can make changes to shared presentation in your templates and, since your content doesn’t “override shared presentation,” it will automatically propagate out to all pages. There are some design limitations in getting this to work correctly, and the majority of your components will need to be customized to pull from page-level fields, but in general this works out nicely.
Language copying is another consideration when choosing this strategy. If you’re using SCORE, there is a Language Copy tool built into the system. Since you’ve done your component assembly in Final presentation, you’ll likely want to copy those presentation settings to each new language you introduce so you don’t have to reconstruct your pages from scratch over and over. If you’re not using SCORE, you can very easily create a Sitecore Powershell script to allow content authors to do this. Otherwise, you’ll need to roll your own copying mechanism.
Option 3: Renderings shmenderings – Why should I even care?
Sadly, I see this strategy used a lot. Often times our team at Brainjocks, now Perficient, will be tasked with helping other teams with their assembly. When we get in and find out that a mixture of Shared and Final presentation were used without careful consideration, it’s always a painful fix. Typically, when we come across this, we’ll write a Powershell script to migrate everything out of Final presentation and stick it into Shared presentation; then, we’ll roll with Option 1. Don’t do this. Please.
Considerations in a SCORE solution
If you happen to be using SCORE in your Sitecore installation, we have a particular pipeline which forces users into Shared mode when they open Experience Editor for the first time. We do this because we usually end up with the Option 1 strategy on almost every build (where multilingual is either out of scope or not a priority). This pipeline is patched in via Website\App_Config\Include\zzScore\zzScore.DefaultEditorMode.config, and you can read about it here.
Hope this helps!
