0

We are developing a sharepoint solution which wil be used/customised by each client. The clients might even cutomise the base contents types/lists (which we have provided) in different sites. The main challenge here is upgrading the content types if they have customised a list by adding columns to the list or creating a new content type based on our artefacts.

I was thinking of managing the meta data (site columns, content types, list templates and list instances) in an axternal storage (DB or a sharepoint site to have the versioning) rathaer than Xml blobs (source code in Visual Studio) and creating them using a custom tool which feeds our internal meta data definition DB instead of deploying then in a solution/feature. The tool, obviously, will include an upgrade tool which identfiies the delta changes and applies them.

I was wondering if you could share you thoughts. Is there any best practices which I can refer to?

Improve this question

1 Answer 1

Reset to default
1

Don't let them customize the base content types. Get them to modify content types that they inherit from either your base types or the Out-of-box types.

Your requirements seem very close to the content-type hub functionality that is in SharePoint 2010, using the managed metadata service application. Rather than try to develop a custom solution, I would see if this can do what you need. Briefly, what you do is set up a site collection to act as a container for the reference content types. Other site collections then subscribe to this and either use these content types or inherit from them to allow further customization. You can make changes to the hub content types and optionally push changes down to the subscribing sites.

More info: http://blogs.technet.com/b/speschka/archive/2009/10/30/publish-and-subscribe-to-content-types-in-sharepoint-2010.aspx

Improve this answer
5
  • Thanks for your reply, SPDoctor. Content hub cannot solve my problem unless we don't allow them to change the content types. That is not possible due to the nature of the business. The only logical solution is to have a separate VS project for each client to be able to manage their changes. Unfortunately, this solution is rejected by the product manager. The reason for that is that if we have 50 clients (as an example), it is impossible to manage the source code
    – gido
    Commented Jan 25, 2011 at 9:37
  • You clients can't change the content type in the subscribing site content gallery, but your clients can inherit from the hub content type and change the inherited content type.
    – SPDoctor
    Commented Jan 25, 2011 at 12:30
  • Thanks again. I might be doing wrong here. I created a content type in VS (CTYPE A), and then deployed the solution. Then after, I created another content type (CTYPE B) using SPD and used the "CTYPE A" as the base content type. I add a new filed to the CTYPE A in VS and update the solution, followed by executing a upgrading the feature. I can see CTYPE A has the new field, but CTYPE B has no clue about the new field in its parent. Does Sharepoint copy the fields to the derrived content type and forgets about the base? or Am I Doing something wrong here?
    – gido
    Commented Jan 25, 2011 at 17:41
  • You can push down content type changes, but it is tricky to get right. This is a whole topic in itself!
    – SPDoctor
    Commented Jan 25, 2011 at 18:06
  • I just did a spike on content type hub. It's working! Thanks
    – gido
    Commented Jan 26, 2011 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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