We recently had an issue regarding language fallback in Sitecore, where field values that were supposed to display fallback values showed up empty. This only happened when accessing the items via the API’s, everything looked right in the Sitecore GUI.
For both item level and field level fallback to work, a number of steps must be taken.
- — Site definitions —
In your configuration, make sure that the EnableItemLevelFallback and/or EnableFieldLevelFallback attributes are set to true for the “shell” website definition and for your public site definitions (which by default is the “website” definition but this is dependent on your setup). Use normal configuration patching to enable this.
- — Configure the language items —
Make sure that language definitions in Sitecore has fallback languages configured. And publish the language definitions when done.
- — Set item level fallback —
Configure the standard values of your chosen templates to enable item fallback. If you only need item fallback on rare occasions, instead enable item fallback manually on those particular items. And publish any changed template standard values and affected items when done.
- — Set field level fallback —
Configure your chosen fields to enable field level fallback. And publish any changed fields and affected items when done.
When all is said and done, things should look good in the Content Editor. If everything is published things should look good if you switch to the web database as well.
This was indeed the situation, but we still faced a weird issue where some fields that looked ok in Sitecore never the less showed up empty.
The issue occurred during a custom process involving exporting item data to Excel, so there might be some quirks in our code. During debugging it was clear that fallback was not working, every field was empty. Some more debugging showed that the current SiteContext during this Excel export was the “website” site definition. Apparently this was set deliberately and explicitly by some coder in the past, probably to avoid using “shell” as the current site.
And that was it. The solution in question has multiple public site definitions for different brands and we no longer use the “website”. It still exists in the configuration though, which effectively lets the Excel export go about its business without a null reference crash. The site definition for “website” did NOT enable language fallback. This was taken care of like so:
Conclusion: In addition to the four items in the above checklist, also remember this:
If you add your own site definitions, consider scrapping the “website” site or at least make sure that “website” also enables language fallback appropriately. In older versions of Sitecore, there were a few bugs where the “website” was hardcoded in some places, which will cause errors if “website” is removed.
Coresighted 