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

We're deploying our custom content types to the content type hub with a feature. The content type with Inherits="TRUE" gets published to the subscriber sites without a problem. However for all content types without (equals FALSE), we're getting following error message in the logs, complaining that we should enable our content types feature (special features like Document Sets are enabled on both hub and subscriber):

Content type 'yourCT' cannot be published to this site because feature 'yourCTFeature' is not enabled.

If we have to deploy the content types feature to all subscriber sites, there's no real use in using a content type hub... And placing Inherits="TRUE" on all content types, just for the sake of being able to push them through isn't a solution either. E.g. Document Sets give issues with the event receivers to update shared properties, if you create them this way.

Is there a way to make the publishing working without activating our custom feature or forcing the Inherits attribute?

Related: How to efficiently deploy content types to a Content Type Hub

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

This has to do with how SharePoint "builds" content types I think. It needs to know where to find the parent, or more specifically, the parent's original schema (XML). If Inherits is set to true, it will include the parent's fields directly in its own schema, when this is not the case. it will always require a schema to be based on, which can be found in the feature.

We have found some really weird behavior regarding the Inherits attribute too. For instance, when Inherit is set to true, any XmlDocuments (i.e. declaritive Item event receivers are not just ignored :-S).

MSDN describes the Inherits attribute as follows:

Inherits – Optional Boolean. The value of this attribute determines whether the content type inherits fields from its parent content type when it is created.

If Inherits is TRUE, the child content type inherits all fields that are in the parent, including fields that users have added.

If Inherits is FALSE or absent and the parent content type is a built-in type, the child content type inherits only the fields that were in the parent content type when SharePoint Foundation was installed. The child content type does not have any fields that users have added to the parent content type.

If Inherits is FALSE or absent and the parent content type was provisioned by a sandboxed solution, the child does not inherit any fields from the parent.

more on this topic:

http://blog.mastykarz.nl/content-type-doesnt-inherit-columns-parent-content-type-publishing-tip-1/

http://msmvps.com/blogs/windsor/archive/2011/05/02/custom-content-types-and-inherits-in-sharepoint-2010.aspx

share|improve this answer
    
Some call that weird behavior a "SharePoint feature", aka bug. Thanks for the confirmation. –  Bart Oct 20 '11 at 8:22
add comment

I know this really should not be an answer, and should be a comment on the accepted answer, but apparently I cannot add a comment.

In any case, I have a potential solution to the problem of the Inherits attribute, and needing to set it to True so you can publish content types correctly vs. needing to set it to False so that you can preserve your declarative XMLDocuments.

See my blog post here.

[Edit over a year later]

In the interest of keeping the content here useful in the event of links going bad, the general process/idea that I go over in detail in my blog post is as follows:

If you deploy content types with Inherits="TRUE", SharePoint will completely ignore any custom XMLDocuments in your content type definition. However, you can force your XMLDocuments back into the content types by using a feature receiver.

By the time the FeatureActivated event fires, the damage is already done: SharePoint has processed your Elements.xml files and set up content type definitions on the site that don't have your XMLDocuments. But, through properties.Definition.GetElementDefinitions(), you can get your elements including your XMLDocuments from the feature definition.

Then, you can reach into the site content types, get the content type definitions that SharePoint has already installed, and add your XMLDocuments back into the content type definitions.

At that point, you will have content type definitions installed on the site with both your custom XMLDocuments and Inherits="TRUE".

share|improve this answer
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.