SharePoint Site Definitions: Why You Need Them and How to Use Them

harePoint makes developing templates easy. You simply create a site the way that you want it and then save it as a template, quickly and easily freezing the site setup into a reusable stamp that you can then use to create other sites. However, user templates in SharePoint can lead to performance problems and may not be the best approach if you’re trying to create a set of reusable templates for an entire organization. Instead, you should use site definitions to create templates that form the basis for creating new sites. The site definitions approach doesn’t suffer from the same limitations as user templates.

Understanding Ghosting and Unghosting
Before diving into site definitions it’s important to understand one of the inner workings of SharePoint. When you create a new site, SharePoint doesn’t really copy the pages for that site? default.aspx and so on?into a new database table or directory. These files exist once and only once on each of the front end Web servers. Instead, SharePoint creates a reference to those files in the database tables that define the new site, a process called “ghosting.” The outcome is that the site appears to have its own unique pages, but the pages are actually shared across all sites that use the same definition.

This has two distinct advantages over copying the files to each site individually when the site is created. First, it saves space. If you have a thousand sites, rather than having a thousand copies of a file you still have only one. Second, it improves performance. Instead of having to load and cache a thousand pages from the database, the server needs to cache only one copy from the file system, which can improve performance by freeing cache memory for other purposes. Loading the file from the Web server’s local file system improves performance by eliminating the overhead of the database call and the network traffic to the database.

One interesting benefit of this approach is that when you make a change to one file on the file system, that change takes effect across all the sites that have been created. All in all, the process of ghosting is a huge benefit to SharePoint. However, there are some limitations.

SharePoint can’t ghost every page. Some operations, such as editing a page in FrontPage, cause SharePoint to “unghost” dependent pages for the site. Because ghosting requires all ghosted pages to be exactly the same across all the sites that share them, SharePoint unghosts, or creates a copy of the page in the database, whenever a ghosted page changes, for example, when someone performs an edit operation on the page. Unghosting lets users customize their own sites without impacting other users who might be using the same file. Unfortunately however, unghosting also has a negative performance impact, and makes global changes, such as applying corporate branding to the entire collection of sites far more difficult. Unghosting is the primary reason why efforts to leverage the power of site definitions to change the branding of an entire site may not work as intended.

Exploring Site Definitions
Site definitions are the foundation on which all sites and user templates are built. They consist of a set of files found in the C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions60TEMPLATE directory. For English sites you’ll find the templates under the 1033 directory. This is the first evidence of a multi-lingual design for SharePoint. The 1033 number in the directory name corresponds to the US English locale ID.

Underneath this directory you’ll find at least three sub-directories: XML, STS, and MPS. Except for the XML directory, each directory represents a different site definition. SharePoint stores all the files that make up the site definition in the STS and MPS directories. The XML directory contains one or more files that match the filename pattern WEBTEMP*.XML. These files list the site definitions. For example, the base WEBTEMP.XML file lists both the STS and MPS site definitions. If you install SharePoint Portal server you’ll also have a WEBTEMPSPS.XML file, which contains all the site definitions for SharePoint Portal Server.

Each WEBTEMP*.XML file has a simple format that starts with a Templates tag containing a nested set of child Template tags. Each Template tag contains a set of Configuration tags. This structure lets you specify new site definitions, each of which can have an initial configuration. The template defines the look and feel while the configuration defines the initial configuration of lists and Web Parts. This becomes obvious when you view the WEBTEMP.XML file shown in Listing 1.

In the WEBTEMP.XML file in Listing 1, the Team Site, Blank Site, and Document Workspace sites all share the STS site definition, but the configuration referenced for each is different. The Configuration ID refers to a set of instructions in the ONET.XML file which, along with several other files and folders, compose a site definition.

Dissecting an Individual Site Definition
Site definitions consist of a hierarchy of files and folders that contain some specific entries. Each template requires three directories: DOCTEMP, LISTS, and XML. The XML folder contains the ONET.XML file, which is essential for creating the corresponding site. Although its contents are a bit messy, ONET.XML contains all the major settings that you need for controlling initial site creation. The XML folder also contains a STDVIEW.XML and VWSTYLES.XML, which control the most basic list display control and allow you to adapt list appearance to meet your needs. You can see these basic display types in the list of options displayed when creating a new View?standard, datasheet, and calendar view base types. Additionally, the styles section of the view settings displays the different ways that the fields in the list can be displayed together.

In the DOCTEMP folder you’ll find the various template documents for the different kinds of files referred to by the ONET.XML file in the tag. These are the templates that SharePoint uses when you click the New Document button in a document library.

The LISTS folder contains a set of subfolders that correspond to the tags in the ONET.XML file. Each of these folders contains a SCHEMA.XML file that defines the fields, views, and general information about the appearance of the list within the site. The SCHEMA.XML fills essentially the same role as the ONET.XML file except that it operates within the scope of a list rather than a site.

Throughout the folder structure you’ll find .aspx files. These are the Web Part pages that SharePoint uses to display your sites. Changes made to these files affect all the sites that still have that page ghosted. In essence a change to one of the .aspx files in the site definition directory can take effect across the entire set of sites created from the definition.

Dissecting the ONET.XML File
Because the ONET.XML file is a core file that tells SharePoint how to configure a newly created site, it’s somewhat complicated; however, the major sections in the file are relatively straightforward after you examine them in a logical progression:

  • Configurations maps the configurations referred to in the WEBTEMP*.XML file in the XML directory off of the locale ID folder. The configuration section tells SharePoint what things to include in a configuration including lists (ListTemplates), Web Parts, and Web Part pages (Modules).
  • ListTemplates creates the templates for lists to be used by the configurations. It leverages the BaseTypes section to control the basic fields and other detail information, and describes global settings for the list, including its ID, descriptive text, and an image.
  • BaseTypes defines the fields and views for a created list. The ListTemplates section uses the BaseTypes section to create a completely formed list.
  • DocumentTemplates provide users with a list of document templates from which they can select the default document template for a Document Library when creating a document library list.
  • Modules describes the files to be added to the SharePoint site and how those files should be configured. In SharePoint every Web Part page is a file. Because of this the modules section describes what Web Parts to display on a file. It also controls the appearance of the navigation bar on those pages.
  • NavBars describes how the navigation bar should look. The navigation bar is the area at the top of the page that typically displays home, documents, lists, etc. This section controls the appearance of the navigation bar for all sites derived from this site definition.

While a detailed exploration of the ONET.XML file is beyond the scope of the article, here’s a typical customization sequence so you can see how the process works and some of the places where the file can be modified.

Installing Your Own Site Definition
The first step in customizing a site definition is to install it into SharePoint. You start this process by copying an existing site definition and placing it into another directory. You can use any of the existing site definitions as your starting point. For demonstration purposes, copy the STS site definition folder structure to a new DEVX folder. Doing that gives you a new site definition based on the contents of the DEVX directory.

Next, connect the DEVX site definition to SharePoint by copying the WEBTEMP.XML file located in the TEMPLATEXML directory to a file named WEBTEMPDEVX.XML. Open the file and delete any unnecessary