Ghosts can cause a massive headache when upgrading from SharePoint 2007 to SharePoint 2010, especially if you decide that the upgrade is a good time to re-organize your feature folder hierarchy.
On a recent upgrade, we ran into multiple issues related to ghosted locations for both page layouts and content types.
When upgrading the solutions to 2010, the code was migrated into clean Visual Studio projects. What this meant was that all the feature folders were now “cleaned up” by VS, instead of Features/featurename we now have Features/projectname_featurename. This blew up all of our masterpages and page layouts. We would get file exceptions from them regardless if they were ghosted or not. The only solution is either to rename the feature folders and get the file references which are read-only in the database back to a happy state, or rip out all the old masterpage gallery items and recreate them with the new vti_setuppaths. Given the size of our site, setting all the pages to a dummy layout while we did this wasn’t feasible so we had to rename all the folder to get our ghosts back.
So in the end masterpage gallery = keep your ghosts in the same place, or risk breaking your content.
Rename feature folders in VStudio 2010:
These were another big headache. To make the content type definitions more manageable, each content type was broken out into its own xml module, and all the fields that they reference were put into one module as well. The same feature name is now in place, but the xml definition files went from one xml to about 15.
When the database was upgraded and new solutions were deployed we kept getting missing columns and content types. The features wouldn’t even activate without a -Force flag.
We ran into the same exact situation as mentioned in the below link where the Definitions in the database were null, and upon upgrading, SharePoint didn’t know where to locate the actual xml that defined these fields and content types.
There have been other, better posts about ContentTypes made by others but long and short of it is, modifying ContentTypes and fields that are feature deployed at the xml definition = bad. In 2007 the changes would not propogate to child types properly. In 2010, the overwrite flag helps, but mileage varies depending on if the ContentType is unghosted vs ghosted.
Looking into the suggested fix at the bottom of that post (modify the site columns in 2007) lead me to believe that these null missing items are coming across in the situations where the feature defined items were ghosted. If there is a definition on the filesystem, why eat up the database storage by pushing it in there at the start. We’ll only add the value once the item becomes unghosted.
We’re testing this out now, but I’m comfortable saying that with Content Types
ghosts = bad; get rid of them.
So, if you’re upgrading and making structure changes to your feature folders and don’t want to modify any of the content, make sure to keep your masterpage gallery items in the same place reghosted to pickup changes and unghost your contenttypes so that they don’t blow up when their xml references are different.