Fallback and Enforcing Version in Sitecore
Tags: sitecore
Published: 2019-08-16 20:02:22

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

{% stackexchange 18733 sitecore %}

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:

{% github kmac23va/ScHelix %}
You'll need data from these specific files:
* [IsValidForLanguageFallback.cs] (https://github.com/kmac23va/ScHelix/blob/master/src/Foundation/HelixCore/code/Pipelines/GetFieldValue/IsValidForLanguageFallback.cs)
* [Pipelines.config] (https://github.com/kmac23va/ScHelix/blob/master/src/Foundation/HelixCore/code/App_Config/Include/Foundation/HelixCore/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:

```C#
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):

```C#
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!