Creating Site Definitions

Site definitions are similar to templates. Site definitions are composed of several files located in the file system on each Web server. The site definition files contain XML tags that define a template for a site. The default site types included with Windows SharePoint Services are created using site definitions (such as Team Site, Blank Site, Document Workspace, and so on). Windows SharePoint Services creates a version of each site definition during installation. The site definition files are stored in subdirectories in the following location:

Local_drive:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\

It is recommended that you create a custom site definition by copying an existing site definition, rather than modifying the original files installed with Windows SharePoint Services. Changes that you make to originally installed files may be lost when you install updates or service packs for Windows SharePoint Services, or when you upgrade a deployment to the next product version.

To create a site definition

1. Copy the existing site template folder in the following location:

   Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\lcid
       

   For example copy the site template folder and rename it "TRAINING".

2. Then copy the WEBTEMP.XML file in the following location:

   Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\TEMPLATE\1033\XML
       

3. Rename the file, for example, WEBTEMPTRAINING.XML.

   During initialization, the compiler merges the information contained in files prefixed with WEBTEMP*.XML and makes them available for creating sites. This provides easy extensibility for third-party ISVs to create additional site definitions that integrate with SharePoint Products and Technologies.

   Note   All areas in a SharePoint Portal Server deployment are stored in directories that begin with /SPS*.

A site definition is composed of three main files: WEBTEMP.XML, ONET.XML, and SCHEMA.XML. The following table shows the files' locations in the file system, and their definitions.

Table 1. Site definition files

Site Definition File	Location	Description
WEBTEMP.XML	Local_drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\60\TEMPLATE\1033\XML	Specifies configurations of lists and modules for a site definition.
ONET.XML	Local_drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\60\TEMPLATE\1033\*\XML	Defines navigation bars such as the top link bar and the quick launch, available lists, document templates, base types, configurations, modules
SCHEMA.XML	Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\TEMPLATE\1033\Custom_Site_Template\LISTS	Defines the columns, views, and contents of a list

WEBTEMP.XML

A WEBTEMP.XML file contains the site definitions that are available on the Template Selection page for creating instances of sites. WEBTEMP.XML defines the site template for a site definition. By default, Windows SharePoint Services includes the following site templates: Team Site, Blank Site, Document Workspace, and Meeting Workspace.

You can edit the default WEBTEMP.XML file to modify the existing list of templates available to users. To hide a particular template on the list of site templates, locate the section for that template in the WEBTEMP.XML file, and then set the Hidden attribute of the Configuration element to TRUE. Set Hidden to FALSE to make the template visible.

Remember to copy and rename the WEBTEMP.XML file before making changes to the default version. In the following example, we use the copied and renamed file WEBTEMPTRAINING.XML to create a Training Team Site and a Trainee Workspace.

WEBTEMPTRAINING.XML
<?xml version="1.0" encoding="utf-8" ?>
<Templates xmlns:ows="Microsoft SharePoint">
<Template Name="TRAINING" ID="10101">
<Configuration ID="0" Title="Training Team Site" Type="0"
Hidden="FALSE"
ImageUrl="images/stsprev.jpg"
Description="This template provides a forum
for the team to create, organize, and share information
quickly and easily. It includes a document library, and
basic lists such as Announcements, Events, Contacts,
and Quick Links.">
</Configuration>
<Configuration ID="1" Title="Trainee Workspace" Type="0"
Hidden="FALSE"
ImageUrl="images/dwsprev.jpg"
Description="This definition creates a site for Trainees
to work together on specific documents.">
</Configuration>
</Template>
</Templates>

The WEBTEMPTRAINING.XML file contains a Template element used to define a single template for a site. Each Template element has a Name attribute that must match the name of the XML file prefixed with webtemp. For example, the value of the Name attribute (in this example, training) is the same as the file name following the prefix of webtemp. During initialization, Windows SharePoint Services scans for files with a prefix of webtemp*.xml and loads them into memory.

Note   For changes to appear, you must reset Internet Information Services (IIS) whenever making changes to any of the WEBTEMP*.XML files.

A site definition only needs one root Template element. To avoid conflict with IDs already used by Windows SharePoint Services, use unique values greater than 10,000 for the ID attribute.

The WEBTEMPTRAINING.XML file creates additional template options for selecting a new template during site creation, as shown in Figure 1.

 

Figure 1. Training Workspace and Training Team Site templates are created (Click picture to see larger image)

ONET.XML

The ONET.XML file defines the top link bar and the Quick Launch bar. It also specifies the default document and list templates that are available for a Web Part Page such as document library, picture library, custom list, discussion boards, surveys, and so on. The ONET.XML file also specifies the configuration of files to include during site creation, and includes modules that identify the location of these files during site creation.

 

Figure 2. Default options specified in the ONET.XML file (Click picture to see larger image)

For detailed information, see "ONET.XML" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).

Customizing the Navigation Bar for a Site

You can customize the navigation bar of an existing site by adding a NavBarLink element to a NavBar element within the ONET.XML file for a custom site template. You can add links to local files and pages on the server or to files and pages located elsewhere.

The following example adds two NavBarLink elements, one that provides a link to a local file on the server, called Sample.aspx, and the other that provides a link to a URL, http://example.microsoft.com/.

<NavBars>
<NavBar Name="SharePoint Top Navbar" ID="1002">
<NavBarLink Name="Documents and Lists"
Url="_layouts/[%=System.Threading.Thread.CurrentThread.CurrentCulture.LCID%]/viewlsts.aspx">
</NavBarLink>
<NavBarLink Name="Create"
Url="_layouts/[%=System.Threading.Thread.CurrentThread.CurrentCulture.LCID%]/create.aspx">
</NavBarLink>
<NavBarLink Name="Site Settings"
Url="_layouts/[%=System.Threading.Thread.CurrentThread.CurrentCulture.LCID%]/settings.aspx">
</NavBarLink>
<NavBarLink Name="Get Current Data" Url="_layouts/Sample.aspx"></NavBarLink>
<NavBarLink Name="microsoft" Url="http://example.microsoft.com/"></NavBarLink>
<NavBarLink Name="Help" Url="javascript:HelpWindow()"></NavBarLink>
</NavBar>
<NavBar Name="Documents" ID="1004">
</NavBar>
<NavBar Name="Pictures" ID="1005">
</NavBar>
<NavBar Name="Lists" ID="1003">
</NavBar>
<NavBar Name="Discussions" ID="1006">
</NavBar>
<NavBar Name="Surveys" ID="1007">
</NavBar>
</NavBars>

The value of the Url attribute in the local link is relative to the top-level SharePoint site.

Using Site Configurations

When creating site definitions, the configuration identifies which lists and modules to include. A configuration allows a site definition to have multiple options for site layout and design such as Team Site, Blank Site, and Document Workspace. Each of these site templates result in a different configuration of lists and Web Parts. Both WEBTEMP.XML and ONET.XML include a Configuration element. In WEBTEMP.XML, this element is contained within the Template element and specifies the configuration options to include for the site definition.

In ONET.XML, the Configuration element is contained within a Configurations element that specifies one or more configurations containing lists and modules. Each Configuration element contains an ID attribute. The ID attribute associates the configuration specified in a site template with a configuration of list definitions in the ONET.XML file. The combination of this ID and the value of the Name attribute in the Template element provides a reference to the contents of a specific Configuration element in a ONET.XML file.

You can reuse existing list definitions specified in the ONET.XML file for a site definition. You can also create multiple configurations in a single ONET.XML file. In this approach, each configuration enables the creation of a site with a different set of lists, Web Parts, and layout.

Table 2. Configuration element attributes

Name	Description
Description	Optional Text. Contains the description of the site configuration that appears on the Template Selection page.
Hidden	Optional Boolean. Specifies whether the site configuration appears as an option on the Template Selection page.
ID	Required Integer. Specifies a unique ID for the configuration.
ImageUrlURL	Optional Text. Contains the URL for the preview image displayed on the Template Selection page.
Name	Optional Text. Contains the name of the configuration.
Title	Optional Text. Contains the title of the configuration that is displayed on the Template Selection page.
Type	Optional Text. Identifies the configuration with a specific site definition.

To set up a configuration within a site definition, use Configuration elements within a custom WEBTEMP*.XML file and within one or more ONET.XML files that are referenced in the WEBTEMP*.XML file.

For example, the WEBTEMPTRAINING.XML file in the previous example uses two configurations to define different site configurations, one for a training team site and the other for a training Document Workspace site. This example involves use of only two configurations within a single site definition, but you can include multiple definitions with different configurations within a single WEBTEMPTRAINING.XML file, each one referencing different site definition directories and their respective ONET.XML files.

In the ONET.XML file, each configuration defines a specific type of site that can be created from the site definition. All configurations within this file share a set of available list definitions, document templates, navigation areas, base list types, and modules that are defined within the file. You can add a reference to a list that is defined in ONET.XML by adding a List element to the collection of lists specified within a Configuration element. For example, if you define a list type named "My_Custom_List" in ONET.XML with a Type attribute of 143, then you can add <List Title="My_Custom_List" Type="143" URL="Lists/My_Custom_List" /> to add the list to the configuration. The following example shows the arrangement of configurations in the ONET.XML file for a specific WEBTEMP*.XML file:

<Configurations>
<Configuration ID="0" Name="Default">
<Lists>
<List Title="My_Custom_List" Type="143" Url="Lists/My_Custom_List" />
<List Title="Shared Documents"  Url="Shared Documents"
QuickLaunchUrl="Shared Documents/Forms/AllItems.aspx"
Type="101" />
<List Title="General Discussion" Url="Lists/General Discussion"
QuickLaunchUrl="Lists/General Discussion/AllItems.aspx"
Type="108" />
<List Title="Announcements" Type="104" Url="Lists/Announcements" />
<List Title="Links" Type="103" Url="Lists/Links" />
<List Title="Contacts" Url="Lists/Contacts" QuickLaunchUrl="Lists/Contacts/AllItems.aspx" Type="105" />
<List Title="Events" Type="106" Url="Lists/Events" />
<List Title="Tasks" Url="Lists/Tasks" QuickLaunchUrl="Lists/Tasks/AllItems.aspx" Type="107" />
<List Title="Site Template Catalog" Type="111" Url="_catalogs/wt" RootWebOnly="TRUE" />
<List Title="Web Part Catalog" Type="113" Url="_catalogs/wp" RootWebOnly="TRUE" />
<List Title="List Template Catalog" Type="114" Url="_catalogs/lt" RootWebOnly="TRUE" />
</Lists>
<Modules>
<Module Name="Default"/>
<Module Name="WebPartPopulation"/>
</Modules>
</Configuration>
<Configuration ID="1" Name="DWS">
<Lists>
<List Title="Shared Documents" Type="101" />
<List Title="Image Library" Type="109" />
<List Title="General Discussion" Url="Lists/General Discussion"
QuickLaunchUrl="Lists/General Discussion/AllItems.aspx" Type="108" />
<List Title="Announcements" Type="104" Url="Lists/Announcements" />
<List Title="Contacts" Url="Lists/Contacts" QuickLaunchUrl="Lists/Contacts/AllItems.aspx"
Type="105" />
<List Title="Links" Type="103" Url="Lists/Links" />
<List Title="Events" Url="Lists/Events" QuickLaunchUrl="Lists/Events/AllItems.aspx"
Type="106" />
<List Title="Tasks" Type="107" />
<List Title="Site Template Catalog" Type="111" Url="_catalogs/wt" RootWebOnly="TRUE" />
<List Title="Web Part Catalog" Type="113" Url="_catalogs/wp" RootWebOnly="TRUE" />
<List Title="List Template Catalog" Type="114" Url="_catalogs/lt" RootWebOnly="TRUE" />
</Lists>
<Modules>
<Module Name="DWS"/>
<Module Name="WebPartPopulation"/>
</Modules>
</Configuration>
</Configurations>

Using Modules

Modules serve two purposes. Modules specify all the files associated with a definition and they specify the location of these files in the new site. For example, if the file is a Web Part Page, the module definition specifies both the Web Part Page file itself and the specific set of Web Parts or lists, and files, to include on the page. The file is encapsulated inside the File element as a child element of the module.

You must declare modules as an element within the Configuration element. You can also use modules outside the configuration to define the URL of any file to include as part of the definition.

The following is an example from the ONET.XML that shows the use of modules:

<Module Name="Default" Url="" Path="">
<File Url="default.aspx" NavBarHome="True">
<View List="104" BaseViewID="0" WebPartZoneID="Left"/>
<View List="106" BaseViewID="0" WebPartZoneID="Left"
WebPartOrder="2"/>
<AllUsersWebPart WebPartZoneID="Right"WebPartOrder="1">
<![CDATA[
<WebPart xmlns=http://schemas.microsoft.com/WebPart/v2
xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image">
<Assembly>Microsoft.SharePoint, Version=11.0.0.0,
Culture=neutral,
PublicKeyToken=71e9bce111e9429c</Assembly>
<TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart
</TypeName>
<FrameType>None</FrameType>
<Title>Site Image</Title>
<iwp:ImageLink>/_layouts/images/homepage.gif
</iwp:ImageLink>
</WebPart>
]]>
</AllUsersWebPart>
<View List="103" BaseViewID="0" WebPartZoneID="Right"
WebPartOrder="2"/>
<NavBarPage Name="Home" ID="1002" Position="Start">
</NavBarPage>
<NavBarPage Name="Home" ID="0" Position="Start">
</NavBarPage>
</File>
</Module>

Note   HTML definitions do not allow for nested <CDATA> tags. However to work around this, you can remove the inner tag and use HtmlEncode on its content.

The URL attribute is required and designates the main file to execute for the module. For example, the URL could specify a Web Part Page such as default.aspx, or a *.dwp file for a specific Web Part. Inside the Module element, you can include Web Part definitions and placements inside a Web Part zone. The previous example specifies a single image Web Part displayed in the right Web Part zone.

You can also specify whether to display a module in the top navigation area of a page as well as placement in the Web Part zones of a page. In the previous example, views and Web Parts in the module are displayed on the Home page. After a Web site is created, it includes whatever files are specified through this module.

Field Definitions Using SCHEMA.XML

The SCHEMA.XML file defines the views, forms, and any special fields for a list. To customize a list with custom views, you can modify the SCHEMA.XML file and add a field to the list definition.

To add a field to a list definition

1. Go to the following directory:

   Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server
       Extensions\60\TEMPLATE\1033\Custom_Site_Template\LISTS
       

   Each subfolder represents a specific list.

2. Open the subfolder for the list you want to customize.
3. Open the SCHEMA.XML file using a text editor such as Notepad.
4. In the Metadata section of the file, find the Fields element that contains the definitions of each field in the list type. You can add a new field under the Fields element as follows:

   <Field Name="EmployeeID" DisplayName="Employee ID" Type="Number"Required="TRUE"
       Description="Enter the ID from your employee badge."/>
       

For more information, see "Creating a List Definition" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).

Customizing the Toolbar for a List

To customize the toolbar for a list, you need to make changes to the Toolbar element within the SCHEMA.XML file for the list. To add a new link to the toolbar, for example, you can copy an existing definition for a link and then modify it. This maintains the nesting of tables that is used for displaying links and ensures that the appearance of the link you add is consistent with the other links.

The following example adds a link on the toolbar of a list to a document that is contained in the Shared Documents folder.

<tr><td style="padding-left: 2px;padding-bottom: 2px" width=100%>
<table border=0 cellpadding=0 cellspacing=0 width=100%>
<tr><td width=100% class="ms-unselectednav" colspan=2>
<table cellpadding=0 cellspacing=0 border=0><tr><td valign=top>
<img src="../../_layouts/images/rect.gif">&nbsp; </td>
<td><A  HREF="]]></HTML><HttpVDir/>
<HTML><![CDATA[/Shared Documents/MeetingNotes.doc">]]></HTML>
<HTML>Type Conversions</HTML><HTML><![CDATA[</A></td></tr></table>
</td></tr></table>
</td></tr>

The example shows the toolbar link nested within three tables. The two tables in the example are contained within opening and closing <tr> and <td> tags that belong to a third table, which serves as the frame for containing all the links in the toolbar.

The CAML HttpVDir element, which returns the root directory of the current subsite, constructs the complete path for the URL.

When a new list is created based on this template, a link to a MeetingNotes.doc file appears in the toolbar.

Customizing Portal Areas Using Templates

You can select an area template to use when creating an area in SharePoint Portal Server. Area templates are site definitions that also consist of multiple files with a parallel structure to the site definitions in Windows SharePoint Services. They are stored in the following location:

Local_drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\60\template\1033

An area template can include:

• A site home page
• Lists for the site
• Document libraries

The default naming convention for area template directories starts with the prefix SPS. The following table lists the template and the area it maps to.

Table 3. Area templates

Template	Maps to
SPS	Home
SPSBWEB	To create bucket Web sites
SPSCOMMU	Communities
SPSMSITE	Site Registry
SPSNEWS	Subareas under News
SPSNHOME	News Home
SPSPERS	MySite
SPSTOC	Topics Home
SPSTOPIC	Topic

To create area templates based on existing definitions

1. Copy and paste an area template folder (such as SPSCOMMU) and rename it, for example, SPSMyTemplate.

   Note   The new template name must begin with SPS.

2. Leave the default WEBTEMPSPS.XML file, and create a new one, such as WEBTEMPMySPS.xml, for the new template.
3. Optionally, you can create additional lists, either as described earlier in this article, or as described in "Creating a List Definition" (Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK)).
4. In the new template folder, modify ONET.XML to add Web Parts and lists the same way you modify a SharePoint site. You can also modify default.aspx to suit your needs.
5. Reset IIS to have the changes take effect. The new area template should appear in the area template picker on the Create New Area page.

Specifying a Template for Subareas

When you change a template associated with an area, you can specify a template for its subarea.

To specify a template for a subarea

1. For any area you want to change, under Actions, click Manage Portal Site.
2. For the area of your choice, in the Edit drop-down list box, click Edit.
3. Click the Page tab. In the Subarea Templates section you can choose one of the following:
   • Subareas can use any template (in the list of available area templates)
   • All subareas will use the following template (which you choose from the drop-down list)

Template Inheritance

An area can inherit its template from its parent area, from a page, or from the original template (see Figure 3).

To set a template for the current area

1. For any area you want to change, under Actions, click Manage Portal Site.
2. For the area of your choice, in the Edit drop-down list box, click Edit.
3. Click the Page tab. In the Area Templates section you can choose one of the following:
   • This area uses the same template as the parent area   Use the parent template to render this area.

     Note   The area uses the parent's template and the default SharePoint lists, but portal listings are still sourced from the current area.

   • This area uses the template originally specified for this area   Use the template specified at area creation time to render the area. Picking this option reverts the template to the one used when the area was created.
   • This area uses the following page as a template   You provide any URL here that you want. You can add the relative URL to another area to use that area's template, for example, /topics/default.aspx. Or you can create your own page, and provide the URL to that page. Regardless of what you type here, if the page used has a Portal Listing Web Part on it, by default it uses the listing information from the current area as its source.

 

Figure 3. Template inheritance (Click picture to see larger image)

By default, a subarea inherits its parent area's security settings but you can change its security settings by going to the area and under Actions, clicking Manage Security. Similarly, you can add users and modify permission rights. You can also change site groups permission on the current area. Modifying the security setting for the subarea breaks its security inheritance. You can re-establish the inheritance to its parent by selecting the Inherit permissions from the parent area link on the current area.

Editing Existing Area Templates

An area template essentially consists of a style sheet reference, registration of various components/controls to run on the page, standard HTML markup dictating layout, zones (containers for Web Parts), Web controls (for example, navigation elements), and in some cases, instances of Web Parts. The primary file is default.aspx, located in the root directory of each template folder. Building from copied templates is possible for all templates, with the exception of the site Home page, the Event Calendar and the Sites Directory template. Because the site Home page, Event Calendar, and Sites Directory have already been created using the SPS template, it is not possible to re-provision the site using alternate templates. You must alter the default template to modify the home page look and feel. If you attempt to create a custom Sites Directory template, delete the existing Sites Directory page, and create a Sites Directory page based on a new template, you may cause many functional problems, as the new Sites Directory page would be located at a /C*/ address. It is more efficient to edit the Sites Directory directly from the default template, leaving the location of the Sites area at (/SiteDirectory/). When you create a new template, you must add it into the system to make available for content creators to select.

To add a new template to the system

1. Note the name of the new template folder (such as SPSTOPICMSW).
2. In a text editor such as Notepad, open WEBTEMPSPS.XML located at \\FE_Server_name \c$\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\XML.
3. Within the <Templates> node, copy and then paste an existing <Template> node. For example:

   <Template Name="SPSNEWS" ID="32">
       <Configuration ID="0" Title="News area template" Type="0" Hidden="TRUE"
       ImageUrl="../images/spshome.gif" Description="Area Template."></Configuration>
       </Template>
       

4. Replace the Name property with the name of the new template folder.
5. Give the new template a unique ID.
6. Replace the Title, ImageUrl, and Description properties as appropriate.
7. Save the file, and then restart IIS.

   The template is now available as a new item in the Template menu on the Create Area form.

Figure 4. Area Template menu showing new template

As mentioned earlier, a template essentially consists of a style sheet reference, registration of various components/controls to run on the page, standard HTML markup dictating layout, zones (containers for Web Parts), Web controls (for example, navigation elements) and in some cases, instances of Web Parts.

Modifying a template simply involves opening the template of choice in a text editor, making the desired changes, and saving the file. No IIS reset is required.

Tips on Making Templates

If you foresee making substantial changes to templates, make a new template instead of modifying an existing template. This will guarantee you freedom from upgrades and conflict with new SharePoint Portal Server code. Do not put your templates into the same folders as existing templates or call them the same name, because during an upgrade, your code can be overwritten.

Make a "mother template" page—you can create zones of different sizes that take up different column percentages of the width of the page, and use them as quick starting points for your own templates.

Guidelines for Using Templates and Site Definitions

There is more than one way to tailor your site to your exact needs. When you customize a site, be aware of several key factors that can help you determine whether to choose templates or site definitions.

The amount of modification involved in changing the site can be a significant factor. The default site templates are limited in design and variety, designed primarily for an intranet portal rather than a corporate Web presence on the Internet. If you need a site design that differs significantly from the default sites, then a new site definition may be your appropriate choice.

Typically, site navigation is consistent across a deployment, however, site managers typically want some control over the design and layout of their site. In some cases, control over relatively minor aspects of site rendering (logos, menus, means of navigation, and so on) can give individual sites a unique look and feel while maintaining consistency across a larger deployment. In these cases, site templates might be your appropriate choice.

When to Use Site Definitions

Customizing portal sites and other SharePoint sites using site definitions is most appropriate for third-party developers and server administrators. Because site definitions require access to the file systems of the Web server, server administrators must always be involved in the deployment of site definitions. If you are modifying areas of a portal site, then you will need to use site definitions.

Although deploying a site definition requires more work, site definitions typically perform better when cached on the file system instead of in the database. In addition, you can achieve a finer level of customization by directly editing all the schema files and not depending on the existing site definition as a site template does. Also, if you want to introduce new file types, view styles, and drop-down edit menus, you need to edit the schema files that make up the site definition.

Custom site definitions are version and upgrade independent. Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.

However, there is no easy way to modify site definitions once they are deployed. There is always the possibility of breaking existing deployed sites derived from the site definition once you modify an existing site definition. You can only add to the site definition once it is deployed.

When to Use Site Templates

Site templates, compared to site definitions, are easy to create and deploy. You can make all customizations through the user interface or FrontPage 2003. In addition, you do not need to be a server administrator on the Web server to create and deploy site templates. You can modify a site template without affecting existing sites created by the template. Deployment is simple because template data is stored centrally in the configuration database.

Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance. Templates in the database are compiled and executed every time a page is rendered. Windows SharePoint Services does some performance optimization whereby it stores templates on the local Web server and a copy (or "ghost") of the page in the configuration database. However, you can easily prevent Windows SharePoint Services from using a copy of the page by using Web Folders or FrontPage to open, modify, and save it. From this point forward, the database is used to render the page. Preventing Windows SharePoint Services from using a copy of a site page will cause the page to stop picking up changes from the site definition files, so if you want to keep a consistent look across the entire portal and only want to modify the site definition files, then don't prevent this optimization. Rendering pages from the database will result in an initial performance penalty.

Site templates only work on SharePoint sites that are not portal sites (not based on the SPS templates). Furthermore, site templates are not ideally suited for a development environment. In effect, they are still customizations of a site definition. If the site definition does not exist on the server, the site template fails.

Typically, because of these issues, site templates are not as efficient as site definitions in a large-scale environment.