Updating Content Types
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Windows SharePoint Services gives you the ability to make changes to a content type, even after you deploy it to a site, add it to lists, and assign it to items. You can even ensure those changes are propagated to the children of a site content type.
Approaches to Updating Content Types
There are two standard approaches to updating content types. Before updating the content type, you should decide which is best for your situation:
Approach 1: Make the necessary changes to the content type, and then push down those changes to all child content types.
This approach works best if you must make targeted, discrete changes to a content type in use.
Each content type contains a reference to the site content type on which it is based. This enables Windows SharePoint Services to propagate, or push down, changes made to a parent content type to its child site and list content types. When you make changes to a site content type, you can choose to push down those changes to all of its children.
For example, suppose you need to add another column to a site content type. You can add the column to the site content type, and then use the push-down functionality to make sure that the column is added to all children of that content type. This includes other site content types based on the content type, as well as list content types based on the site content type and its children.
For more information about what to consider when pushing changes down to child content types, see Updating Child Content Types.
Approach 2: Create a new content type with the necessary changes, deploy it wherever the previous content type exists, and then add the previous content type to the _Hidden content type group.
This approach works best if you want to replace a content type that is currently in use with a revised content type, but still retain the current content type for items that are already assigned it.
For example, suppose you have a content type for product specifications named ProductSpec, which your company has used for several years. Now the requirements you track in product specifications have changed. You need to create a content type to embody these new requirements, but for history reasons, you must still retain the existing ProductSpec content type, which has been assigned to numerous items over the years. In such a case, you can create a new content type, ProductSpec2007, based on the existing ProductSpec content type. After you package the ProductSpec2007 content type as a Feature, you can write code to install and activate that content type for your site collection, and add the ProductSpec2007 content type to every site and list to which the ProductSpec content type is already added. Finally, you can write code to set the ProductSpeccontent type's Hidden property to true. Now, when users go to a site to create a product specification, they can choose the ProductSpec2007 content type; the ProductSpec content type is no longer listed. However, the ProductSpec content type remains on the sites and lists to which it was added, and items assigned that content type remain unchanged.
Hidden content types are not displayed on the New menu for list views. Therefore, users cannot create items of that content type from the list. For more information, see Content Type Access Control.
Storing Updates to Content Types
Windows SharePoint Services never writes changes made to a content type back to the content type definition file. Instead, Windows SharePoint Services stores updates made to content types as entries within the Windows SharePoint Services database.
All list content types are stored as entries within the Windows SharePoint Services database because when you add a site content type to a list, Windows SharePoint Services copies a site content type locally to the list as a list content type. For more information, see Site and List Content Types.
For more information about the content type definition file, see Content Type Definition Schema.
Important
Do not, under any circumstances, 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 all the changes made to the content type definition file. Therefore, you have no reliable method for pushing down all the changes made to site content types to the child content types.
Updating Sealed Content Types
Sealed content types cannot be updated through the user interface or object model. If you must make updates to a sealed content type, you must set the Sealed property of the content type to false, and then make your changes. Do not edit the content type definition file directly.
You must have site collection administrator rights to set the Sealed property of an SPContentType object. For more information, see Content Type Change Control.