Updating Child Content Types
Applies to: SharePoint Foundation 2010
Available in SharePoint Online
Each content type contains a reference to the site content type on which it was based. This enables Microsoft SharePoint Foundation 2010 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 push down those changes to all its child content types, either through the user interface or through the object model. When the push-down operation copies the changes that you make 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 is 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 that you can push down is 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 website, 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 SharePoint Foundation 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);
}
Using oWebsite As SPWeb = New SPSite("http://MyServer/sites/MySiteCollection/MyWebSite").OpenWeb()
Dim oList As SPList = oWebsite.GetList("MyWebSite/Lists/MyList")
Dim collFields As SPFieldCollection = oWebsite.Fields
Dim strNewColumn As String = collFields.Add("MyNewColumn", SPFieldType.Text, False)
Dim oFieldLink As New SPFieldLink(fields(strNewColumn))
Dim oContentType As SPContentType = oList.ContentTypes("Specification")
oContentType.FieldLinks.Add(oFieldLink)
oContentType.Update(True)
End Using
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 SharePoint Foundation makes no effort to determine whether the XML document is currently being used or is 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 that are made to child content types if those changes fall within the granularity of the push-down operation. For example, suppose that 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 you push down the changes, SharePoint Foundation overwrites the changes that you (or more likely, someone else) originally made in the child content type.
Each push-down operation pushes down only the changes that are made to the parent content type at that time. If you do not push down the changes at the time that 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 that 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 was deleted from a child content type, those changes are ignored. SharePoint Foundation does not add the column back into the child content type.
If you try 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, SharePoint Foundation continues pushing down the changes to any remaining child content types. At the end of the push-down operation, SharePoint Foundation returns a list of errors that 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 that are contained in that child site fail.
For more information about read-only and sealed content types, see Content Type Change Control.