Content Type Lifecycle management best practices

Question

I saw thisarticle in the link below and I wonder if you could help me with some questions I have

http://msdn.microsoft.com/en-us/library/ee330223(v=office.12).aspx

In our current project, which we didn’t not develop but we have to maintain, we are facing some issues, it looks like the first time the other firm developed the content types, they were done fine, using xml definitions, creating list templates and list instances was also done fine and in an organized way.

However at some point in time and after the content types and lists were already running on production, some changes had to be done (adding new fields to existing content types, changing translations of displayname or groupname, changing properties like required, showinnewform, showineditform, etc)

Across the internet I have found that many people have problems with unghosted content types, which means that the content type is detached from its XML definition, as far as I know this happens when somebody modified the child content type or list using the UI.

I am trying to collect a list of best practices for managing content types after they are deployed:

1.How to add a new field to an existing content type?

For this we have used UpgradeActions and AddFieldRef

2.How to remove an existing field from a content type?

For this, we haven’t needed it yet, but I have see that there also exist the RemoveFieldRef element which could be used inside UpgradeActions

3.How to reorder fields in a content type?

We do this by code in a custom upgrade action.

4.How to change a translation in an existing field?

We do this by code in a custom upgrade action.

5.How to change properties like ShowInDisplayForm, ShowInNewForm, Hidden, Required, etc.

We do this by code in a custom upgrade action.

I wonder if my list above specially points 3,4 and 5 can be called best practices, or if I am missing something or doing something wrong? Why? A few weeks ago we had a lot of problems, when doing changes via code and pushing down the changes was not working, the changes were not pushed(we were not seeing the changes in the lists). After reading for many hours, I saw that this might be possible due to that the list content type LINK is broken from its Parent content type definition.

I found that a way to restablish this link can be done using SQL but it’s not supported of course.

http://www.olavaukan.com/2010/10/content-types-can-be-unghosted-too/

http://soerennielsen.wordpress.com/2007/09/08/convert-%E2%80%9Dvirtual-content-types%E2%80%9D-to-physical/

Maybe somebody can guide me in the right direction?

Answer 1

With my experiance upgrade content type and field are very harad to do. The reason is that once your content type and fields are deployed to production SharePoint copies your custom content type definition as a local library/list content type, difinition. This is done to hold compatibility between new and old items using this content type.

Let's say you create your content type "bills" with ammount and date fields. After you deployed this content type to production and create a list/library which is using this content type, SharePoint is copying this content type as a local one usable only for this list (list content type). In this way all changes made to parent content type will not affect content type of the list beside changes are pushed down with a poweershell or code. The same way you can easily add new column to list content type without affecting parent one.

What I usally do is using PowerShell to edit content type and fields. This works exactly the same way but by code and you have whole control about what you do and how.

Here are some steps I do to patch production web site. IMPORTANT, be sure to test on dev and staging, plus QA if possible, before doing it on prod:

1) Create in the project class patch or somthing similar to fill this with patch functions like add field, add column, add event receiver etc. I'm trying to do it more generic possible to be able to reuse it again when needed.

2) Create patch.ps1 which is loading DLL with your patch class and calls your functions in a given order.

3) Do not forget to add XML defenitions for fields and or content types changes in case you do it for latter clean installations or, in my case, it was create new site using modified XML definitions.

If I can share something more I will be happy to help,

Andrew