I am very familiar with Presentation Details and inheritance, as well as the Sitecore 8 documentation on Versioned Layouts, but I feel like Presentation Details are all too often one of the most fragile pieces of architecture on my sites.

The loose-coupling challenge is also throwing me. Without using template inheritance, which often means inheriting the Presentation Details of items in other modules, I am having trouble devising a strategy that is easy for the client and our internal teams to maintain.

What I am looking for is a Presentation Detail strategy that prevents tight-coupling, keeps overhead low, and provides for easier maintenance. When I say "strategy," what I mean is a set of rules, like "Always declare on Standard Values. Do not depend on Standard Values inheriting from other Standard Values and instead copy the Presentation Details before modifying."

Has anyone developed an effective strategy for Presentation Details that works well the above focuses?

2 Answers 2


Start by reading the Sitecore Helix Documentation. The component-based architecture it describes is definitely the way to go. Most of the accelerators use something like it even if they don't use the Foundation-Feature-Project layers.

Most of the accelerators also move presentation details away from the template standard values to some extent. SXA has Composite Renderings, Partial Designs and Page Designs. Other accelerators also use things like the Placeholder Fallback mentioned by Derek or Cascading Renderings. There's also my Base Layouts project (GitHub) which I have been neglecting lately. It should go without saying at this point that all of them use Dynamic Placeholders.

  • I've read the Helix documentation many times, but it doesn't say anything about presentation that isn't already written in best practices. The strategies employed in the links that you posted might help me improve my current one! Thanks so much for your response! Commented Oct 15, 2016 at 1:57

One strategy that has served me well is called Placeholder Fallback and was originally blogged by Charlie Turano at Hedgehog. In this strategy, you define your presentation on a parent item and it is inherited on all descendant items that contain a special fallback rendering. This avoids the issue of inheriting presentation from standard values across templates, and is especially useful for global renderings such as headers, footers, navigation, etc.

For example, your home page's presentation could be defined as:

 header / Logo Rendering
 header / Navigation Rendering
 header / Breadcrumb Rendering
 main / ... 
 footer / Copyright Rendering
 footer / Footer Navigation Rendering

While on all sub-page templates, the presentation would look something like this:

 main / Fallback Rendering (header)
 main / ...
 main / Fallback Rendering (footer)

In addition to keeping your presentation details lean and centralized, the components defined on the homepage will also support Personalization and Testing across the entire site, which is not possible by default.

  • Thanks so much for posting this! I actually hadn't seen this article and it was a super interesting read. I am going to experiment with it this weekend! Commented Oct 15, 2016 at 1:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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