Sharepoint: What happens to lists based on content type when content type is updated?
I have kind of hypothetical question (at least for now :))
Let's say I create list based on some custom content-type. I add some 1000 items into that list (in production). Then customer comes and he say that he need to modify that custom content type.
What happens to list if I modify custom content type? Will it be updated automatically (I doubt) ? And what about already created list items?
Do any of you have some experience with this?
Answer
So a couple of issues regarding content types:
First of all, content types comes in two flavours: Site content types and list content types. Site content types are "templates" that reside in a gallery. When a site content type is used in a list, the content type is instantiated as a list content type on the given list.
Secondly, your content types could be created and modified in several ways, which would decide in what of three modes your data is present in the database.
If you have created the content type using the GUI, or through custom code using the API, both your site content types and your list content types are in the "database-only" state in the database. That means that it is looking in the database for the definitions of the content type.
If you have created the content type as a feature in CAML, your site content type is ghosted (or un-customized as we are supposed to call it in v3) in the database. That basicly means that the database looks in the feature XML in the 12-hive for the site columns that makes up the content type. So that should mean that you could update the feature, and you would have new site columns available in the update content type, right?
Unfortunately not: remember that we also had list content types? The bummer here is, that these list content types are instantiated using code, so they are in the "database-only" state. It means your changes would only be seen in your site content types, but not in existing lists using that content type!
There are several approaches to fixing this issue, the solution depends on what your needs are and what kind of changes you are doing (deleting fields, adding fields, changing fields).
For example, you would often want to keep your existing item meta data, even though the content type changes over time. If you push through the changes in the list content type through code, you would lose the data stored in the changed/deleted fields. A solution to this would be to add a completely new content type based on the old one but with the changed fields. You would add the new content type (through code or using feature XML) and use a feature receiver or similar to propegate the new content type to all lists that used the old content type, and subsequently mark the old content type as hidden. That would make it possible to keep old meta data but not to add new items using other than the new meta data.
The approach mentioned in the other answer to this question would be preferred if you have direct access to the production environment, and if your customers governance plan allows it. As with other artifacts in SharePoint however, it would be recommended to deploy content types in a structured manner. Adding new content types in an unstructured fashion would influence search relevance (managed properties) and could also affect the general taxonomy of the site (site columns not being reused, etc.), so even though it is possible to add these changes directly in a production site, I would not reccomend it!
That leads me to the final approach that is the one I would reccomend, at least for future content types: Create your content types programmatically from the beginning using a feature receiver! That way you always know the true state of your content types (database-only) and you can have a structured approach for governing changes in the future! You can find several ways to do this by googling 'create "content types" programmatically SharePoint'
For completeness: I mentioned three modes. The last mode your content type can be in is "UnGhosted". This means that your content type was created using feature XML, but that it has been disconnected from the original XML source in the 12 hive.
My friend Søren Nielsen has some good points on Content Types in Audit your Content Type Hierarchy. Some of the issues described above can be found briefly mentioned in an MSDN article Updating Content Types. Gary Lapointe also has an STSADM extension that addresses some of the problems with Content Types, see Propagate Content Type Changes.
Sorry for the rant, but the subject is complex and demands a thorough explanation to avoid any misconceptions.