Updating Content Types
Applies to: SharePoint Foundation 2010
Available in SharePoint Online
Microsoft SharePoint Foundation lets you 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 that those changes are propagated to the child content types 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 that is in use.
Each content type contains a reference to the site content type on which it is based. This enables SharePoint Foundation to propagate, or push down, changes that are 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 child content types.
For example, suppose that 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 child content types of that content type. This includes other site content types that are based on the content type, and also list content types that are based on the site content type and its child content types.
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 that content type.
For example, suppose that you have a content type for product specifications named ProductSpec, which your company has used for several years. Now the requirements that 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 many items over the years. In such a case, you can create a new content type, ProductSpec2010, based on the existing ProductSpec content type. After you package the ProductSpec2010 content type as a Feature, you can write code to install and activate that content type for your site collection, and add the ProductSpec2010 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 select the ProductSpec2010 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 that are 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
SharePoint Foundation never writes changes that are made to a content type back to the content type definition file. Instead, it stores updates that are made to content types as entries in the SharePoint Foundation database.
All list content types are stored as entries in the SharePoint Foundation database because when you add a site content type to a list, SharePoint Foundation 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 Definitions.
Important
Do not, under any circumstances, update the content type definition file for a content type after you install and activate that content type. SharePoint Foundation does not track all the changes that are 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.