Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

If a Content Type was deployed using a feature and someone makes manually changes it through the UI (e.g. adding a column), are there any implications?

  • Does the content type become unghosted?
  • Are you still able to upgrade the content type via a feature?
  • Is there any way to tell that a content type has been manually edited?
  • Is there any way to revert it back to its unmodifed state?
share|improve this question
add comment

2 Answers 2

up vote 3 down vote accepted

Content types Will be unghosted if you have defined them declaratively and then change them from UI!

There are no supported way of detecting if a content type is unghosted, you only can see it indirectly by your changes not being provisioned.

There is unsupported way of doing this, but that includes doing selects directly on your content database, but you should only do this on copies of databases, and not running farms, as this could render your farm in an unsupported state!

My friend Søren Nielsen has created an "Content Type Hierarchy" app here.

The checks that the internal methods do to determine a Content Types state boils down to this:

Is it a feature based content type, by checking “FeatureID != null”, if not mark it as “DB only”. Note that this is actually a private field, so I have to go the long way around and fetch it through reflection.

If it is feature based on the version > 0 then it has been unghosted. The version number seem to work well for this. It will always be 0 for ghosted content types and be incremented by one every time somebody modifies (and thereby unghost it). According to the xml schema you can specify this field in your content type definition, but it will (fortunately) not make it to the database so the detection seems sound. If you make new versions of the xml file, the server won’t really notice

Also be sure to read the other two articles on Content Types by Søren here.

While most of the story are the same in SP2010 we do have a couple of new features to help us:

We have some help though, through the OVERWRITE="TRUE" attribute in ContentType element. This will enforce an owerwrite of the site content type.

Feature upgrade also has options to add fields to an existing content type.

In general it is a recommended approach to create your "root level" or base content types as sealed, which basically sets this content type as read only. Then you create your child content types which can be "depricated" when we need to add or delete fields: hide the old feature and create a new content type on the same level in the hierarchy to replace it. By hiding it you make sure you dont loose data (content created by that content type is still there, you just cant add new content with that content type).

Read my related post on Stack Overflow here.

share|improve this answer
    
Anders, thank you for your very thorough and informative answer! –  Mark Bell Jun 26 '11 at 18:17
add comment
  • Does the content type become unghosted? Content Types are not ghosted, they just are "copied" to each list that uses it, sharepoint adds a guid to it's id in the list it is referenced in (basically making it a "child" content type. P.S. This is why it is "illegal" to update ctype CAML defintions directly)
  • Are you still able to upgrade the content type via a feature? I believe so, as long as the fields being added are not already present in the content type, Add or delete fields using a FeatureUpgradeAction
  • Is there any way to tell that a content type has been manually edited? No
  • Is there any way to revert it back to its unmodifed state? Yes, by hand, or by writing code that checks the original CAML schema and reverts to this, might be difficult if fields were added later through feature upgrades (which ARE fields you defined to be part of that ctype, but are not in the ctype's CAML
share|improve this answer
    
Content types can and will get unghosted, unfortunately. –  Anders Rask Jun 25 '11 at 12:40
    
Wow, I didn't even know that... after 4 years of SP development. I'm off to go live in shame somewhere remote.. :-P –  Colin Jun 27 '11 at 1:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.