Sitecore item and version design flaw

2011-01-11 | Sitecore Bug

I have a multi-lingual Sitecore (6.2) site that has been having many issues with item versions showing up in their site myseteriously. The client has over 12 languages in their site and certain items shouldn't be accessible to certain languages. Now, Sitecore says simply don't create a version of the item and it won't appear in the site for the language. Perfect? Nope.

There are dozens of pages scattered in the Sitecore tree that shouldn't exist in the English site. However, on any given day one of these pages starts showing up in the English site. There isn't an English site author creating a version and, to make it even more frustrating, there is no audit trail of them being created! I've logged about 10 'bugs' with Sitecore on ways to have these versions magically appear in the tree (and there are more that I haven't reported). Most of them have been addressed with hot-fixes, but I think it boils down to one fundamental issue with Sitecore...

**A Sitecore item NEEDS at least one version. **Shared fields are the reason we need a version. A "shared field" is a field whos value has no boundaries. The value is available to all versions in any language. Things like workflow, security, display name, sort order, etc... are stored in a shared field on a version of an item. If you have an item with no version than it has no security, display name, or sort order.

This leads me to one of my bugs. As an example, try this.

Create a little subtree of five items names 1, 2, 3, 4 and 5. Now:

  1. Remove all versions from this item
  2. Sort item '5' using the 'First' sorting button
  3. Sort item '5' moving it 'Down' below item '1'

You should now observe that there is a version for every item in our subtree. We only worked on item '5' yet all items have a version. This shouldn't happen; I never told it to create a version!

Once you introduce multiple languages into the equation it gets better! Say you have this same sub-tree and they all have a version in English. Now, change the language you are working on within Sitecore to Danish and resort the tree. You will notice that Sitecore went ahead and created Danish versions of all the items. Worth noting is that the version that was created would have bypassed any language security too. Why couldn't Sitecore just save the sort field on the English version (it is a shared field)?

I will admit that my example is a bit contrived. It probably would never exist as is, but we do have a client that has items scattered in their tree that do not have any versions. I will also admit that this could be a training issue, but I still feel it raises a fundamental flaw in the system.

I think the first step in fixing the problem is that there NEEDS to be at least one version of an item. The "Remove Version" button should check to see that it isn't the last version of all languages. If it is the last version then it can't be deleted.

I would love to hear your thoughts.

P.s. I haven't seen Sitecore 7.0, but I can imagine that the fundamental architecture changes with it will (hopefully) address this.

Other Posts

Comments

Right, it would be logical to get rid of that "Zombie" items which does not have any version. There is also another quite similar problem - about language fallback issue which frequently happens on multilingual solutions - there is great approach recently released by Alex Shyba: http://sitecoreblog.alexshyba.com/2010/11/approaching-language-fallback-with.html. I think something similar should be implemented in one of next Sitecore CMS version. Interesting information. thank You.

Correct link to blog is here :) http://sitecoreblog.alexshyba.com/2010/11/approaching-language-fallback-with.html

Brian Pedersen says:
2011-01-12T17:28:31.0000000Z

I just tried it on my Sitecore 6.3.something. If I chose an item, change the language to one without any versions on and click sort/Up or sort/Down, the item magically is assigned a version to the selected language. The children or siblings aren't assigned a language version. That's a small comfort. I guess the problem arises because by changing the sort order, you update the "SortOrder" field, and Sitecore needs a version in order to update the field. I haven't tried to change sort order on items in a Workflow, but I guess you will experience the same issue here, as you in fact does an update of a field when moving an item.

Alistair Deneys says:
2011-01-13T04:00:18.0000000Z

Interesting issue. I can see why Sitecore does it the way they do (as Brian describes above) and I have also witnessed the issue myself previously where an item existed but had no versions in any language. I know you're after a discussion about how Sitecore should behave, but for anyone scratching their heads wondering how to work around this issue, simply verify the current item version has a created date. I'm not sure if that will work for the example above, but it worked in my case where an item didn't have a version in the current language.

We've also had issues with this in the past and I never really understood the reasons behind this behavior. It's something that should be fixed in the future so I understand your frustration and "support spamming" :) Good article!

Sean, hate to do this, but I could not find another way to contact you. In a previous post you spoke of the REST api for Sitecore, but in 6.4 it seems to have been eliminated. Do you know if it still exists via another path? If not, do you think taking that page from an old version of SiteCore and putting it into 6.4 might work? Thanks, Keith J. Leslie Inspiro Solutions Group, Inc.

Keith, That page was pulled some time ago. I don't remember exactly what version, but somewhere around 6.1. My guess is that the page had ties to version specific Sitecore dlls that would no longer be there.