Fallback and Enforcing Version in Sitecore

I ran into an issue today trying to get proper versioning to work correctly in Sitecore, and got an answer on Sitecore StackExchange:

Glass Mapper - Item not null when language version not present

May 16 '19 Comments: 3 Answers: 1

1

I'm using Glass 5.4.18 with Sitecore 9.0.2. I have a base template for my site that has language fallback turned on by default, but for a few items the client wants to disable language fallback so the item does not appear in certain languages.

I've gone into the individual item…

Open Full Question

I thought I’d expand on the setup a bit, and go into my default arrangement for a base template. There are two kinds of fallback available in Sitecore, items and fields, applying primarily to multilingual website setups.

• Item fallback means that if you don’t have a version for a particular language, it will fall back and use the version from a specified fallback language (set in the /sitecore/system/Languages section).
• Field fallback means that when you create a new language version, instead of blank fields you’ll see the content of the specified fallback language.

Turning on item fallback is easy, just create a base item template to inherit from and check on the enable item fallback option. Turning on field fallback is a little harder to do globally; you can go to the base field item’s standard values (/sitecore/templates/System/Templates/Template field/__Standard Values) and check on the enable shared language fallback box, but there’s a bug that doesn’t have that setting propagate up the line and work properly. Sitecore has provided a patch DLL and configuration that they say works in 9.0.2, so they might need to adjust it for other versions. Note that as of 9.2 the patch has still not been applied in the Sitecore.Kernel file, but you can find it inside my ScHelix GitHub project:

kmac23va / ScHelix

Baseline Sitecore Helix foundation and publishing layers based on HelixCore

Welcome to GitHub Pages

You can use the editor on GitHub to maintain and preview the content for your website in Markdown files.

Whenever you commit to this repository, GitHub Pages will run Jekyll to rebuild the pages in your site, from the content in your Markdown files.

Markdown

Markdown is a lightweight and easy-to-use syntax for styling your writing. It includes conventions for

Syntax highlighted code block

# Header 1
## Header 2
### Header 3

- Bulleted
- List

1. Numbered
2. List

**Bold** and _Italic_ and `Code` text

[Link](url) and ![Image](src)

For more details see GitHub Flavored Markdown.

Jekyll Themes

Your Pages site will use the layout and styles from the Jekyll theme you have selected in your repository settings. The name of this theme is saved in the Jekyll _config.yml configuration file.

Support or Contact

Having trouble with Pages? Check…

View on GitHub

You'll need data from these specific files:

• IsValidForLanguageFallback.cs
• Pipelines.config

In addition to the item settings, you’ll need to add some settings to your site definition entries. This includes patching the shell site definition, and adding the settings to other site definitions:

enableItemLanguageFallback="true" enableFieldLanguageFallback="true"

Note that if you don’t add these settings to the shell site definition, you won’t see the proper result in the editors.

Then there’s enforcing the version presence. This is applicable if fallback is not turned on, but even if you have it turned on, it’s a good backup for cases where you might disable fallback on particular items. By default, if neither fallback nor enforcing version presence is on, when you get an item via the Sitecore API (or Glass Mapper, my preference) you’ll get that item data back, although the version count will be zero. If you turn on enforcing the version presence, you’ll get back a null result, which is preferable so that in a scenario where you’re looping through a set of items, one that doesn’t belong due to a missing version isn’t inadvertently present. (This is the scenario I ran into earlier, looping through items for a navigation tree.)

Turning on version presence enforcement is just as easy as item fallback; it’s the enforce version presence checkbox right under the enable item fallback checkbox in the base template’s standard values. In addition, you’ll need to add the following setting to your site definitions, but not the shell site definition (if you set it in shell you’ll only see the languages you have versions for in the item language select, not the available languages to help create a new version):

enforceVersionPresence="true"

Even if you aren’t planning to do a multilingual site, I’m a fan of activating all of these options at the start, and/or include it in a base Helix foundation layer project. I don’t believe there’s any harmful ramifications, and it keeps you fully ready if a client decides they want multilingual content; all you have to do is create the language option and set the fallback language, and you’re good to go!