I was recently tripped up by a publishing error in Sitecore that dragged me kicking and screaming into understanding the new inheritance logic that underpins layout settings. The error was the usual helpful Value cannot be null, directly after a Database.GetItem() call. OK thinks I, there must be a broken link somewhere. Two hours later of adding and removing sublayouts, publishing, re-publishing, staring at XML, commenting in, commenting out, copying and pasting, I had me an understanding of how the oh-so-important __Renderings field now functions. Now I look forward to the fix that stops the following error occurring when I forget to publish my standard values item that contains half, yes half, of my presentation data.
So, what’s new?
I recently had a meeting with Sitecore Australia’s Steve Green, in which he mentioned in passing the upcoming changes to presentation. It “stores the delta between your standard values and the item”. This sounded interesting, we’ll save countless man hours usually spent updating settings on multiple items due to a tiny change in the UI. I left the meeting looking forward to the next version, 6.5. Unbeknownst to me, this functionality was already alive and kicking on our current implementation on version 6.4.1.
The Delta, you say?
You might be familiar with the XML structure that is used to store presentation. The following image shows the basics, an opening r element(for Renderings), one or more d elements (for Device) and a number of r elements (for Rendering.. or Sublayout as I’ll refer to them here). Each Device element will have a GUID that defines the Layout to be used for that Device, while each Sublayout element will have a GUID reference to the Sublayout, the placeholder it will be added to, the parameters containing settings and/or content .. plus a number of other attributes and settings that describe its functionality.
Usually you’d configure this using the Sitecore interface by editing the __Standard values item of your template. Any items based on this template will then use these presentation settings until the time you make a change to the item presentation – for example, by updating the RichTextContent parameter and adding a promotion to the content_right placeholder. Previously at this point, the entire XML would be updated and stored in the item’s __Renderings field, replacing the XML from the standard values item.
As of version 6.4 however, the layout XML on the item contains just the differences between the standard values and the item. The new layout info is distinguished by an attribute namespace, s. In our example, the majority of the configuration for the RichText Sublayout remains within the standard values item, and is now referenced by its uid attribute, with the updated RichTextContent value stored within s:par, signifying that it overrides the original par attribute from the standard values item. Likewise, the new promotion Sublayout is added with all attributes but with the s: attribute namespace.
Sitecore will now get the standard values information and merge it with the delta in the item, allowing you to change common info. For example, if we needed to move the RichText Sublayout into a new placeholder, or update caching options, this could be done on the standard values item and published with one simple change, rather than update every item that uses the template as we had to do in the past. Great stuff.
So that’s it, basically. Whatever you do, don’t forget to publish your template’s __Standard values item before the item, or you’ll get that nasty publishing error. The null reference error occurs because the uid attribute is the reference to the same rendering in the standard values. As of version 6.4.1, Sitecore won’t let you publish an item without the target uid existing.
Update: the publishing error was fixed in Sitecore CMS 6.4.1 rev.110928 (6.4.1 Update-4). Fear not the publish – fire at will.