Rendering Data Source Saved as Path Can Cause Trouble in Sitecore

Benjamin Vidal Benjamin Vidal
June 22, 2012
Sitecore , Web Development

As the number of Sitecore 6.5 implementations ramp up and we transition more users into the use of Page Editor, we've recently uncovered a problem with the default handling of how a data source is saved that can cause alot of problems for content authors if not addressed.

Basically, the situation is as follows. A content author can add a component to a page (for example, let's say something called "Related Blog Post") and subsequently choose the data source for that component (using our example component, they would be choosing which specific blog post to show as being related to their page).  Now here's where the risk of a problem begins. That selected data source for the component is saved as a path (i.e. /sitecore/content/blog/example-post). If that blog post were ever renamed or moved, the path would become incorrect resulting in a broken component on that page. Of course, this is a problem because one of the core features of the CMS is the ability to rename/move content.

This issue came to light recently as we've rolled out more projects with heavy use of Page Editor. We have completed many Sitecore projects and it just dawned on me that I had never really noticed that when you assign a rendering data source (under Presentation details), it is saved as a Sitecore path. When you view "Raw Values" you will see the rendering's data source as a path. This is not a big deal if the data source's path never changes, however, authors can always rename/move the item.

The consequence is that if the item is moved, renamed, or experiences any other alterations to it's path, the rendering will not work. Actually, it may result in a nasty error if you don't catch the error. For sublayouts, you are able to trap it because you should be checking if the item exists before you use it. But for XSL renderings, where it gets automatically assigned to "sc_item," we normally ignore checking if it exists or not. Anyway, this is a potential problem that a Sitecore developer should be aware of.

The next issue is, can I switch it to an ID? I'd rather have a Sitecore ID so it doesn't matter what you do to the item (as long you don't delete it), the rendering will always find the item. So, I tried to enter an ID in the data source and it worked! Now, the only problem is how do I get the ID of the item that the user selects when assigning the data source item?

So, I ventured to see if there is a way to change how a user assigns the data source. I went with the premise that almost everything in Sitecore is defined... in Sitecore. Also, I know about rendering parameters. Then I thought, I bet Sitecore created a rendering parameter for this purpose. After a few seconds of looking, I found it:

/sitecore/templates/system/layout/rendering parameters/standard rendering parameters

In it, you can see several sections but the one I'm interested in is the 'Data Source' field. By default, it is an Internal Link. Unfortunately, that produces a path as its return value. I did try to figure out if it has any parameters to tell it to result into an ID or path, but I didn't find one. So, I switched the 'Data Source' field's field type to something that returns an ID such as a DropTree (and consequently should only allow for one value). Saved it and tested it.

Obviously, this now changes the way your user selects the item from a pop-up to a tree. After assigning the item, I switched back to raw values and the data source was now an ID.

One thing to remember, if you're going to do this on an existing site, the original path value gets preserved until you actually go in and re-select the same data source and save it. So, I recommend you update all your rendering data sources by either manually going to each presentation details or creating an update script.

Roundedcube is going to make this change for each website we build from this point forward which will reduce the possibility of an exception that will in turn increase site reliability. I hope Sitecore implements a change as well to address this situation, so we don't have to worry about possible upgrade issues in the future. By the way, this works in Page Editor!

comments powered by Disqus