Content Type Hub : Inconvenient updates

Recently I had to develop some kind of tool for a customer that would manage their content types from the content type hub. This tool included content migration as well. Think of renaming a content type or change the parent of a content type. During development I noticed that updating a content type and republish it from the content type hub, it did not update the content type all the way to sub-sites and lists. In spite of what the option says in the Managed Metadata Service Connection properties dialog:


The Test

Let’s take a test drive. In my example I have the following content type set to a document library and I will rename the content type and let’s see what the results are.



The My Content Type in the library is inherited from the site content type My Content Type. The latter one has been published from the content type hub. And by design, all published content types are readonly.


I renamed the content type My Content Type to My Renamed Content Type in the hub, republished it, started all necessary timer jobs and went back to my document library.


So, the site content type is updated, but not the library one.

For us developers, this seems like a SPContentType.Update() and not a SPContentType.Update(true).

The quest

But let’s take a deep dive into the code. I use ILSpy, but Reflector will do too. The update is performed by the Content Type Subscriber timer job. After some searching and digging it all starts with the assembly Microsoft.SharePoint.Taxonomy and the namespace Microsoft.SharePoint.Taxonomy.ContentTypeSync.Internal. Starting from SubscriberTimerJobDefinition jumping to SubscriberImport and you will see the SynchronizeSite method. Some interesting lines of code are:



In both methods you will see at some point the following lines of code:

sPContentType.ReadOnly = contentTypeInfo.IsReadOnly;

No Update(true) at all.

This leaves us writing our own update mechanism to sub-sites and lists. But that’s for another blog post.