One of the more complicated, and yet fundamental aspects of SharePoint is the concept of “customization” or “unghosting”. When a page is not customized, it should refer to the definition that was installed on the file system in the 12 hive. That being said, when you do an stsadm -o upgradesolution command, and you update that definition on the file system, all the uncustomized pages on the site should pick up that change.
I was running into a mysterious circumstance where the changes were not being picked up in my Publishing Page Layouts. When I did an upgradesolution, I was finding that I needed to actually deactive, then reactive the feature that provisioned those Page Layouts into the Master Page Gallery at the site collection root. Futhermore, I ran into this confusing conundrum: if I set the “Ingore if already exists” property on your Module file element, it wasn’t overwriting the older version of the Page Layout, yet if I set that value to true, it wouldn’t install the feature because the Page Layout already existed in the Gallery. The second option was prohibitive because you can’t delete a Page Layout that has pages based on it. What’s a girl to do?
I knew the documentation said an upgradesoltuion command would only upgrade uncustomized items, since customized pages essentially have a copy of the original definition stored in the database. However, I had never modified my Page Layout using SharePoint Designer, and no one had even touched the page since it was provisioned, so it never occurred to me the page could be customized.
After hours of struggling with this issue, I started wondering about some rogue tags in my Page directive at the top of my Page Layout .aspx pages. They looked like this:
meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document"I have heard more times than I can count that you should never create Page Layouts in SharePoint Designer and then move the code to a Feature in Visual Studio, but dangit, it’s an easy was to code. (I had removed the Robot control and thought that was enough.) It turns out, those directives are added by SharePoint Designer when a Page Layout is customized in SharePoint Designer. Futhermore, somehow, those tags instruct SharePoint to customize those Page Layouts. What that means is, although my Page Layouts from my Feature had been untouched by hunman hands (or SPD), it was still being customized the moment it was being provisioned in SharePoint. That’s why my upgradesolution command wasn’t working.