Creating a SharePoint branded Web site that is consistent across the entire SharePoint Server 2007 farm requires making changes to the files stored in the SharePoint server’s 12 hives. Because SharePoint Designer 2007 cannot open pages directly from the file system, these pages must be edited in some other way. For many of these files, a simple editor like Notepad.exe can be used, but Visual Studio 2005 provides the best environment for these files. Using Visual Studio 2005, it is possible for you to create all of the files necessary to implement a custom brand, including master pages, layout pages, CCS, and JavaScript files. But more importantly, Visual Studio 2005 allows the creation of features, solutions, and program code that will automate the deployment of these components across an entire farm. Branding files created using SharePoint Designer 2007 are customized and stored at the site level, but files stored in the 12 hive are available to all site collections. The key to their use is developing strategies that will deploy these files from the 12 hive as uncustomized copies to the sites in the farm. Because uncustomized files always get their source from the original file in the 12 hive, this allows updates to be made simply by updating the original file stored in each server’s 12 hive.
Site definitions provide the blueprints used to provision SharePoint Product and Technologies sites; they are the instructions that orchestrate site creation. You can use site definitions for branding and customization in two distinct ways: by associating features with existing site definitions or by creating custom site definitions.
Site definitions are stored on the file system in the 12 hive and are a suitable method for globally deploying customizations. When a site is provisioned, a copy of the site definition is not made in the content database; rather, a pointer is created that points to the underlying definition in the 12 hive. If the site definition is deleted from the 12 hive, the sites provisioned from it will no longer function.
In addition to the site definition being stored on the file system, a site definition’s resources—such as master pages, layout pages, CSS, and JavaScript files—can reside on the file system. As long as the site definition’s resources are not customized, such as with SharePoint Designer 2007, changes made to those resources on the file system will be globally reflected in all sites that were provisioned from the site definition. This provides a much more manageable mechanism for consistently maintaining enterprise customizations than the process used by SharePoint Designer 2007, which is limited in scope to either sites or site collections. In the event a file system resource, such as a master page, is opened from a site using SharePoint Designer 2007 and then altered, any future changes made to the file system version will not be reflected in the site that was edited. If site definitions are used for the purpose of referencing resources located on the file system, it is important to limit any modification of sites that would result in file system resources being customized and copied to the content database.
Site definitions also allow a wide array of customizations, including the following:
Features, scoped at either the site collection or site level, can be provisioned with the site, and features suitable for only the top level of a site can be limited to only the top level.
List and document templates can be made available when the site is created from the custom site definition.
Instances of lists and document libraries can be created.
Master pages and layout pages can be added to the site’s Master Page Gallery with the pages actually residing on the file system and referenced by all sites created from the site definition.
Web parts can be added to the default page of the site and will be immediately available when the site is created.
An external CSS resource, named AlternateCSSUrl, can be modified after the site is provisioned and will affect all sites created from the site definition. Although it is possible to set the AlternateCSSUrl property of a site after the site is provisioned, it is much simpler to do so at creation.
An external JavaScript resource, named CustomJSUrl, can be modified after the site is provisioned and will affect all sites created from the site definition. Unlike the AlternateCSSUrl resource, the CustomJSUrl can only be set at creation via a site definition.
Note
Because adding CustomJSUrl or AlternateCSSUrl values to a site definition cannot affect existing sites already provisioned from the definition, always specify a value for both the CustomJSUrl and AlternateCSSUrl. If their functionality is not immediately required, then both files can be created containing only comments that describe their intended purpose and the site definition with which they are associated.
Although custom site definitions provide a tremendous resource for branding and customization, you must be aware of certain limitations. First, Microsoft has stated explicitly in Knowledge Base article 898631 that modifying site definitions after they have been deployed and sites provisioned based on them is not supported. Second, because site definitions are essentially the blueprints that detail how to create a site, altering a site definition after sites have been provisioned from it would not positively affect sites even if it was supported. These limitations will severely hamper your ability to maintain, support, and extend site definitions. There is a very powerful means to mitigate them by using features in conjunction with site definitions.
Feature site template association, often referred to as feature stapling, allows a feature or features to be automatically run whenever a site is created from a given site definition, even the default Microsoft site definitions. Feature stapling does not affect sites that have already been provisioned, but it does provide a ready means of extending functionality to new sites provisioned from the associated site definition. Feature stapling provides a powerful way to maintain site definitions without modifying the site definition itself. By creating a minimalist site definition that implements as much of its functionality as possible through feature stapling, you can add or remove functionality from the site definition by altering the feature associated with it, which does not contravene Microsoft’s site definition policies. Using this approach to add functionality requires that the stapled feature be modified or call other features as dependencies. If it becomes desirable to remove functionality, the appropriate features can be modified or no longer called as dependencies. Although altering the site template’s associated feature will not automatically standardize existing site definitions, using this approach will make doing so easier because the alterations required will largely consist of activating and deactivating the appropriate features.
Note
Site definitions should be implemented as lightweight as possible and feature site template association used for as much functionality as possible.
There are some things that will require a custom site definition and should be included within one. These include any Web parts that will appear on the Welcome page, a custom Welcome page, and implementing sites with variations. Variations, which provide multilingual support in SharePoint Server 2007, provision sites for multiple languages and copy content between them. Because the variation process provisions sites and does not copy them, when a new variation target is created, it will reflect the default site as described in the site definition. It will not automatically provide custom Welcome pages, lists, libraries, documents, or images that are not part of the site definition. Although it would be possible to re-create any resources manually through the user interface, doing so would be a tedious and time-consuming process not suited to enterprise deployment. Therefore, it is generally wise to create a custom site definition when you implement variations so that new variation targets will be created with appropriate content and structure.
There are many ways to specify which master page to use when you render a page in SharePoint. For example, pages in the _Layouts virtual directory reference Application.master directly because it is stored in the same virtual directory. But most pages in SharePoint use one of two replaceable tokens to reference a master page. These tokens are ~masterurl/default.master and ~masterurl/custom.master. Most pages in a SharePoint environment use the first token except for publishing pages stored in a pages document library, which use the second token. In a publishing site, these tokens represent the System and Site Master pages, respectively.
Master pages can be created using Visual Studio, but are most easily created using SharePoint Designer. However, after creation, master pages can be implemented in a custom site definition or through a feature. Because these files will be stored in the 12 hive and only ghosted to the Master Page Gallery of the Web site, any change made to the original file will be picked up the next time the page is refreshed.
The AlternateCSSUrl property of a site can be set within a site definition via the user interface or with object model code. As previously mentioned, the AlternateCSSUrl causes an external CSS resource to be referenced in addition to the base CSS used for the site. By extending and overriding the base CSS, you can modify a site’s look and feel to reflect custom colors, fonts, and images associated with branding.
Visual Studio’s tremendous strength for branding and customization is scope of deployment. Deploying resources, such as master and layout pages uncustomized to the file system, makes them much easier to manage, because multiple sites can reference the same resource and will therefore all reflect changes made to that resource. Unfortunately, unlike SharePoint Designer deployment of content database resources, deploying file system resources is not done automatically by Visual Studio. There is a specific means of overcoming this obstacle—the Windows SharePoint Services Solution Package, often referred to simply as a solution or WSP. A Windows SharePoint Services Solution Package is a SharePoint-specific CAB file that contains a manifest with instructions on how to deploy resources throughout a SharePoint Products and Technologies farm. The Windows SharePoint Services Solution Package is added to the solution store using the STSADM.EXE command ADDSOLUTION. The solution store is a single farm-wide resource that can be managed from either the command line to deploy resources throughout the farm or to specific Web applications. A Windows SharePoint Services Solution Package can be added to the solution store, making it available to operations to be deployed to the appropriate locations at scheduled times.