This post has come about due to some challenges when upgrading a publishing site page layout.
Before we delve into the issues I best explain how the Page Layouts are setup. The page layouts are all contained within a feature called “Company.Intranet.Publishing” which are deployed to the folder:
Each of the page layouts are deployed into the master page gallery (/_catalogs/masterpages) using a Module. The page layouts are deployed as uncustomised or ghosted files.
The fact these resources are deployed as ghosted files is very important as you will see in the next section.
Finally the feature is deployed using the SharePoint Solution framework as a single SharePoint WSP using WSP Builder.
What do you mean by Ghosted / UnCustomised files?
There has been quite a lot of information published about this and the following are good resources:-
- Maurice Prather: http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=4
- Eric Shupps: http://www.pointsharepoint.com/2010/02/great-debate-sharepoint-designer-vs.html
My understanding is that a ghosted file is where the binary content is actually stored on the file system of the server and a pointer to that binary content is held in the content database. If a user modifies the content of a page layout in a site collection by a tool such as SharePoint Designer then a copy of that binary content is taken from the file system and merged along with the changes made by the user and stored in the content database.
Hence when you retrieve an uncustomised file its binary content is being pulled from the content database.
Why are Ghosted / Uncustomised files preferred?
Recently at the SharePoint Best Practices conference, Eric Shupps and Rob Foster did a great presentation on Fine Tuning and Optimising SharePoint Performance. One of the key points in improving performance is to ensure that files are ghosted/uncustomised for the following reasons:-
- Ghosted files all point to a single file and hence they all point to the same binary content. This means only one file needs to be cached and the load on the database is significantly reduced.
- Actually Unghosted files cannot be cached within a BlobCache. Unghosted files are therefore slower to load and render (10% slower on average) than a ghosted file.
Upgrading Page Layouts
The method used to upgrade page layouts is simply by redeploying the files through an updated wsp solution file. We have also been careful through training and guidance with users to ensure that page layouts are not edited through SharePoint Designer.
Therefore if a change to a page layout is required, then the page layout is updated within the feature directory using Visual Studio and the WSP solution file is rebuilt.
The solution is then ready to be updated using the command:-
stsadm –o upgradesolution –filename [solutionname.wsp] –name [solutionname.wsp] –allowgacdeployment –allowcaspolicies –immediate
The change to the page layout is then reflected within the SharePoint site.
Why are my changes are not seen?
More history, our last deployment required that we tidied up the page layout’s title and description.
One of the problems with using a Module to deploy files within a feature is that with SharePoint 2007 it is difficult to make changes to existing files deployed by a module without resorting to code. Any changes to the filenames or properties that are deployed by the Module are not reflected until the file is deleted from the site collection.
As there were not that many site collections, we took the decision not to write any code and we modified the page layout titles and descriptions through the SharePoint UI.
Unfortunately when we did our next release into our testing environment the changes to the page layout markup were not seen within the site.
After checking that the page layouts were being deployed correctly to the the WFE’s file system we started thinking of the reason. Finally I thought it must be due to unghosting of the files.
Normally you can use SharePoint Designer to revert page layouts to their site definition. So I fired up SharePoint Designer and browsed to the /_catalogs/masterpages document library but could see that the Page Layouts were not customised.
I started to search for tools to find out which files are customised. The legendary Gary LaPointe (@glapointe) came to the rescue.
If you don’t deploy Gary LaPointe STSADM tools on your Production/UAT environments then I plead with you that you start to do so as soon as possible. Time and time again I have been in a bind and Gary’s STSADM commands have got me out of trouble.
The commands that saved the day this time are:-
The commands give a lot of flexibility, though I will warn you that you need to be a bit careful as you could quickly reghost all the files within your site collection if you are not careful.
I performed the following command:-
stsadm –o gl-enumghostedfiles –url http://sharepointsite.domain.com/
This displayed a list of files that were unghosted. Funnily enough all the page layouts that we had modified and changed their Title and Description fields had become unghosted!
Once we had a list of the unghosted page layouts we could reghost each of them in turn using the command:-
stsadm –o gl-reghostfile –url http://sharepointsite.domain.com/_catalogs/masterpage/RandomPageLayout.aspx –Scope File
This command would reghost each of the files, there were occasions where the page layout reghosting would fail, using the –force option for the gl-reghostfile would ensure that the page was ghosted.
Now looking at the site the page layouts had been updated and reflected the changes that had been deployed by the update solution.
Hope that helps!
Just what I was looking for.. Thanks a lot!
Glad that it helped!
I wanna ask if I create a page through page layout (this page has a web part )then I updated the web part in page layout , why it dosen’t reflect in the created pages ,,, Is there any solution for this problem
Is the web part embedded on the page layout found in the _/layouts directory or something that you added using the SharePoint UI?
If the webpart has been added afterwards using the SharePoint UI then the webpart is added to the SharePoint Content Database for that particular instance of the page.
If you want the webpart to appear on all pages you will need to add to it the page being deployed into the /_layouts directory. Something that you will need to think about though is if the webpart needs different configuration options for each location, you will need to think about how they are stored.
is this the command:
stsadm –o gl-enumunghostedfiles –url http://sharepointsite.domain.com/
stsadm –o gl-enumghostedfiles –url http://sharepointsite.domain.com/
Thanks for taking the time to pick up on the article I will take a look and modify accordingly
Simon, I like the article–Connect to me on linkedin.
thanks, Stephan Onisick