SharePoint Migration of Publishing Content Types
When you migrate your Publishing Content Types from SharePoint 2007 to 2010 you have to do some changes to you xml definition. There are two new attributes to consider when creating or migrating Content Types:
Now take a look what msdn says:
The result is:
I don't really understand for what the attribute really stands for. I mean we have a complex mechanism of guids to create inheritance for content types and you have to say extra that you want "inherit" fields. Perhaps someone can help me here. I'll update the post when I find more info.
I examinde the contenttype table in the database and found out that when you create a content type with inherit=true, your content type gets unghosted. That means SharePoint write the content type directly into the database. So the information for the definition is picked from the database table and not from the xml definition. I don't no really know if this is good or bad, but when a content type is created by the SharePoint gui or by code, it is also written into the database. The only way to get ghosted content types are by feature installation.
When you omit the inherit attribute your content type is ghosted. The definition for the content type is picked from the xml file. Furthermore when you have a content type and the parent content type is a built-in content type (like publishing contenttype) your content type inherits all fields from the publishing contenttype but not the one you added. He? yeah that is exactly what the definition of inherits says.
When you migrate your Publishing Content Types from SharePoint 2007 to 2010 you have to do some changes to you xml definition. There are two new attributes to consider when creating or migrating Content Types:
Stefan Stanev has a great post about the new overwrite attribute in his blog.
The overwrite attribute solves some problems with content types which gets updated or modified. Because there are different types of content types, like site content types, list content types, ghosted and unghosted content types, modifiying content types is complicated. Therefore plan content types carefully so that you never have to do that.
Useful links
- Inherits
- Overwrite
The Inherits attribute
When you p.e. migrate a custom "publishing content type" that derives from the default page content type you must use the inherits attribute to display your custom fields.Now take a look what msdn says:
| Inherits | Optional Boolean. The value of this attribute determines whether the content type inherits fields from its parent content type when it is created. If Inherits is TRUE, the child content type inherits all fields that are in the parent, including fields that users have added. If Inherits is FALSE or absent and the parent content type is a built-in type, the child content type inherits only the fields that were in the parent content type when SharePoint Foundation was installed. The child content type does not have any fields that users have added to the parent content type. If Inherits is FALSE or absent and the parent content type was provisioned by a sandboxed solution, the child does not inherit any fields from the parent. |
|---|
The result is:
<ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390027E3522FA4F2451e8AF57D3CC9D40BF1"
Name="Project.Contentpage"
Group="Project Publishing Contenttypes"
Description="Contentpage"
Inherits="TRUE"
Version="0">
<FieldRefs>
<FieldRef ID="{7B367A27-2052-4b43-A47F-D057FF367A65}" Name="PageTitle" />
<FieldRef ID="{7B72B83A-B2EA-479D-A927-50A62DCD1B7D}" Name="HtmlField1" />
<FieldRef ID="{2677CEB5-4A8D-4717-B904-BA8962A579EF}" Name="HtmlField2" />
</FieldRefs>
</ContentType>
I don't really understand for what the attribute really stands for. I mean we have a complex mechanism of guids to create inheritance for content types and you have to say extra that you want "inherit" fields. Perhaps someone can help me here. I'll update the post when I find more info.
I examinde the contenttype table in the database and found out that when you create a content type with inherit=true, your content type gets unghosted. That means SharePoint write the content type directly into the database. So the information for the definition is picked from the database table and not from the xml definition. I don't no really know if this is good or bad, but when a content type is created by the SharePoint gui or by code, it is also written into the database. The only way to get ghosted content types are by feature installation.
When you omit the inherit attribute your content type is ghosted. The definition for the content type is picked from the xml file. Furthermore when you have a content type and the parent content type is a built-in content type (like publishing contenttype) your content type inherits all fields from the publishing contenttype but not the one you added. He? yeah that is exactly what the definition of inherits says.
When you migrate your Publishing Content Types from SharePoint 2007 to 2010 you have to do some changes to you xml definition. There are two new attributes to consider when creating or migrating Content Types:
The Overwrite attribute
Stefan Stanev has a great post about the new overwrite attribute in his blog.
The overwrite attribute solves some problems with content types which gets updated or modified. Because there are different types of content types, like site content types, list content types, ghosted and unghosted content types, modifiying content types is complicated. Therefore plan content types carefully so that you never have to do that.
Useful links
Comments