Customizing SharePoint Sites and Portals: Using Templates and Site Definitions, Part 2
Dino Dato-on
Jinger Zhao
Microsoft Corporation
May 2004
Applies to:
Microsoft® Windows® SharePoint™ Services
Microsoft Office SharePoint Portal Server 2003
Microsoft Office FrontPage® 2003
Summary: The second of three companion articles. In Customizing SharePoint Sites and Portals, Part 1, you learned ways to customize a SharePoint site and an area; manage users, sites, and templates; change the structure of pages in a site; manage user access; and optimize style sheets. In this article, we provide more details by creating and editing a site using templates and site definitions. Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables, Part 3, provides valuable style sheet class reference tables. (20 printed pages)
Contents
Introduction
Creating Custom Templates
Creating Site Definitions
Using Site Configurations
Using Modules
Field Definitions Using SCHEMA.XML
Customizing Portal Areas Using Templates
Guidelines for Using Templates and Site Definitions
Conclusion
Introduction
Microsoft® SharePoint™ Products and Technologies consists of Microsoft Office SharePoint Portal Server 2003 and Microsoft Windows® SharePoint Services. SharePoint Products and Technologies use Microsoft Windows Server™ 2003 and the .NET Framework. This latest version offers improvements in the customization, development, and deployment of an enterprise portal and team collaboration infrastructure.
Customization is the ability to change the layout, view, content, and site structure for a group of users such as a department or corporation. To help ensure consistency, Windows SharePoint Services and SharePoint Portal Server 2003 enable only Web Designers and Site Administrators full customization privileges for managing the look and feel of a site.
Templates and Site Definitions
There are two ways you can customize SharePoint sites. You can use custom templates or create site definitions. Custom templates enable you to customize a site by using the user interface (UI). For example, you can derive a custom list from an existing list, or create a custom list to use as a list template that Site Administrators can choose from a list of available list templates. Windows SharePoint Services stores all custom templates in the content database. You can customize list and site templates from Top-level Site Administration or by using Microsoft Office FrontPage 2003. For more information about using FrontPage to customize SharePoint sites and portals, see Customizing SharePoint Sites and Portals, Part 1.
Site definitions are composed of multiple files located in the file system of each Web server. Site definitions and templates work together to customize a site. Custom templates are always associated with the site definition on which the template is based. A custom template depends on the base site definition in the file system in order to work. A custom template is the difference between a site definition and the state of the site after a template is generated. The template tracks changes to the site definitions that are stored in the configuration database. This article describes the advantages and disadvantages of using custom templates and site definitions and provides guidance about when to choose one over the other, and how to avoid overwriting custom templates and site definitions when installing product updates.
Creating Custom Templates
Now that we know that custom templates track changes to a SharePoint site definition, we can examine the different types of custom templates. List templates track changes to columns, forms, pages, and optionally, changes to the content associated with a specified list. Site templates track changes to site navigation, Web Parts, lists present on a site, and optionally, changes to the content of a single site. You can save an existing site as a site template.
Note There is a 10 MB quota on the total size of the content you can store in a site template. You can determine the size of site content by going to Top-Level Site Administration, and in the Management and Statistics section, clicking View site usage data.
A custom template is persisted as a file with an .stp extension, which is actually a .cab file that you can rename with the .cab file extension and open in Windows Explorer. This file includes one Manifest.xml file in Collaborative Application Markup Language (CAML) that the server generates as a subset of the Microsoft SharePoint Migration Tool (Smigrate.exe) manifest file format. For more information about SMIGRATE, see "Introduction to Templates and Definitions" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
Let's say that you created a site, customized it by adding lists, events, document libraries, custom Web Parts, and applied a special theme. You want to share this piece of work with other site owners or impose this site template on any subsites. On the Site Settings menu, click Go to Site Administration, and then in the Management and Statistics section, click Save as template. Type a file name using an .stp extension and type a title and description for your site template. You can also select the Include content check box. You save your site as a template in a gallery inside the content database to make it available to other subsites. As long as subsequent subsites are based on the same site definition (for example, on a Document Workspace) and have the identical language of the original site, you can create subsites using this template.
To make the template appear in the list of templates in the Site Creation wizard, you need to export the template to the file system and run the STSADM command tool. To export the template, right-click the template and click Save Target As, and then follow the prompts to save the template. After saving the template to the file system, from a command prompt, type the following:
stsadm.exe -o addtemplate -filename "local_drive:\site_template_file_name.stp" -title "Site_Template_Name"
Note You must reset Microsoft Internet Information Services (IIS) before these changes can take affect. After resetting IIS, the Site_Template_Name template becomes available in the site template list during site creation.
You can also export a list template the same way you exported the site template. However, list templates are available only to the site collection of the site from which you exported.
About Collaborative Application Markup Language
Collaborative Application Markup Language (CAML) is an XML-based language used for defining collaboration objects for a site. In Windows SharePoint Services, CAML defines sites, lists, fields, views, or forms.
CAML essentially has two major types of elements—those for field rendering and schema definition, and those for page rendering. For example, you can use the page-rendering CAML elements when you need to extract the property of a specific field and render it on a page.
You can also use CAML to define tables in the site database during site provisioning. You can use CAML to customize a SharePoint site and in SOAP messaging to Web services in Windows SharePoint Services to interact remotely with a Windows SharePoint Services deployment. Moreover, you can use CAML in script or code that implements members in the Windows SharePoint Services object model. In this case, you pass CAML strings through method parameters, assign them to properties, or return them by methods and properties.
For more information about CAML, see "Introduction to Collaborative Application Markup Language (CAML)" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
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
Copy the existing site template folder in the following location:
Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\lcidFor example copy the site template folder and rename it "TRAINING".
Then copy the WEBTEMP.XML file in the following location:
Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\TEMPLATE\1033\XMLRename 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.
.gif)
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.
.gif)
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
Go to the following directory:
Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\TEMPLATE\1033\Custom_Site_Template\LISTSEach subfolder represents a specific list.
Open the subfolder for the list you want to customize.
Open the SCHEMA.XML file using a text editor such as Notepad.
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"> </td>
<td><A HREF="]]></HTML><HttpVDir/>
<HTML><![CDATA[/Shared Documents/MeetingNotes.doc">]]></HTML>
<HTML>Type Conversions</HTML><HTML><.gif)
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
Note the name of the new template folder (such as SPSTOPICMSW).
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.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>Replace the Name property with the name of the new template folder.
Give the new template a unique ID.
Replace the Title, ImageUrl, and Description properties as appropriate.
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.
.gif)
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.
Conclusion
Whether you are a developer or a site administrator who wants to change the user interface to better suit your requirements, you have a gamut of options for customization. There are no limits to what you are allowed to do when creating custom sites. Understanding how custom templates and site definitions work can help you to tweak the user interface to look the way you want. Custom templates and site definitions are easy to use and relatively safe to modify without making major changes to your deployment or breaking any of the default features of SharePoint Products and Technologies.
For more general information about customization, and how to use FrontPage in customizing, see Customizing SharePoint Sites and Portals, Part 1. For style sheet class reference tables you can use, see Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables, Part 3.
Additional References
Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).