SharePoint Designer 2007 is the most frequently used tool for creating many of the components involved in branding a SharePoint site. Nonetheless, there are some pages that SharePoint Designer 2007 can’t modify. Because SharePoint Designer 2007 reads and writes its changes to the content database, it can’t change any page or file that is not ghosted to the content database. This includes all of the application pages, which are accessed via the _Layouts directory of a SharePoint Products and Technologies site, because these files are stored in the Template/Layouts directory of the 12 hive. Although typically administrative pages, some pages in the _Layouts directory are frequently used. For example, the File Upload page is stored in _Layouts. Neither these pages nor the master page they use, Application.master, can be customized using SharePoint Designer.
Despite these limitations, the SharePoint Designer 2007 editor is the easiest way to customize master pages, create publishing layout pages, or build custom CSS files. The real challenges when using SharePoint Designer are scalability, deployment, and long-term maintenance. We believe a hybrid approach is a best practice when using SharePoint Designer 2007. Extend the power of SharePoint Designer 2007 by using it in conjunction with Visual Studio to provide farm-scale deployment and simplified maintenance.
Most pages in a SharePoint Products and Technologies site are set to obtain their master page by using a replaceable parameter that SharePoint converts to a URL address at run time. That parameter, ~masterUrl/default.master, will normally point to a master page called default.master that is ghosted from the 12 hive to the Master Page Gallery of the site when the site is created. It is the value of this parameter that is being changed when the System Master page is set on a publishing site. The first challenge involved in editing an existing master page is that most editing tools cannot access SharePoint pages or sites directly because they are stored in the content database and not the file system. For example, although Visual Studio can edit a master page, it cannot load it directly from a URL site address. In fact, there are currently no other HTML editors that can open a SharePoint master page directly from a SharePoint Products and Technologies site other than SharePoint Designer 2007. This fact alone makes SharePoint Designer 2007 a tool that must be considered when you edit or create master pages.
Although the HTML code on a master page is quite complex, it can be edited relatively easily in SharePoint Designer’s WYSIWYG editor. SharePoint Designer can easily perform the following functions:
Restructure the HTML tables, rows, and cells on the page that are being used to control the layout of page elements.
Move content placeholder controls or server controls to different locations on the page to modify the layout of content on the page.
Add additional controls to the master page to customize the functionality of all of the pages in a site.
Modify attributes of server controls to extend their features (e.g., configuring the navigation controls to support dynamic flyout menus).
Attach a specific CSS or JavaScript file to the master page so that it is available for use in all content pages linked to use this master.
There are a few actions that should be avoided. First, be very careful about removing existing controls from the page. Most of them are necessary, otherwise some of the pages built into SharePoint Products and Technologies will stop working. Instead of removing them, the controls should be moved inside an ASP:panel server control at the bottom of the page and the visible attribute set to false. Although still on the page, this effectively hides them from view.
Adding inline C# or VB code to a script tag on the page should also be strictly avoided. SharePoint Products and Technologies runs in a restricted security environment where inline code will not be parsed and compiled on master pages or content pages housed in the content database. Although this behavior can be changed by adding the location of the page to a PageParserPath tag in the web.config file, it is not recommended because this is a security risk. Note that client-side JavaScript is not a security risk and does not require a PageParserPath entry.
The SharePoint Designer 2007 editor also includes several safety net features to improve the editing experience. As previously pointed out, editing the page using SharePoint Designer 2007 will customize the page and disconnect it from the original page stored in the 12 hive. Any page that has been edited and saved by SharePoint Designer in this way will have a blue octagon icon containing a lowercase "i" next to its name. This icon denotes a customized page stored in the content database. In addition to the visible indicator, SharePoint Designer 2007 can quickly roll back the changes if you right-click the file and select Reset To Site Definition from the context menu. Doing this will store a copy of the customized page and restore the original page to its uncustomized state.
With the exception of the increase in maintenance workload caused by the limited scope of customized master pages, SharePoint Designer is the most full-featured editor available for modifying or creating new master pages.
In a publishing environment, SharePoint Designer 2007 is the best editor for creating new page layouts or modifying existing ones. In fact, when you try to edit a page in a publishing site that is based on a page layout, SharePoint Designer 2007 will inform you that these pages cannot be directly edited in SharePoint Designer. It will then give you an option to both launch the browser and edit the content using the user interface or edit the layout page upon which that the page is based in SharePoint Designer.
Once a layout page has been loaded for editing in SharePoint Designer 2007, it will operate like any other HTML page—with two exceptions. First, all HTML content in the body of the page must be encapsulated inside <ASP:content> tags that target a content placeholder on the master page. The other change is a new set of controls in the toolbox where ASP.Net server controls and HTML controls reside. There will be two new categories called Content Fields and Page Fields under the SharePoint Controls group. These content and page fields represent columns in the content type associated with this layout page. Content fields contain content that can be displayed directly on the page. Page fields contain information about the page, such as the author last modified date. This information can also be displayed on the page. Drag either type of field into a content placeholder control in the location the content should appear on the page. To use the controls to collect metadata values when the page is edited but not display that information on the page when not in editing mode, place the controls in an EditModePanel. Authors can add pages and content to pages based on layout pages, but the ability to modify the layout page themselves is reserved for designers.
One of the easiest options for replicating a site with the same look and feel is to turn it into a site template and then use that template to create other sites. This has the advantage of taking all the branding changes made to the site by customizing files in SharePoint Designer 2007 and wrapping them up in a single file with an STP extension. Customized master pages, layout pages, applied themes, custom CSS files, and, optionally, content stored in site lists and libraries are all included in the STP file. This SharePoint Template Package file is then saved to the Site Template Gallery of the top-level site of the site collection. From there, it can be exported to the file system to import it into another site collection’s Site Template Gallery or installed into the SharePoint farm’s central Site Template Gallery using the following STSADM command:
stsadm.exe -o addtemplate -filename <filename> -title <template title> -description <description of the template>
There are only two real limitations to this approach. First, STP files are by default limited to no more than 10 MB in size. Including customized master pages and other content can quickly overrun this limit. This can be overcome by using the following STSADM command to increase the maximum size of an STP file:
stsadm.exe -o setproperty -pn max-template-document-size -pv 20000000
The maximum size should be guided by two considerations: First, if the resulting STP file is to be used in other sites, the size should not be increased above your maximum upload limit. The default limit of an STP file is 500 MB. Also, understand that there is a risk that increasing the STP file size by too much may tempt users to use this as a way to make a quick backup of an existing site. STP files were not intended for this purpose, and their use in this fashion should be discouraged.
The other limitation of this approach is that it must be done before creating other sites. Once new sites have been created, you cannot make changes to them by making changes to the original. STP files are a blueprint for the creation of new sites, but changing the blueprint after the site is created has no effect on existing sites.