Setting __Renderings field not shared in Sitecore consequences?

7
votes

Does anyone have experience in setting the __Renderings field in Sitecore to not be shared? We are building a multi site-multi language solution and would need the (sub)layouts to be different in different languages. For example, the English language site could have a sublayout that the Swedish version of the same item does not have and all presentation components does not always have the same data source for different languages.

A somewhat easy solution to this would be to simply uncheck "shared" on __Renderings field in the /sitecore/templates/System/Templates/Sections/Layout template, but does this have any other consequences? Or is there a better way to handle this requirement?

4
sitecoresitecore6
One major drawback is that you are modifying a sitecore system template which is not supported. This will make future upgrades more difficult. – Matthew Dresser
In addition to your Language example, there is also a use case for varying presentation between item versions. For example, changing a datasource on a rendering between version 1 & 2, or simply changing the sort order of renderings. This is not possible when "shared" is checked. – Derek Hunziker
@DerekHunziker +1. Very good point. Also it's impossible to use workflow with the out of the box Sitecore "shared" field. It's a pretty big fail on Sitecore's part. They get away with it because most people publish on-demand when the workflow state changes, meaning the shared field only gets published in-line with workflow changes. But as soon as you use scheduled full-site publishing (or similar) then that shared field gets published to your web db whilst all the rest of your edits are still in draft, leaving you with missing rendering items and all kinds of broken layouts. It's terrible. – theyetiman

4 Answers

5
votes

My own preference when needing to swap around visual elements based on something like language, country of origin, etc. is to use Sitecore's personalization rules editing to swap data sources and alter the presentation in that manner. It doesn't involve changing Sitecore's default behaviour and allows you to tap into built-in Sitecore functionality.

If your different 'sublayouts' are actually just the datasources being pulled in by various personalization rules, you can configure all of this with OMS/DMS and rely on the Sitecore engine to present the components you need given the current state. For performance, going with the most recent version of DMS is probably best (I believe 6.5 Update 5 is now the recommended release).

2
votes

Modifying Sitecore's default behavior in this way is usually not a good idea. It's not transparent for others people that might work with the system in the future and it could lead to unexpected results.

Imo, it's better to make a switch inside the (sub)layouts so it loads different files based on the current language.

As for the consequence. It will work as you expect when you make the _Renderings field unshared. You will be able to set different presentation details for each language version. The consequence is that you must now set it for each language version... so it will be less easy to manage.

2
votes

We have indeed done this, and for the most part there are few side effects. In fact, it's the only way you are going to get workflow on __Renderings changes. We combine it with Partial Language Fallback so that languages can inherit the value from English. However be careful, as if an item is cloned, it will always pull its default value from the clone first, rather than standard values / fallback.

1
votes

I would instead use the the Devices of sitecore. For each language you can define a Site and each site can have their own Device. This will work out-of-the-box if you have one domain name forr each language (www.site.com, www.site.de, www.site.fr etc...)

If you have one site (one host name) for all languages, you can switch the devices with a httpRequestBegin pipeline processor.

This article, http://briancaos.wordpress.com/2012/04/12/identifying-mobile-devices-in-sitecore/, describes how to identify mobile devices. It is not hard to rewrite the logic to switch devices depending on the language.

When you have defined different devices for each language you simply place the renderings on the device matching your language. And you still have the possibility of a fallback device for all those pages where all renderings are the same.

Modifying the Sitecore default behaviour might work for now, but using and extending the Sitecore platform is a better way forward.