Guest Author: Susan Henry

In SharePoint 2003 the concept of Ghosting and Unghosting described what happened to your files when they were modified or customized. With SharePoint 2007 that terminology and the process by which customizations are handled has changed drastically. Instead SharePoint 2007 and WSS 3.0 are built on top of ASP.NET 2.0 and use the Virtual Page Parser. Thus, the process has changed and so has the name. With the next version of SharePoint right around the corner it’s probably a good idea to use the newer naming convention of Uncustomized/Customized and understand what it’s all about…

Anyone who has worked with SharePoint “branding” in any capacity has encountered the following message when trying to save changes to any of the files in your site’s file system. You get the Site Definition Page Warning message…

The question is, what does it mean??? When you say “Yes”, what actually happens? Why do your files (i.e., aspx pages, master pages, etc) then have this little blue “i” next to them??? These are questions you should be asking because it’s important to understand how your changes are affecting the bigger picture within your SharePoint environment. The best way to understand this is to dive a little deeper into the guts of SharePoint.

You’ll notice if you hover over the page it actually tells you what that symbol means, “Page is customized”…

A brief background here… SharePoint is a site-provisioning engine that supports user site creation and a large number of sites. Every SharePoint site is part of a larger container, the site collection, which lives inside a content database within SQL Server. Each content database contains all of the files, lists, libraries, and data that make up your SharePoint site.

However, some of these files, like the ASPX pages and Master Pages, don’t actually live in the content database, not out-of-the-box at least. In lieu of these files residing in the content database there are instances or pointers back to the original files that live on the SharePoint server itself, inside the 12 Hive. This virtualized file system means that site pages and application pages are served up by ASP.NET from the 12 Hive by the instances or “pointers” in your site’s content database.

Once you make your changes to one of these files you are “customizing” that file and essentially creating your own version that will be stored in the content database. Once a file is customized it no longer points back to the SharePoint server file system and is instead pulled directly from the content database. This is the main distinction between uncustomized and customized files in SharePoint…

Uncustomized means that the source of the file lives on the file system NOT in the content database. Only an instance or pointer exists in the content database. This is how all Master Pages and ASPX pages start out.

Customized means that the source of the file lives ONLY in the site collection’s content database. When an end-user requests a customized page, SharePoint loads all markup from the database.

The diagram below gives a visual representation of the process by which Uncustomized files are served to an end-user.

With all that said, why should you care whether or not your files are customized???

Depending on your environment, you’ll want to understand where the majority of content is being served from because there may be performance issues if you are constantly fetching customized pages from the database. You’ll also want to keep in mind that the more files you customize, the more you’ll have to keep track of. When you consider upgrade scenarios, disaster recovery, or major design changes, the more customized files you have to keep track of, the more overhead you’re faced with.

The biggest red flag I’ve seen is when people create a multitude of customized ASPX pages that are detached from a Master Page. If that sounds familiar, you should probably take a step back and reassess your game plan. I say that only as a word of caution because the more customized files you have, the more difficult it becomes to maintain. Just try to use the tools like Master Pages and Cascading Stylesheets to your advantage so that you don’t end up pulling your hair out later on.

Once you’ve customized a page, you can always revert back to the original, i.e. the site definition. You can find that option on the file menu and it will create a copy of your customized file and replace the original with what exists on the server.

Guest Author: Susan Henry

Susan Henry is a SharePoint Consultant with ettain group, a Microsoft Gold Certified Partner based in Charlotte, NC. Her career began in web design and development, but for the past two years her primary focus has been with Mircosoft SharePoint Technologies. She specializes in Administration, Architecture and Design. She has extensive experience with SharePoint Branding and Web Content Management and has helped several clients take their SharePoint sites to the next level through customization and design.