Sharing The Point

One of the great new features in SharePoint 2010 is the Content Type Syndication Hub, where we can finally achieve global content types. This ability is achieved by creating a site collection that we designate as the hub that pushes content types to web applications that subscribe to it.

Along with the content types and their related site columns, event receivers also come over during this synchronization process. Attaching event receivers directly to a content type is a good way to ensure your code runs wherever the content type is used.

The Issue

I have updated this post to provide detailed instructions on how to reproduce an issue where event receivers in the subscribing site’s content types appear to be removed when a parent content type that they are based off of, which is in the syndication hub, gets updated with additional event receivers.

Here are the steps to reproduce the issue:

1. Create a content type in the syndication hub, with one or more event receivers attached, and publish it
2. Create a child content type in a subscribing site based on the content type created in the hub, and add one or more event receivers directly to it (at this point it should have the event receivers from the global content type as well as the new ones added in this step)
3. Update the parent content type in the hub by adding one or more additional event receivers
4. Republish the content type in the hub
5. Once the sync takes place, the child content type no longer has the event receivers that were attached to it, and instead only reflects the event receivers in its parent (I have also found through other configurations where the parent event receivers never make it to the child content type)

The Fix

The one quick fix to this solution is to reattach any event receivers on your child content types that were removed. However, I am still researching this issue for more information. I will update this post once I have more details.

Cheers,
Matt

A duplicate content type “Enter Name” was found

If you’ve gotten this error and come to this site looking for answers, chances are it isn’t simply because the name you’re trying to give a new content type is already in use. On the contrary, you are probably sitting there saying that you know without a doubt the name you are entering is not in use, and you have probably even pounded a random value out on your keyboard just to prove the point.

Maybe you’ve come across forum posts like the following that suggest you make an update directly to the content database (MSDN Forum Post). I never go this route, because it is going to take you out of support with Microsoft, since working with the database is specifically prohibited.

I have, however, created a way to overcome this error utilizing perfectly legal methods.

What Does This Error Mean?

There are 2 ways to create an ID for a content type (MSDN Site). One involves assigning a child id based off a numerical sequence, and the other involves utilizing a unique guid. If you are developing your own content types, I highly recommend always creating your id’s with the unique method because you don’t risk conflicting with another developer or a 3rd party solution, but if you are creating content types through the UI, you have no choice – the UI method always creates children id’s based off of a numerical sequence (until it runs out of numerical values).

Another new feature in SharePoint 2010 also seems to add to this problem, as when utilizing a Content Type Hub, you essentially end up with 2 different sources (the hub and the site) trying to issue children content types and keep track of what the next numerical id should be. The content database has a field on the dbo.ContentTypes table called “NextChildByte” and that is what lets SharePoint know what that next numerical value should be. This is the heart of our problem. Sometimes SharePoint gets out of sync with itself, and “NextChildByte” indicates a value that already is in use. SharePoint is not intelligent enough to continue looking sequentially until it finds the next available byte sequence. Instead, it throws the error you see at the top of the page. That is why the posts online about updating this value in the database work – because the heart of the problem is this value, which is incorrectly telling SharePoint what the next numerical value for a child of this content type should be.

The Solution

I looked at this solution from a few perspectives, but ultimately knew I needed to get this “NextChildByte” value to change without issuing a command on the database. I discovered through testing that every time a content type is created programmatically (where you set the ID – either in the numerical format OR the unique guid format) this value gets incremented by 1. This is an increment of 1 each time – it doesn’t recalculate this value based on the content types already in the site. Essentially what we need to do is create enough “dummy” content types to increment this value up to a point where those numerical values have not yet been used in other content types.

I’ve written a PowerShell function that takes in an SPWeb and SPContentType that you are having trouble creating child content types of through the UI, and it simply adds 10 “dummy” child content types with random id’s and then removes them (thereby also freeing the random id’s it added). This ends up incrementing “NextChildByte” in the database by 10 and fixing your issue. If incrementing by 10 isn’t enough for you, or you run into the problem again down the road, you can update the script to suit your needs and re-run it. You may be wondering what happens after you reach the end of the numerical range expressed by a hexadecimal value (FF). At the point you run off the track (which would seem unlikely) SharePoint is intelligent enough to just create the children with Unique ID’s after that point. “NextChildByte” in the database then sits at 0, even as you add more content types.

function FixContentTypeForChildCreation
{
    param(
    [Microsoft.SharePoint.SPWeb]$web,
    [Microsoft.SharePoint.SPContentType]$ct
    )
 
    #Grab the ID of the CT you need to fix for child creation
    $ctID = $ct.ID.ToString();
 
    for($i=0;$i -lt 10; $i++)
    {
        #Create a new child content type with a unique guid and then delete it
        $newCTID = new-object Microsoft.SharePoint.SPContentTypeId($ctID + "00" + [Guid]::NewGuid().ToString("n"));
        $newCT = new-object Microsoft.SharePoint.SPContentType($newCTID, $web.ContentTypes, "Temp Content Type - Auto Deleted");
        $addedCT = $web.ContentTypes.Add($newCT);
        $newCT.Delete();    
    }
 
    Write-Host "Content Type Fix for Child Creation is Complete"
}

Example Usage

$web = get-spweb "http://yoursite"
$ct = $web.AvailableContentTypes["YourContentType"]
FixContentTypeForChildCreation $web $ct

I hope that this solution is able to help you through what can certainly be a frustrating time for users who are unable to create content types in the UI.

Cheers,
Matt