One of the more frustrating things I've run across when working with SharePoint is dealing with templates to define the look and feel of a Portal.
SharePoint installs various .aspx files on the server which define the default template for all of the different types of pages in the Portal. If you want to change the look and feel of the Portal, one option is to update these .aspx files.
Another option is to open the web in FrontPage and edit the page. What I've run across is that once the page has been saved using FrontPage, changing the .aspx file no longer affects the page.
So for example, I want to change all Portal Areas to have a new header graphic. I can go to the c:\Program Files\Common Files\Microsoft Shared\web server extensions\60\template\spstopics folder and edit the default.aspx file. After I add my graphic to that file, refreshing the area pages in the portal should reflect my change - all of them. Existing areas as well as new areas I create.
However, let's say I open up the web in FrontPage, and I go to the Departments area and I edit the default.aspx page in FrontPage. Once I save those changes, the page becomes "unghosted." That means it is no longer parsed by the ASP.NET engine and does not use the default.aspx file on the file system. Instead, it is parsed by the SharePoint safemode parser using data from the database. The advantage here is that the page is parsed faster and security vulnerabilites of ASP.NET are eliminated (for example, malicious code injection). If all of my department areas are unghosted and I want to change a graphic on the header of the pages, I must edit each one seperately. Changes to the default.aspx file on the file system still will affect new areas when created.
This can be a bit frustrating when you are still working on finalizing the look and feel of a Portal. Once the pages become unghosted, you can't just change the template file and expect all existing pages to reflect the change.
This is what I am dealing with at a current client. We are working on the look and feel for all team sites. Unfortunately, one particular team site has become unghosted, so it does not reflect any changes we've made to the default.aspx template.
I did find a solution for this, though. I found great SharePoint Blog by Maurice Prather. He has created a Web Part Toolkit you can download and that includes a ghostfinder web part. This web part, once installed, will list all pages on the portal that are unghosted. It also allows you to reset the page, so that it then becomes ghosted.
We will use this at the client to ghost that one team site page so that it will reflect the changes to the template file.
Another aspect of ghosted pages is performance. I found the following snippet on TechNet:
"SharePoint Portal Server 2003 stores some of its basic page and template information in the file system on the front-end Web server. These pages, which have not been customized, and metadata are called 'ghosted pages.'
"When a page is modified, it is written to the database and read from there. The performance impact of reading these pages from the database rather than from the disk is approximately 10 percent."