Yep. There's definitely a bunch of things to check before pushing down CT changes.
It also gets very complicated when you're dealing with changes to CTs on subsites that have deliberately broken inheritance or have additional content types that might have inherited from the ones you're updating. Versioning also offers its own set of problems as I discovered the hard way. I've added the following checks: - Check-in all files and approve/publish where required. - Empty recycle bins. - Tackle one site collection at a time and review it in advance. - Check for broken inheritance and stop. - Unlock CTs and the re-lock after push down. I may be over-cautious, or perhaps not cautious enough. Would be interested to hear if anyone has anything else to add. We also use SPSoucre to generate the XML but I'm starting to think that although this saves time in the first instance, it has its limitations. The real reason for using SPSource was so that we could suck down any changes made via the UI. I'm now going down the road of locking all CTs and changing permission levels to prevent changes via the UI. I then plan to rebuild all CT and site column definitions using the API to provide more flexibility. Regards, Paul Online Developer, ICT CEO Sydney From: ozmoss@ozmoss.com [mailto:ozm...@ozmoss.com] On Behalf Of Edge Sent: Friday, 24 July 2009 2:35 AM To: ozmoss@ozmoss.com Subject: Re: Upgrading solution for CT that's a good article. I think I missed that during my swine-flu :) As a matter of fact I am about to perform a content type rollout in our SP farm, which have hundreds of sites.( not to mention the lists in them and mysites ). But I believe he missed some *very important* points when doing that sort of CT manipulation. In my tests you can get pretty scary results if things like: you try to change a content type that is associated with a list with checked out files, or a content type columns is being referenced in a page layuot and you change that column etc. so YES, some checks must be done before for real life setups. if you perform that sort of modification without the checks, you can kiss goodbye these files:) you can see but never will access them again ( which can upset people and yeah!!!... we are not in the bussiness of upsetting people unless you are a QLD Maroon talking to a NSW Blue:) ) anyway... he is right about using feature receiver (SPbuilder rocks). but we are actually using SPSource (that guy Jeremy Thake rocks) to generate the template then use the feature receiver to propagate the changes. As of now we are running in our test-environment but so soon we go for the real deal :) ( BANG! ) Cheers, -Edge On Wed, Jul 22, 2009 at 9:36 PM, Clayton James <clayt...@flarepoint.com.au<mailto:clayt...@flarepoint.com.au>> wrote: This has just been released this month on msdn. Great article on developing, deploying and updating Content Types. Best Practices: Developing Content Types in SharePoint Server 2007 and Windows SharePoint Services 3.0 http://msdn.microsoft.com/en-us/library/ee330223.aspx Clayton James FlarePoint Pty Ltd |t +61 7 3821 7178 |f + 61 7 3821 7175 |m 0402 463 276 | w http://www.flarepoint.com.au<http://www.flarepoint.com.au/> ________________________________ Support procedure: https://www.codify.com/lists/support List address: ozmoss@ozmoss.com Subscribe: ozmoss-subscr...@ozmoss.com Unsubscribe: ozmoss-unsubscr...@ozmoss.com List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: http://www.codify.com/lists/support List address: ozmoss@ozmoss.com Subscribe: ozmoss-subscr...@ozmoss.com Unsubscribe: ozmoss-unsubscr...@ozmoss.com List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists
