05/22/08
Page Layouts Not Updating on Solution Upgrade
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.
5 comments
on 05/23/08 at 09:49
Thanks for the post. It's worth noting that you don't need to *modify* a page layout with SPD in order for it to become customised. Just opening the file in SPD is enough to customize it.
I found this out recently, after a long and painful process very similar to yours, and I haven't seen this info published anywhere else.
Anthony
Nice finding. We were also facing the same problem and we removed this tag from out page layouts to uncustmoize the layouts. We noted that these tags exists when we are having Webpart Zone into the page layouts. did you also noticed that as well?
If by mistake any user opened any layouts into the SPD then following method can be used for reverting them back to file system.
To revert the pages back to file system you can use "revertToContentStream()" method of page layouts. if above mention tag is avaiable in the page layouts then even after running the above method on all page layouts , these layouts will be considered as customized. So these tags needs to be removed from page directive before moving them into the feature files. I am just adding this for readers.
Regards
Deepak
on 05/27/08 at 11:41
Tony, it depends which kind of page is customized, as to how to revert it back. If you are talking about Publishing Pages that are based on a page layout, like Deepak said, you can call the SPFile.RevertContentStream() method, or in SharePoint Designer you can right click on the page in the site tree view, and select an option to revert to the original.
SPFile.RevertContentStream():
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.revertcontentstream.aspx
This post has 4 feedbacks awaiting moderation...
Comment feed for this postLeave a comment
