Scenario #1: A client is migrating from an existing CMS and pulls the content from the existing cms into Sitecore on a regular basis during migration to reduce the size of the outage windows for Clients.
Scenario #2: A client injects data into Sitecore from an external system via clearing all the nodes under a certain node in sitecore and then re-imports the content items.
In both these scenarios the Guid would chance for the content item but the path would remain the same.
In Sitecore 6.6, this would work fine as the DataSource property of the sublayout stored the Item Path.
In Sitecore 7.0, a cool advancement was introduced that allowed you to move content around and it would automap the DataSoure much like it does with content links. Nice feature but in the above scenarios it will break existing SubLayouts.
Workaround: This is not ideal but if you place text in front of the item path eg. "ITEM_PATH:" then sitecore cannot resolve the sitecore path so it will keep the string there. Then in the sublayout when you grab the DataSource you look for that string and remove it before calling GetItem. Here is some sample code:
if (string.IsNullOrEmpty(subLayout.DataSource))
return Sitecore.Context.Item;
string dataSource = subLayout.DataSource;
Item dataSourceItem = null;
if (dataSource.StartsWith("ITEM_PATH:"))
{
dataSource = dataSource.Substring(10);
}
if (Sitecore.Context.Database.GetItem(dataSource) != null)
{
dataSourceItem = Sitecore.Context.Database.GetItem(dataSource) ??
Sitecore.Context.ContentDatabase.GetItem(dataSource);
Log.Info("CurrentContextBased On Data Source (" + dataSource + ")", this);
}
Alternatively someone could override part of the mechanism to handle "ITEM_PATH:" much like Sitecore itself does currently with "query:" If someone has created one, and is willing to share it in MarketPlace for others to use, let me know and I will reference it here for others to access.
If you have any tips, tricks or resources you would like to share with the Guild please email them to chris.williams@threepointturn.com or dennis.augustine@threepointturn.com and we will share them with the Guild.
Hi Chris, nice post.
ReplyDeleteI love that Sitecore 7 uses Guids now. So much more stable!
I was wondering, in your examples how will the new changes affect existing sublayouts? I think Sitecore will only try and update the item paths to Guids in DataSources if the items renderings are changed and saved. (i.e not automatically in an upgrade).
Also, database.GetItem() should be able to take a string, whether it's looks like a Guid, or it looks like a path, and be able to figure out which one it is, and find the item.
If the item doesn't exist in a path specified, the sublayout would already have been broken, even in Sitecore 6.6.
...or maybe I'm not understanding the process behind the two scenarios you mentioned...
Thanks,
Sean
Yes if the item does not exist for the path that is a different issue. In my case we are clearing a section of the content tree and pushing new items back into the tree (delete and insert). By doing so the guid changes but the path does exist.
DeleteThe other scenario is when a user accidentally deletes an item and recreates it. The guid would change. In 6.6 you were ok but in 7.x it will break. This is mentioned in the following Sitecore 7 blog post
http://www.sitecore.net/Community/Technical-Blogs/Sitecore-7-Development-Team/Posts/2013/04/Sitecore-7-Datasources.aspx
Ah ok, I understand.
DeleteIt's an interesting scenario you're in, in that case.
Is this is just a temporary thing that happens during a migration phase...or an on-going, long term process?
If it's a long term thing, I could see potential issues, like removing an item and not replacing it, or renaming it. That's the sort of thing Sitecore 7's changes were trying to prevent.... but if you're usage of the breakage is something you require, then this is a nice little workaround.
This is just during migration so that we reduce the outage window as we migrate from one CMS to another. Once moved over fully to Sitecore 7 in production you don't need to sync anymore and can simply use the Sitecore 7 guid mechanism and remove the workaround. Once the workaround is removed you can then move content blocks and around and Sitecore will readjust the data sources for you.
DeleteI love the new functionality its a godsend, its just the initial gotcha during migration :)