Infinite loop with language fallback and non-standard named standard values item
Enable item-level language fallback and have a non-standard named __Standard Values
item and you're going to have bad time - specifically a StackOverflowException
. Those are notoriously hard to troubleshoot. Trust me...
Apparently the name of the standard values item, __Standard Values
, is hardcoded inside Sitecore in several places - which makes sense as the item isn't otherwise discernible.
When item-level language fallback is enabled and you try to retrieve an item, it checks if item fallback is enabled on the item itself (checkbox field, part of the standard fields).
private bool IsItemFallbackEnabled(Item item)
{
if (item == null)
return false;
if (StandardValuesManager.IsStandardValuesHolder(item))
return item.Fields[FieldIDs.EnableItemFallback].GetValue(false) == "1";
using (new LanguageFallbackItemSwitcher(new bool?(false)))
{
return item.Fields[FieldIDs.EnableItemFallback].GetValue(true, true, false) == "1";
}
}
The call to StandardValuesManager.IsStandardValuesHolder(item)
ends up doing this check:
return item.Name.Equals("__Standard Values", StringComparison.OrdinalIgnoreCase);
So if the standard values item is not named exactly that, then it tries to get the field value again... and again... and again. You get the point.
This is probably not an issue you would run into very often, but it's always nice to be prepared. We ran into this issue with a client where we had installed an older version of the 301 Redirect Module (version 1.3 if I remember correctly), which had standard values items with a hyphen instead of a space in the name - __Standard-Values
instead of the correct __Standard Values
.
You can no longer download version 1.3 and later versions do not have this problem. The module has also recently been updated with a lot of new features like Content Editor notifications and automatic generation of redirects when items are moved.
The inifinite loop issue has been reported to Sitecore Support and they have filed it as a bug with reference number 118166.