Windows SharePoint Services 2.0 Site Definitions and Unghosting

SharePoint sites are different from standard Web sites that you might find on the Internet or on an intranet. Typically, when you create a Web site, you create a file for every page that you want to display. Each page in the Web site has a corresponding HTML page or an ASP.NET page (ASPX). Internet Information Services (IIS) Web sites point to the folder containing the files. But SharePoint sites are different. They are simply rows in a database table storing the metadata about each site, area, or workspace. Each site listed in the Docs table in the contents database contains the setup path to a  Default.aspx file hosted on the file system of the Web server, allowing us to make a single change to one  Default.aspx page that affects every site that uses the page. The  Default.aspx file, along with some other XML files, make up a site definition. The 60 hive is where these site definitions live. Each site definition contains the following folders and files:

• DOCTEMP folder The DOCTEMP folder contains subfolders for each Office application. You will notice a folder for Word, Excel, PowerPoint, FrontPage, InfoPath, Blank Web Part Pages, and Smart Pages. (These have abbreviated names. For example, Excel is XL.) Each subfolder contains the templates that are used in the document libraries to create a document when you click the New Document button. Upon creation of a document library, a default template is chosen and copied from the DOCTEMP\application_name folder and to the Forms folder in the document library. You can view the template file in the Forms folder by using the Explorer view for a document library.

• LISTS folder The LISTS folder contains the list definitions that are used by the site definition. Each list contains a  Schema.xml file and a collection of .aspx pages that are used to view, edit, and create the list items. The  Schema.xml file describes the fields and views that the list will use.

• XML folder The XML folder contains the core Site Definitions File (ONET.XML), STDVIEW.XML, and VWSTYLES.XML. STDVIEW.XML describes the views that you can create, such as Standard View, Calendar View, and DataSheet View. The VWSTYLES.XML files describe the styles that you can apply to each view, such as the Newsletter, Newsletter No Labels, Boxed, Boxed No Labels, Shaded, and Default Views styles.

• Default.aspx file The  Default.aspx file is referred to by the site in the docs table of the content database. This file is responsible for creating the table structure and Web Part zones of a site.

Figure 25-1 shows an image of the 60 hive folder and how you can access it, as well as where to find the site definitions.

Figure 25-1: The 60 hive folder

Note 

The term 60 hive refers to a folder location of the SharePoint Web front-end server. It can be found by browsing to %SystemDrive%\Program Files \Common Files\Microsoft Shared\Web server extensions\60. Also, LCID is an acronym for Local Culture Identifier, and 1033 is the LCID for English (US).

IIS was modified in Windows SharePoint Services 2.0 to look in the Content database for the majority of the files it renders. If you look at the local path for the Virtual Servers Home directory, you will find a Web.config file, but you won't find any .aspx pages. These .aspx pages are accessed by IIS from the Content database. When a site is accessed, IIS looks in the Content database for the relevant site, which then references the  Default.aspx in the site definition in the 60 hive. If you need to create some custom .aspx files or some user controls, you need to create an excluded managed path by using the Define Managed Paths option in the Virtual Server Settings page in SharePoint Central Administration. UserControl Virtual Directories were common in Microsoft SharePoint Products and Techologies 2003 if your developers created user controls that were loaded by a custom Web Part.

Team Sites, Blank Sites, and Document Workspaces are site definition configurations that are stored in the 60\TEMPLATE\LCID\STS folder. Meeting Workspaces-such as Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and MultiPage Meeting Workspace-are all configurations of the 60\TEMPLATE\LCID\MPS folder. STS and MPS contain a  Default.aspx file and a collection of XML files, including the  ONET.XML file, which forms the site definition. Ghosted site is the term used for a site that doesn't actually have its own copy of the  Default.aspx and instead points to the  Default.aspx on the file system of the SharePoint server.

Windows SharePoint Services 2.0 allows each user who has Contributor rights to modify her own personal view of each page, and also modify the personal properties of a Web Part. SharePoint keeps track of these changes by storing them in a Personalization table in the Content database. If the permission has been granted, users who have at least contributor rights can also create their own sites in Windows SharePoint Services 2.0. Site definitions empower users to create sites for themselves through the user interface, meaning they no longer need to ask Web developers to create a site for them.

Unghosted pages are the result of modifying a ghosted, or default, page in Microsoft FrontPage 2003 or any Web-page editing tool that can edit Windows SharePoint Services 2.0-based pages. Unghosting a page means that instead of saving changes to the  Default.aspx file in the 60 hive, a copy of the file is made and stored as a customized page for that site in the content database. Microsoft, therefore, had to address this in SharePoint Server 2007 so that when we upgrade from Windows SharePoint Services 2.0 to version 3.0, the customized  default.aspx pages that are in the Content database that require updating can be updated in such a manner to include the 2007 functionality.

The upgrade action on the SharePoint code base changes the  default.aspx in the site definition, allowing ghosted sites to receive new functionality. If the  default.aspx page is copied and stored in the content database, the unghosted page won't receive the new SharePoint Server 2007 functionality.

Microsoft has provided better ways of customizing sites in Windows SharePoint Services 3.0. Master pages are used across all Web sites, which means that developers can change a master page to effect changes across multiple Web sites from a single location instead of changing each site directly. SharePoint Designer 2007 is the replacement for Microsoft FrontPage 2003. It provides developers and power users with even more tools for customizing their sites, allowing them to perform such tasks as creating and applying workflows, using the Data Form Web Part, and customizing master pages. Although unghosting still occurs, it is less of a problem if the customization results are something you don't like because the site can be reset to its original site definition using the Site Settings option of Reset To Site Definition. Selecting this option will undo all the changes that have been made to the site in a single administrative action. This feature gives us a way to undo customizations that have been committed on the site.

Custom Site Definitions

In this section, you will learn about Windows SharePoint Services 2.0 custom site definitions so that you have a better understanding of how to upgrade them later in this chapter.

A custom site definition is usually created by a developer and involves an understanding of Collaborative Application Markup Language (CAML). The process usually involves heavily modifying XML files. In Windows SharePoint Services 2.0, custom site definitions are created so that you could incorporate the following:

• Custom cascading style sheet (CSS) files

• Additional or modified Web Part zones

• Custom list definitions

• Modified navigation

• Custom Web Parts

• Additional resources, such as ASPX pages

• Changes to the base types of the lists

In Figure 25-2, you can see how a custom list named Targets has been added into the  ONET.XML file so that the Custom List can be created from the Create page in a team site.

Figure 25-2: STSCONTOSOSALES Custom Site Definition ONET.xml file including a Custom List

Making these changes usually involves modifying the  ONET.XML or  Default.aspx file stored in each site definition, but it can also involve deploying extra .aspx pages, CSS files, XML files, and Web Parts.

Custom site definitions are created by copying and pasting an existing site definition, such as STS, to a neutral location and then making changes to the copy. For example, you can copy the STS folder in 60\TEMPLATE\LCID to 60\TEMPLATE\LCID \STSCUSTOM. This avoids overwriting the changes to the contents of the STS folder by Microsoft in the form of a service pack or upgrade. It also preserves the default site definition so that it can be copied to other locations and modified differently for different purposes.

The custom site definition is then made available to the Template Selection page by creating a copy of the WEBTEMP.XML file found in 60\TEMPLATE\1033\XML in 60\TEMPLATE\1033\XML\WEBTEMPCUSTOM.XML. Remember, it is the WEBTEMP.XML file that is responsible for making custom site definitions available to the Template Selection page. You can name it anything, as long as it is prefixed with "WEBTEMP" (without the quotation marks). SharePoint Portal Server 2003 has a similar file called WEBTEMPSPS.XML. Figure 25-3 is an illustration of a WEBTEMP.XML file. You can see the two site definitions that are referred to: STS and MPS. Note that each site definition has multiple configurations.

Figure 25-3: The WEBTEMP.XML file

Real World Using SharePoint Template Packages Instead of Site Definitions

In SharePoint Products and Technologies 2003, creating custom site definitions is a developer's responsibility, and rolling out custom site definitions is often an administrator's responsibility because it involves having access to the server and requires resetting IIS.

Custom site templates (STPs) are often created as an alternative to custom site definitions because they can be created using the SharePoint user interface and are basically a modification to the underlying site definition. The STP file is saved to the Site Template Gallery in the top-level site of a site collection. STP files can be made available globally using STSADM.exe (""C:\Program Files\Common Files \Microsoft Shared\web server extensions\60\BIN\STSADM.exe" -o addtemplate -filename "templatename.stp" -title "templatetitle" -description "templatedescription" ").

Custom site definitions will always perform better than a site template. However, using site templates doesn't involve heavy modification of XML files, and you don't need to be a programmer to create them. If you just want to make a small change to a site but reuse the changes for future sites, a site template can be an ideal solution.

Exploring Windows SharePoint Services 3.0 Site Definitions

In Windows SharePoint Services 3.0, site definitions are now streamlined. Lists, Document Library templates, and View styles are no longer part of a site definition. All these files have now moved to a more centralized location in the 12 hive. List definitions are now features and can be found in the Features folder under 12\TEMPLATE. List pages are in a Pages folder under 12\TEMPLATE, and the DOCTEMP folder is available in 12\TEMPLATE\1033\STS folder, even though the STS site definition itself is stored in the 12\TEMPLATE\sitetemplates folder. Features are reusable components that can be used to roll out list definitions, content types, workflow, custom actions, Web Parts, and even services such as the Excel Server Service. Rather than each site definition having its own copy of all the list definitions, each site definition simply installs and activates the required features for that particular type of site. This leaves a Site Definition folder with just the  Default.aspx file and an  ONET.XML file to form the STS site definition. Figure 25-4 displays some of the features in the FEATURES folder.

Figure 25-4: The FEATURES folder

Some site definitions do contain a LISTS folder. These site definitions include WIKI, BLOG, CENTRALADMIN, MPS, SPSMSITEHOST, SPSREPORTCENTER, SPSSITES, and SRCHCEN. However, site definitions do not duplicate any lists like they did in Windows SharePoint Services 2.0. They just add to the lists that are created as features, avoiding the duplication of files that occurred in Windows SharePoint Services 2.0.

Inside the  ONET.XML file, there are many changes. For example, the NavBars element uses a resource for each navigation bar. The following NavBars element that has been taken from the STS site definition in Windows SharePoint Services 3.0 shows the reference to a resource for each navigation bar:

 <NavBars>   <NavBar Name="$Resources:core,category_Top;"  />   <NavBar Name="$Resources:core,category_Documents;"  />   <NavBar Name="$Resources:core,category_Pictures;"  />   <NavBar Name="$Resources:core,category_Lists;"  />   <NavBar Name="$Resources:core,category_Discussions;"  />   <NavBar Name="$Resources:core,category_Surveys;"  />   <NavBar Name="$Resources:core,category_Sites;"  />   <NavBar Name="$Resources:core,category_People;"  /> </NavBars> 

For site definitions that do have a LISTS folder, as mentioned above, a ListElement exists for each of the additional list definitions. Some Windows SharePoint Services 3.0 site definitions do contain a LISTS folder which is the same as all the Windows SharePoint Services 2.0 site definitions. The ListTemplates element isn't used in the STS site definition, as all of its lists are rolled out using features. The following example is taken from an SPSSITES site definition in Windows SharePoint Services 3.0 and shows where the ListTemplates element registers the sites list, which is a list definition stored in SPSSITES\LISTS:

 <ListTemplates>   <ListTemplate Name="siteslst" DisplayName="$Resources:spscore,SitesOnet_SitesListName;" FolderCreation="FALSE" Type="300" BaseType="0" OnQuickLaunch="FALSE" SecurityBits="11" Description="$Resources:spscore,SitesOnet_SitesListDescription;" Image="/_layouts/images/itgen.gif" />   <ListTemplate Name="Tabs" DisplayName="$Resources:spscore,SitesOnet_TabsListName;" FolderCreation="FALSE" Type="301" BaseType="0" OnQuickLaunch="FALSE" SecurityBits="11" Description="$Resources:spscore,SitesOnet_SitesList_Description;" Image="/_layouts/images/itgen.gif" />   </ListTemplates> 

Note 

You can create features to allow for customization of newly created and existing sites without having to completely create new Site Definition folders. Features are explained in more detail later in this chapter.

The purpose of the DocumentTemplates element is the same in the two versions. When you create a document library, the template that is used to create the library resides in the DOCTEMP folder. A copy of this template is then stored in a folder named Forms in the document library. The following example of the DocumentTemplateFiles element shows how the Wdtmpl.doc template is copied from the DOCTEMP folder in the 12 hive to the Forms folder in a document library and is renamed as part of the process to Template.doc:

 <DocumentTemplateFiles>   <DocumentTemplateFile Name="doctemp\word\wdtmpl.doc" TargetName="Forms/ template.doc" Default="TRUE" />   </DocumentTemplateFiles> 

The STS site definition has three configurations: Team Site, Blank Site, and Document Workspace. Regardless of which of the three configurations you select from the Template Selection page, your site will still use STS. However, each configuration receives different lists and Web Parts. A configuration element is shown below, displaying the use of features to roll out lists and Web Parts:

 <Configurations>   <Configuration  Name="NewWeb" />   <Configuration  Name="Default">   <Lists>  <List Title="$Resources:spscore,SitesOnet_SitesList_Title;" Description="$Resources:spscore,SitesOnet_SitesList_Description;" Url="SitesList"  Type="300">   <Data>   <Rows>   <Row>   <Field Name="Title">$Resources:spscore,SetupMySite;</Field>   <Field Name="URL">~site/_layouts/ mysite.aspx?Redirect=1, $Resources:spscore,SetupMySite;</Field>   <Field Name="TasksAndTools"> $Resources:spscore,SitesList_TopTasks_Text; </Field>   <Field Name="_ModerationStatus">0</Field>   </Row>   </Rows>   </Data>   </List>   <List Name="Tabs" Title="$Resources:spscore,SitesOnet_TabsList_Title;" Url="Tabs" Description="$Resources:spscore,SitesOnet_TabsList_Description;" Type="301">   <Data>   <Rows>   <Row>   <Field Name="TabName">$Resources:spscore,CategoriesTab;</Field>   <Field Name="Page">category.aspx</Field>   <Field Name="Comments">$Resources:spscore,CategoriesTabComment; </Field>   </Row>   <Row>   <Field Name="TabName">$Resources:spscore,CategoriesTab;</Field>   <Field Name="Page">categoryresults.aspx</Field>   <Field Name="Comments">$Resources:spscore,CategoriesTabComment; </Field>   </Row>   <Row>   <Field Name="TabName">$Resources:spscore,TopSitesTab;</Field>   <Field Name="Page">topsites.aspx</Field>   <Field Name="Comments">$Resources:spscore,TopSitesTabComment; </Field>   </Row>   <Row>   <Field Name="TabName">$Resources:spscore,SiteMapTab;</Field>   <Field Name="Page">sitemap.aspx</Field>   <Field Name="Comments">$Resources:spscore,SiteMapTabComment; </Field>   </Row>   </Rows>   </Data>   </List>   </Lists>   <SiteFeatures>   <Feature ID="" />   <!--  Base site feature   -->   <Feature ID="" />   </SiteFeatures>   <WebFeatures>   <Feature ID="">   <Properties xmlns="http://schemas.microsoft.com/sharepoint/">   <Property Key="ChromeMasterUrl" Value="" />   <Property Key="WelcomePageUrl" Value="$Resources:cmscore,List_Pages_UrlName;/category.aspx" />   <Property Key="PagesListUrl" Value="" />   <Property Key="AllowedSubSiteTemplates" Value="" />   <Property Key="AllowedPageLayouts" Value="" />   <Property Key="EnableVersioningOnPages" Value="true" />   <Property Key="EnableModerationOnPages" Value="true" />   <Property Key="EnableApprovalWorkflowOnPages" Value="false" />   <Property Key="RequireCheckoutOnPages" Value="true" />   </Properties>   </Feature>   <Feature ID="" />   <Feature ID="">   <Properties xmlns="http://schemas.microsoft.com/sharepoint/">   <Property Key="IncludePages" Value="false" />   </Properties>   </Feature>   <Feature ID="" />   </WebFeatures>   <Modules>   <Module Name="Default" />   </Modules>   </Configuration> 

In comparison to a Windows SharePoint Services 2.0 site definition, this file is now much smaller and can be changed more easily through the use of features.

Windows SharePoint Services 2.0 Site Definitions versus Windows SharePoint Services 3.0 Site Definitions

Table 25-1 lists some of the major differences between the Windows SharePoint Services 2.0 site definitions and the Windows SharePoint Services 3.0 site definitions.

Table 25-1: Comparison of Site Definitions in WSSv2 and WSSv3
Open table as spreadsheet

Element	Windows SharePoint Services 2.0	Windows SharePoint Services 3.0
$Resources	No	Yes
NavBars element	Yes	Yes
ListTemplates element	Yes	Not STS
DocumentTemplate files	Yes	Yes
BaseTypes	Yes	No
Configurations	Yes	Yes
Modules	Yes	Yes
Features	No	Yes

Other differences between the site definitions include the following items:

• The DOCTEMP folder is no longer stored as part of the STS site definition.

•  Defaultdws.aspx is included in the STS folder beside  Default.aspx. In version 2.0, it was stored as  Default.aspx in a DWS folder.

  Note 

   Defaultdws.aspx is the Document Workspace version of a team sites  Default.aspx file.

• The  Default.aspx file contains less code due to the use of master pages and placeholders. Every  Default.aspx page is based on Default.master or mwsdefault.master, which can be found in 12\TEMPLATE\1033\Global.

Note 

Mwsdefault.master is the master page file for the meeting workspaces.

Upgrading a site definition from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0 requires some work so that you can still incorporate your original customizations and inherit the new features of SharePoint Server 2007. In the next section, you will learn the possible methods of upgrading your site definitions.