Infinite loop with language fallback and non-standard named standard values item

Search for a command to run...

No comments yet. Be the first to comment.
Polly is great library for easily configuring different kinds of policies around code execution, be it retry, circuit breaker, caching or lots of other things. It's probably most often used around HTTP requests. If you haven't heard about it you defi...

This is part 2 of my series on unit testing in .NET (C#) and will be about my conventions regarding naming unit tests, how to structure them and which parts to test. And lastly I will help you increase readability of assertions and potential error me...

I feel like unit testing is very important and very beneficial in a lot of ways. It helps with not breaking existing functionality and thereby also making you more confident in changing code without fear of breaking important stuff. Often it also mak...

I've been working with Swagger through NSwag a lot recently and also needed to get it to work when hidden behind a reverse proxy - i.e. another service forwarding a request to the service exposing the Swagger UI. Some of the issues I've had along the...

The other day I was writing a unit test to verify what was supposed to happen when a Task would throw an exception when awaited. It wasn't as straight forward as I first assumed, but I quickly found this Stack Overflow post that helped me: https://st...

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.