Updating Child 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.
Each content type contains a reference to the site content type on which it was based. This enables Windows SharePoint Services 3.0 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 push down those changes to all of its children, either through the user interface or through the object model. When the push-down operation copies the changes that you've made to the site or list content types that are based on that site content type, it does not overwrite the entire content type. The scope of the content that gets overwritten differs depending on whether you execute your changes and push-down operation through the user interface or through the object model.
Updating Child Content Types through the User Interface
When you edit a site content type through the user interface and make a change on a content type settings page, all the settings contained on that page are overwritten during the push-down operation. Therefore, the granularity of the changes you can push down are defined by which settings are grouped on each page. Each time you make any change on a content type settings page, all settings on that page are overwritten during the push-down operation.
Following is a summary of the settings that each content type settings page contains:
Advanced Settings This page contains the following settings:
Document template URL
The actual document template file, if you selected an existing template in the Web site, or uploaded your template file
Read-only attribute
New column settings This page manages adding a new column to the site content type.
Column settings This page contains the following settings:
Required
Hidden
Removing a column from the site content type
Updating Child Content Types through the Object Model
Using the object model provides greater granularity in push-down operations. As you make changes to a site content type through the object model, your code is actually making those changes to the in-memory representation of the site content type. Only when you call the Update method does Windows SharePoint Services commit those changes back to the site database.
Example: Adding a column to a content type
The following code example creates a site column, adds the column to the collection of fields that belong to the custom content type (in this example, "Specification") and then pushes those changes down to all the content types that are based on Specification.
Note
You cannot add columns to an existing site content type declaratively, in other words, by updating the Feature XML files.
using (SPWeb oWebsite = new SPSite("http://MyServer/sites/MySiteCollection/MyWebSite").OpenWeb())
{
SPList oList = oWebsite.GetList("MyWebSite/Lists/MyList");
SPFieldCollection collFields = oWebsite.Fields;
string strNewColumn = collFields.Add("MyNewColumn", SPFieldType.Text, false);
SPFieldLink oFieldLink = new SPFieldLink(fields[strNewColumn]);
SPContentType oContentType = oList.ContentTypes["Specification"];
oContentType.FieldLinks.Add(oFieldLink);
oContentType.Update(true);
}
Updating Child Custom Information in Content Types
You can also push down custom settings at the granularity of an XML document by using the object model. Each content type has an XML document collection that third-party solutions can use to store custom settings information. You can overwrite specific XML documents using push-down operations. Be aware that Windows SharePoint Services makes no effort to determine whether the XML document is currently being used or needed for any process before overwriting it. You can also delete XML documents entirely as part of the push-down operation.
For more information about storing XML documents with custom information inside content types, see Custom Information in Content Types.
Considerations When Updating Child Content Types
Be aware that push-down operations overwrite changes made to child content types if those changes fall within the granularity of the push-down operation. For example, suppose you make changes to a column in a child content type. If you then make other changes to that column in the parent template or even delete that column, and push down the changes, Windows SharePoint Services overwrites the changes you (or more likely, someone else) originally made in the child content type.
Each push-down operation pushes down only the changes made to the parent content type at that time. If you do not push down the changes at the time you make them, you cannot easily push down those changes later. In most cases, you would be forced to undo your previous changes, make those changes again, and then push down that set of changes. For example, suppose you delete a column from a parent content type but do not push down that change at the time. Any subsequent push-down operation would not include deleting that column from the child content types. To remove the column from the child content types later, you would need to add the column back to the parent content type, delete it again, and then perform a push-down operation.
If you push down changes that no longer apply to a child content type, those changes are ignored. For example, if you push down column settings changes for a column that has been deleted from a child content type, those changes are ignored. Windows SharePoint Services does not add the column back into the child content type.
If you attempt to perform a push-down operation on a child content type that is marked as read-only, the push-down operation fails unless you set the parent content type to be read/write as part of the push-down operation.
Pushing down changes is not an all-or-nothing operation; if the push down of changes fails on a given child content type, Windows SharePoint Services continues pushing down the changes to any remaining child content types. At the end of the push-down operation, Windows SharePoint Services returns a list of errors it encountered.
If a child content type is defined as sealed, the push-down operation fails on that content type.
Note
To create or manage a site content type on a site, you must have Web Designer access rights to that site. If you do not have the appropriate access rights to a child site, push-down operations to content types contained in that child site will fail.
For more information about read-only and sealed content types, see Content Type Change Control.