Working with Site Templates and Definitions
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
In Windows SharePoint Services, when an end user creates a site through the user interface (UI), he or she does so by selecting one of two possible types of foundations that can define how to instantiate the site:
A site definition configuration (which is a part of a site definition).
A custom site template.
Either type of foundation determines, for example, the lists, files, Web Parts, Features, or settings with which to provision a new SharePoint site.
Site definitions consist primarily of multiple XML and ASPX files stored on a front-end Web server in folders under the \\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE directory.
Custom site templates are stored in the database and are created by using an existing site, with or without its specific content, as a model. This provides a means for reusing sites that you have customized.
Since custom site templates are based on existing sites, at least the first site in any Windows SharePoint Services 3.0 deployment must be founded on a particular configuration within a site definition. A custom site template adds to, but does not repeat, the structural and content information from the original site definition. In some ways, some site templates continue to depend, throughout their lifecycle, on the site definition that is their ultimate foundation. For this reason, Microsoft does not support changing or removing a site definition after sites have been created from it. Such changes may cause sites created from the definition (or created from site templates that are based on the site definition) to stop working properly or may prevent the creation of new sites based directly, or indirectly, on the site definition. For more information about what kinds of customizations of site definitions are supported by Microsoft, see Supported and unsupported scenarios for working with custom site definitions and custom area definitions in Windows SharePoint Services, in SharePoint Portal Server 2003, and in Office SharePoint Server 2007.
In the Windows SharePoint Services 3.0 object model, an SPCustomWebTemplate represents a custom site template. An SPWebTemplate can represent either a site definition (and configuration) or a custom site template.
In Collaborative Application Markup Language (CAML) markup, a site definition is represented by the combination of two things:
A <Template> element in a WebTemp*.xml file in the installation directory, usually c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LCID\XML\, where LCID is the numerical ID of the language/culture such as 1033 for English.
An ONET.xml file in the installation directory, usually c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\site_type\XML\, where site_type is the name of the site definition. So site_type can be "STS," "MPS," "BLOG," "WIKI," "CENTRALADMIN," or the name of a custom type of site.
But such a site definition is really a family of one or more site definition configurations, each of which is represented by one of Template element's child <Configuration> elements. Details of the configuration are stored in a corresponding <Configuration> element in the ONET.xml file.
By contrast, a custom site template is stored as a .stp file in the SharePoint database and is listed in the site templates gallery for the site. You can copy the file to a folder, change its extension to ".cab", and open it.
SharePoint Team Services 1.0 from Microsoft included only one definition for instantiating sites, the "Team Site," but Windows SharePoint Services 2.0 extended the template architecture so that multiple site definitions and templates can be used within a deployment. Windows SharePoint Services 3.0 enhances the Web development platform further by modularizing Features, making it easier to create and apply custom applications. For information about Features, see Working with Features.