How to refactor duplicated fields?

Question

On an existing multi-site instance, it's been noted that there are several templates that duplicate fields by name. For example, each site has a set of templates that are used as the base for each page type, and there are fields that repeat across each of these templates. For example, SEO Metadata fields like "Meta Description", "Meta Keywords", etc.

Site 1 Templates
  Base Page Template
     SEO
       Page Title
       Meta Descriptiopn
       etc
Site 2 Templates
  Base Page Template
     SEO
       Page Title
       Meta Descriptiopn
       etc

We'd like to refactor these into one template that other templates inherit from:

Global
  SEO
    SEO
      Page Title
      Meta Descriptiopn
      etc
Site 1 Templates
  Base Page Template (inherits from Global/SEO)
Site 2 Templates
  Base Page Template (inherits from Global/SEO)

The challenge is how to do this while maintaining existing values. In the above example, we could create the global template and move the template section from "Site 1" to it, then set the inheritance and not lose any values. For Site 2, we could set the inheritance, but it we delete the now duplicate files, we'll lose any existing data.

One thought was to try and update the fields in the database via a SQL script, but I'm always super-hesitant to doing any work in the Sitecore databases.

Answer 1

The best approach to this will require some data grooming. At its simplest, it can be done with nothing besides stock Sitecore and the Sitecore Powershell module. If you're not comfortable with Powershell, or you need to take a more iterative approach, you could also write code to handle your transformation. I like to park pages in /sitecore/admin for just such an occasion.

ORM Warning

If you are using an ORM solution such as Glass or Synthesis, you might want to avoid using it while you perform this merge, as duplicate names and duplicate inheritance may cause code generation issues.

Step 1: Create your new Interface analog

Create your new base template. For the time being, your base template should have a unique content section, so it's easy to find your new fields if you need to review them in the content editor.

Step 2: Establish Inheritance

Assign your new base templates to the target templates you want to merge. Don't delete the old fields; just add your new base template to the inheritance chain.

Step 3: The Heavy Lifting

You want to create a script that crawls the tree and does something like this:

1. Disable security so you can grab all Items and modify them.
2. Identify that an Item inherits from "New Base Template"
3. Identify that an Item inherits from "Old Field Template"
4. Assuming 1 & 2 are true, grab all versions of the Item via Item.Versions
5. For a given Version, copy the values from old-field to new-field.
6. Save the version.
7. Rinse, repeat.

At this point, all your items and their historic versions should have duplicate values in the old & new fields.

Step 4: Break the Chain

You can now break inheritance by removing the "Old Field Template" from the target Item Template. This will remove the old fields. If your target Item Template is the Old Template, go ahead & delete the fields. Warning, you may want to jot down the IDs of these old fields, so you can hunt them down in source code & configuration files if required

Step 5: Code Fixes

If your code is very plain, and you're referencing fields by field name ex: item.Fields["field name"] you may not have any work to do. If you're using an ORM, you need to rebuild the classes using T4 templates, TDS, Unicorn, or Custom Item Generator. Assuming your new field names are the same as your old field names, once the ORM code is generated, you should be good to go, otherwise, you're in standard refactor land.

If you aren't using an ORM and you've got some sort of static FieldIDs class (a-la-Stock Sitecore) you're going to need to re-tool this class to point to your new FieldIDs.

The Warnings Come After the Spells

Depending on the size of your codebase, this is probably a good days work to write and test.

Ideally you'd want a content moratorium in production so that you could roll out the change in one go. If you have to re-run the Sitecore Template changes in production, I would consider using a tool like Razl for larger databases, possibly TDS for smaller ones.

If you have a lot of little sites, each with different Data Template groups (and ideally different VSProjects), I might consider doing this one site at a time.

For installations in the 50K to 100K Item range, I wouldn't hesitate, it'll save you trouble in the long run. If you're pushing a million Items, and/or you can't get any content authoring downtime, I would avoid attempting something like this until you could get a major system rebuild scheduled, or I would focus on redoing one site at a time. Assuming each site has their own Template folder (and therefore namespace) you shouldn't have issues with both approaches existing in the same system.