Olav Aukan Getting information off the Internet is like taking a drink from a fire hydrant…

12Oct/10

Content types can be unghosted too!

Update: There is a simple solution to this problem after all. See How to ghost an unghosted content type for more details.

Just about all SharePoint projects require that you create some custom content types and/or add some custom site columns, and this is usually done through a feature that contains the CAML definition for those content types and site columns, as described in the MSDN article Content Type Deployment Using Features. It is also often the case that for some reason these CAML definitions will change during the project. Maybe a certain feature was not specified correctly, the requirements changed, or additional features are added that require new columns to an already existing content type. This is where the first problems start to arise...

If you read the MSDN article about deploying content types you will see the following warning:

"Under no circumstances should you update the content type definition file for a content type after you have installed and activated that content type. Windows SharePoint Services does not track changes made to the content type definition file. Therefore, you have no method for pushing down changes made to site content types to the child content types."

This warning is usually ignored while in development, as clean builds are done regularly where everything is deleted and the solution is deployed to a fresh site collection. The problem usually doesn't show up until after the solution has gone into production and a later update tries to make some changes to these content type definitons. These changes will be pushed to the site content types but the list content types are basically detached copies of the site content types and therefore will not be updated.

Luckily there is a hack solution to this problem, and it comes in the form of a custom STSADM command. This command will push changes to the site content type down to all list content type instances, thus solving the problem once and for all. Or perhaps not? I stumbled upon this command while trying to figure out how to do just such an update, and after trying it out with success in our test environment I decided to go ahead and use the same command in the production environment. Sadly it did not work, and I could not figure out why.

Then I read a post on our internal blog by Jan Inge Dalsbø with a title of something like "Mysteries of SharePoint content types" where he goes on to explain that site content types can actually be unghosted (detached from their CAML definition) if they are edited in the SharePoint UI. Any changes to the CAML definition done after this has happened will not be pushed to the site content type, and you are - pardon my french - properly fucked! The content type will have to be updated through the UI or object model from that point on.

To verify that the content type has in fact been unghosted you need to check the content database. To do this you will have to run a query against it (obviously) and this will actually leave you in an unsupported state! Yep, we all knew you weren't supposed to modify any of the SharePoint databases but as it turns out you're not even allowed to read from it.  That being said, here are two before and after screenshots of a content type being unghosted.

Notice that in the second screenshot the definition field has gone from being NULL to containing the content type CAML definiton. The content type has now been detached from its definition, updates will fail, hairs will be pulled, gods will be cursed etc. etc. I haven't dared to poke around in the production database to see if this is actually what happened in my case, but I'm pretty certain it's the same problem.

So where do you go from here? I honestly don't know... Søren Nielsen, the original author of the code used in the STSADM command mentioned earlier, has a  hack solution to this problem as well, but it involves modifying the content database. In his blog post Convert “virtual” content types to “physical” he explains the steps needed to reattach the content type to its CAML definition. Keep in mind that this will leave you in an unsupported state!

This was all new to me, and I was a bit shocked to find out that this is how it works. Basically Microsoft has given us a big fat rope to hang ourselves with here. From now on I will definitely tell all site collection administrators to never touch the content types!

12Oct/10

SharePoint does not always play nice with comments

Some days ago I was tasked with removing the "Add to my colleagues" button from the My Profile page in SharePoint. This is a one-off page located at the root of the My Site site collection named Person.aspx. So I fired up SharePoint Designer (yes I know, SPD is a great evil, but for these kinds of changes it's really the easiest way) and looked at the file. It turns out that the "Add to my colleagues" button is a control in the PlaceHolderMiniConsole placeholder, so I commented it out and saved the page.

<asp:Content ContentPlaceHolderId="PlaceHolderMiniConsole" runat="server">
	<SPSWC:MiniConsole runat="server" id="miniConsole">
	<SPSWC:SPSRepeatedControls id="RptControls" runat="server" HeaderHtml="" BeforeControlHtml="<td class='ms-toolbar' nowrap='true' ID='_spFocusHere'>" AfterControlHtml="</td>" SeparatorHtml="<td class=ms-separator>|</td>">
		<Template_Controls>
			<SPSWC:ReturnToSiteButton runat="server" id="TBBReturnToSite" class="ms-toolbar" ShowImageAndText="false"/>
			<!--<SPSWC:AddToColleaguesButton runat="server" visible="false" id="TBBAddtoColleagues" class="ms-toolbar" ShowImageAndText="false"/>-->
			<SPSWC:AsSeenBy runat="server" id="ddlAsSeenBy" SelectionMode="Single" autopostback=true/>
		</Template_Controls>
	</SPSWC:SPSRepeatedControls>
  </SPSWC:MiniConsole>
</asp:Content>

Much to my surprise nothing happened and the control was still rendered. I tried to revert Person.aspx to it's definition and do the changes again, I tried disabling the cache, I tried iisreset, but nothing worked. In the end I deleted the control instead of commenting it out. That worked...

A colleague of mine had a different problem. His content type was suddenly missing a site column. He was being a good developer and deploying it with XML, just like Microsoft tell you to do. I'm sure we all know about the MANY issues with this approach. So many in fact that I'm almost considering using the object model to add my site columns and content types on my next project, but that's a different subject altogether... We looked at the XML and couldn't see anything wrong with it:

<ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D000cba91cafa2b473e85a2e018ed328699"
               Name="InsideBaseArticle"
               Group="Inside Portal"
               Description="Base Content Type for publishing content in the Inside Portal"
               Inherits="TRUE"
               Version="0">
    <FieldRefs>
      <FieldRef ID="{6440A642-CE85-4AF3-BFF7-1900D5095D87}" />   <!-- Tax Note Field -->
      <FieldRef ID="{D5F62894-71DA-49E1-88CE-A8FBBCBFCE2F}" Name="Via" />  <!-- Tax Field -->
      <FieldRef ID="{9DFA6A86-70E7-4470-B3FD-4D68D1FDD1A5}" Name="Summary"  Required="FALSE" />
      <FieldRef ID="{5a14d1ab-1513-48c7-97b3-657a5ba6c742}" Name="AverageRating" />
      <FieldRef ID="{b1996002-9167-45e5-a4df-b2c41c6723c7}" Name="RatingCount" />
    </FieldRefs>
</ContentType>

Turns out it was the comments in the FieldRefs section. Removing them and deploying again resolved the issue.

Moral of the story? SharePoint doesn't always play nice with comments...

Tagged as: 2 Comments