Ghosting and Unghosting in SharePoint

Ghosted pages are pages whose content doesn’t reside in the content database (save as a row with a null value for Content); they reside on the actual file system disk. When site pages are customized, the page is unghosted and their content is then stored in the content database. The issue with unghosted pages is that site maintenance and performance can be affected (e.g. updating server or solution may be impacted or site caching may be affected).

[ In SharePoint Designer 2010, though, you have the option to have more control over how site pages are customized—thus disabling the ghosting process from occurring. To find this functionality, go to SharePoint 2010 Central Administration, and click General Settings, and then under the SharePoint Designer category click Configure SharePoint Designer settings

Under the Configure SharePoint Designer settings, you can check/uncheck a number of settings—one of which is the Allow Site Collection Administrators to Detach Pages from the Site Template option. If you uncheck this option, you are disabling the detachment of pages from the site definition—thus disabling ghosting from occurring.

What happens is that site collection administrators can now edit the site is Normal mode from SharePoint Designer; not the Advanced mode, which supports the ghosting/unghosting process. ]

Ghosted means that the Site Definition pages have not been customized and the pages in your Site Definitions run directly from the file system (cached of course).

SharePoint provide users with an easily customizable platform to do work. It leverages both files on the file system and data in a database to virtually create many sites most of which share the same files on the file system. The net effect is that SharePoint gives the appearance that it’s many files when in reality it’s a relatively small number.

This is accomplished by a technique that used to be called Ghosting. SharePoint contains database entries for each site and each page in the site. By default these entries refer back to a file on the file system. The result of this is that there’s good performance and the ability to impact changes on a massive scale just by changing one file. Since every site refers back to that one set of files making a change there has a global impact.

These files reside in physical ~\TEMPLATE\LAYOUTS\ path of 12 hives.

For example, the default home page is a ghosted page.  Any web part pages created via New Web Part Page user interface also ghosted.

You can also check this out by going to a page like the default.aspx page in the STS Site Definition and typing “Hello” in the body somewhere. Run IIISRESET to clear the cache, and you’ll see that “Hello” shows up immediately on all sites that were created using that Site Definition.

Unghosted means that the site has been customized.  When you customize a v2.0 site in FrontPage or a v3.0 site in SharePoint Designer, or you add custom fields to a Document Library, or create sites using that template; then the changes that you made are stored in the database as a diff and that is referred to as Unghosted.

A request for a Customized (Un-Ghosted) page returns a response which is a combination of data from both the file system and the database. In v2 this was a performance hit, and you wanted to avoid having a large number of sites that were Un-Ghosted. In v3 – caching etc. has been improved.

Ghosted = Un-Customized, The asp.net parser renders the page.

Unghosted = Customized, Controlled by the SafeMode parser.

Is it possible to “reset” an unghosted page to its original ghosted state? No.

This ties into the previous answer. Straight out of the box, there is no way to return a page to its originalghosted state.

Can a page transition from a ghosted state to unghosted? Yes.

Ghosted pages become unghosted once a file has been modified. If a page is updated using FrontPage 2003, web folders, or the modification of custom document library fields, the Content column of the given document row is populated with the page contents. All uploaded .aspx files are automatically unghosted

Ghosted Page in SharePoint
A ghosted page is a page in SharePoint website which is not stored in the database instead it reference to a file which exists in the server’s file system. These reference files are common for all the website/site collection within that SharePoint server, i.e., if you modify a reference file then that change will reflect in all the websites/site collections within that SharePoint server automatically. So we can say these reference files are used as template.

The default master page of SharePoint “default.master” is a well known example of ghosted page. “default.master” page is located in the directory “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Global”. If you do some changes in the “default.master” then this change will automatically reflect in all the websites within that SharePoint server.

To create a new site in SharePoint, a site template is used. Site template contains description of all the pages, webparts within the pages, master page used, custom lists, etc. for the web site to be created. You can define a page ghostable in the “onet.xml” file of the site template.

Unghosted Page in SharePoint
All the pages in a SharePoint website which are stored in the content database are referred as unghosted pages. All the unghosted pages are specific to that SharePoint website only, i.e., changes done in an unghosted pages will not reflect in other websites within that SharePoint server.

If a new website is created with a site template which contains a page defined as “unghostable” in the “onet.xml”, then that page will be stored in the content database of new website created and will not reference to the page available in the site template folder.

If a ghosted page is modified in the SharePoint designer, it will become unghosted. For example if a master page is customized in SharePoint Designer, SharePoint stores a modified version of the master page in the content database and also it breaks the reference to the “default.master” file on the “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Global“.