One of my clients was having an issue where solution upgrade or redeployment didn’t change certain page layouts. I checked the CustomizedPageStatus property of the affected layouts and it said they are customized. However, they had not actually been customized.
I activated the problem feature in another environment. Much to my surprise, the particular layouts indicated that they were customized immediately based on the provisioning for the module!
I didn’t see any difference between the couple of layouts that exhibited this behavior and the others in the same module that were appropriately uncustomized post provisioning. Also, I observed that on a stock publishing portal site with no customizations the same is true of VariationRootPageLayout.aspx.
I figured I couldn’t be the only one to have seen this behavior, so I asked the Internet and fellow MVP Rodrigo Pinto gave me the answer which I am blogging here in hopes that you’ll have better luck finding the answer with the search engine of your choice than I did!
The affected page layouts all contained meta: attributes from SharePoint Designer as shown in the following example.
meta:progid="SharePoint.WebPartPage.Document" meta:webpartpageexpansion="full" %>
The presence of these causes SharePoint to ‘unghost’ or customize the page upon the initial provisioning. The affect is exactly the same as if the page was manually modified or uploaded into the library – subsequent upgrades do not affect the version in the site. I removed these from each of the affected layouts and checked in the changes. Once we upgraded the solution were able to run a script to re-ghost (uncustomize) the affected layouts. The script used Gary Lapointe’s excellent extensions: http://blog.falchionconsulting.com/index.php/2007/09/re-ghosting-pages/
Author: Doug Ware