With the introduction of the Content Type Hub in SharePoint 2010, there was lots of excitement about the ease of maintaining content types in SharePoint. The ability to manage fields and content types in one place was very appealing to organizations with the large intranet redesigns and deployments. Setup is very simple, create a hub, deploy field and content type elements and we are in business. The content type hub then pushes down information to it’s consumers, sites and lists are all in synch and everything is working as expected.
So, a change comes up, and the implementation sounds simple just deploy fields, deploy content types, deploy updated list schemas, publish content types, looking good… Until, the data in a pre-existing list is reviewed and the change to the content type is not reflected. Hmmm… the content type has been published, the content type jobs have run, the site has the newly updated content type, but the pre-existing list does not. That’s a big problem when you have many lists across an enterprise implementation that all need updates and now the data is out of synch between lists created post change and the lists that existed pre-change. After lots of research, it was determined that the binding of the content type to the list schema itself (custom lists were also implemented) was the culprit of the updating problems. Once that was identified, a new solution was formed so that lists would update as expected.
Ultimately, the approach to creating and updating content types, lists, and their association with each other were all modified. Since Content Types are the basis of the solution modifications, the deployment and modification of field elements has not changed, we will start there.
Changing the way content types are deployed…
The documented Microsoft approach to creating and deploying content types, regardless of whether The Hub is being utilized, is to create an elements file with a Content Type element and the appropriate Field References including removing any unnecessary inherited fields. The content types get their own GUID, internal name, and other attributes can be specified at this time. Instead of deploying content types with an elements file, the new approach is strictly PowerShell. A parent content type can still be specified within PowerShell to maintain the hierarchy. All modifications to content types should be handled via PowerShell just as the creation was to maintain consistency throughout environments. Publishing after creation via script is still necessary. If you are using The Hub, the PowerShell script should only be run on the URL where the content type hub is created, just as if you were activating a feature in the old approach.
In the next blog we will discuss list schemas and their association to custom content types.