Migrate from Hedgehog’s Field Fallback to Sitecore’s Language Fallback via Powershell

I’m working on a Sitecore upgrade for a client that is looking to go from v6.6 to v8.1. There is still some hesitation from our group to move to v8.2 until there’s at least one update to work out any kinks.  I’ll probably share some more of the overall upgrade process but I wanted to share at least one hurdle we encountered.

Sitecore didn’t offer their Language Fallback feature until v8.1.  I don’t know the complete history but it’s either a direct migration of or completely new implementation of the Field Fallback module that Hedgehog developed as far back as 2013 (according to the Marketplace stats).  If you’re not already aware, the premise is to create a mechanism that shares content between language versions.  In most multilingual implementations, there’s a “primary” language that usually gets more attention than the others.  For American-based sites, that is obviously English.  When authors and developers make the decision to offer more than one language, the main obstacle is translating every last drop of content to the “secondary” languages.  Through either of these features, you can specify a case-by-case basis (based on individual field/template) to allow the secondary language versions to use the primary language until an “override” is provided.  It’s like specifying the field as “shared” but with more flexibility.  And the fallback can have multiple levels which can be handy when there are variations or dialects of a particular language you want to support.

There are plenty of other resources to describe how to use that feature.  Our dilemma was to migrate from the module implementation to the new core implementation.  At its root, that really just meant a switch from one checkbox to another on the “Template field” items.  Like other many other one-time-only tasks, this seemed like a job for the Sitecore Powershell Extensions module.  If you’re not already using this module, drop everything and get up to speed.  There’s a certain amount of “blunt force” to it but, at the end of the day, it solves most problems that would take 10x longer to fix through more conventional means.

The script to make this migration actually ended up being pretty straight-forward:

Get-ChildItem -Recurse | 
Where-Object { $_.Template.Name -eq "Template field" } | 
Where-Object { $_.EnableLanguageFallback -eq "1" } | 
ForEach {
    $_.Editing.BeginEdit()
    $_["Enable Shared Language Fallback"] = "1"
    $_.Editing.EndEdit()
    
    Reset-ItemField -Item $_ -Name "EnableLanguageFallback"
}

I’ve read documentation that you don’t normally need the “BeginEdit” and “EndEdit” statements but I was getting errors if I left them out.  I’m also running the initial “Get-ChildItem” statement based on contextual path as opposed to something hard-coded.  This means you can elect to run this script on part or all of the items under “/sitecore/Templates”.  Finally, I am both filtering on and eventually removing/resetting the old “EnableLanguageFallback”.  So if you run this multiple times, subsequent runs will be shorter because the previous items would have already been “corrected”.  You could, if you wanted, “spot fix” one area, confirm it’s working and then correct the remainder of your templates.

It should be noted that you will need to publish your templates and enable the newer Sitecore feature in order to see this change working.  I got a little frustrated when I wasn’t seeing my updates reflected in the final product and realized I was missing those steps.

It’s always reassuring when a community-born feature such as this is eventually assimilated into the mainstream.  Unfortunately, this seems like that last bit of “missing documentation” needed to fully embrace and utilize those improvements.  Hopefully this saves you some time if you are in a similar situation.  If you have an alternative method, please feel free to share in the comments.

Leave a Reply