Customizing Content

Out of the box, SharePoint has a certain appearance. It has a set of colors, fonts, page layouts, and navigation features that are built into the default site templates provided. This look and feel is designed to work well for general purpose intranet sites, but it is somewhat bland and utilitarian looking. Fortunately, SharePoint supports dramatically customizing this appearance with a variety of tools. The process of changing the site-wide look and feel of a site is referred to as branding the site.

Applying your own brand to a SharePoint site is done in different ways, depending on the desired changes to be made. Changing the default colors and fonts used on the site is done using themes. Changing the overall page layout of the site is done using master pages. Changes to the site's navigation features are also typically done through master pages by embedding a set of custom SharePoint controls that render menus in the web browser.

In this section, we will describe the branding process at a high level as it relates to deploying application components that relate to branding. For a more detailed description of the branding process, see Chapter 11.

Master Pages

Master pages are a feature of ASP.NET that allows several pages to inherit their structure and other common elements from a shared source file. This enables the maintenance of these elements in a central location. A master page typically contains the HTML tags that define the layout of a page with “content areas” designated for page-specific content. Master pages can also include web controls that are common to all pages, like navigation menus, and often common CSS links as mentioned above.

Figure 12-6 shows a typical SharePoint page. The rectangles indicate where the customizable content areas might be. In this case, many of these areas have been provided with default content such as navigation menus. The author of a page using a tool such as Visual Studio or SharePoint Designer can replace this default content with content specific to the page.

Figure 12-6. Structuring a page with master pages

SharePoint extends the functionality of ASP.NET master pages by managing the relationship between the master pages and the pages that use them. A SharePoint site can be associated with a new master page, thereby completely changing its layout and appearance.

Master page files are stored in a Master Page Gallery. The Master Page Gallery is created automatically in all SharePoint sites. It is a best practice to limit yourself to using only the root master page gallery unless you have good reason to do otherwise. Having custom master page files spread throughout a site collection can quickly become unmanageable.

It is also a good idea to limit the number of users that can create, edit, and apply master pages in the gallery. This is done by setting the permissions on the gallery itself and the permissions on the site. You should remove or restrict access to any master pages that are not standard in your environment. This will prevent them from being used by mistake.

Themes

To those familiar with themes from previous versions of SharePoint, the themes in SharePoint 2010 will seem entirely new. Microsoft Office 2010 contains a theming engine that has been incorporated into the various Office applications and into SharePoint.

Specifically, a theme is now a much more lightweight concept than it was in the past. Instead of referring to a collection of cascading style sheets (CSS) and images, in Office 2010 a theme is just a small set of font and color declarations as shown in Figure 12-7. These are typically stored in a file with a THMX extension. When a theme is applied to a SharePoint site, a set of standard CSS files is processed by the theming engine to create the actual CSS files sent to the user's web browser. Unlike in previous versions, these standard CSS files should not be tampered with. Instead, if additional CSS definitions are needed, they should be placed into separate files that are applied outside of the theming engine. This process is discussed in Chapter 11.

Figure 12-7. An Office 2010 theme definition

Theme files are stored in the Theme Gallery, which is a special library that exists in each SharePoint site collection. There is a default set of themes that appear by default in the Theme Gallery. An organization that intends to control its brand should start by removing or restricting access to the theme files in this gallery. A common technique would be to place one approved theme in the gallery that must be used by all sites. Additionally, the permissions to edit and create themes should be restricted to prevent users from creating their own themes. This will ensure that the organization's standards are maintained.

In some cases, more than one theme may need to be left in the Theme Gallery to allow for different brands or types of sites to be created. Different divisions within a company may have their own brands that need to be supported. Also, public-facing sites may use a rigidly-defined theme whereas internal-facing or extranet sites may have more flexibility. The key is to remember that the Theme Gallery exists at the site collection level. Areas of the site that require different sets of themes are probably good candidates for being in separate site collections.

An organization's themes are typically set by a design or marketing department. Themes can be created using an Office application like PowerPoint 2010 and exported to THMX files. Theme files can be uploaded to the gallery using the web browser or as part of a solution package created by a developer. The choice depends on how the themes will be managed and by whom. If the themes will be managed by a non-IT department, they will usually deploy it using the web browser. An application development team will generally use a solution package to deploy custom themes.

There are times when the standard CSS files provided by SharePoint need to be extended. In this case, there are several options for adding additional style information to a page. Style tags can be added to the master page or the content areas of the individual pages. However, this can result in a site that is difficult to maintain since all of the style information is not in one place.

A better solution is to create separate CSS files and deploy them to the site. SharePoint contains a control called CSSRegistration which is designed to add custom CSS files to the set of files provided by SharePoint. This control can place a given file reference before or after other style sheets in the page to create the desired precedence order for the styles contained within it. The CSS files themselves can be deployed using a solution package or they can be placed on the site as content files. The CSSRegistration control is typically embedded in the site's master page.

There are additional ways to provide styles to your site that only become available when using publishing sites.

Publishing

The SharePoint publishing feature is used to create a more controlled environment for managing important content. This type of feature is often referred to as Web Content Management. An authorized user can edit a publishing site's content and submit it for approval.

Publishing sites differ from non-publishing sites in the types of controls that are available. This can be very useful for governing the creation and approval of content.

• Content changes on a non-publishing site are made visible to all users as soon as they are saved. Publishing site changes are not visible until they are approved.
• Content on a publishing site can be scheduled to appear or disappear at an arbitrary time in the future.
• The approval process can be customized using SharePoint's workflow engine.
• Publishing sites have additional functionality supporting style sheets, navigation, and controlling the master pages applied to the site.
• Content changes can be staged in a separate environment and migrated to the production farm using content deployment paths. This prevents unauthorized or unreviewed changes from being inadvertently exposed on a public-facing web site. Complex topologies of authoring, staging, and production servers can be supported.

Publishing site pages contain an additional level of structure called a page layout. Layout pages are similar to master pages but they enable rich content–editing and publishing by non-technical users. Layout pages are stored in the master page gallery. As shown in Figure 12-8, the content is built up in layers with the page layout in the middle. In the case of a publishing site, the content applied to the page layout is handled more like data fields than like HTML or Web Parts.

Figure 12-8. Publishing vs. collaboration page construction

Publishing sites are most often used for non-collaboration sites. The restrictions placed on the creation and approval of content makes them ideal for public-facing web sites and corporate- or division-level pages within a company's intranet. Non-publishing sites are best used for sites that manage projects and exchange information informally.

Site Templates

One of the best ways to encourage adherence to standards is to make it easy. That makes site templates a great place to start. When any user creates a new site, it will always be based on one of the available site templates. This will create a predefined set of lists, libraries, master pages, and even content that will be available to the users immediately. By creating a set of standard templates for your organization, you can help users create consistent sites.

A site template in SharePoint 2010 is a solution package file (.wsp) that contains the definition of the contents of a site when it is created. The easiest way to create a site template is to save an existing site as a template using the Save Site as a Template option on site settings. SharePoint packages all of the lists, libraries, forms, workflows, pages, and (optionally) content items into a single file in the Solution Gallery. As we will discuss in Chapter 13, the solution gallery is used to hold solution packages that have been deployed to the local site collection.

A site template can be customized using Visual Studio. The developer can download the template file and import it into a new Visual Studio project. This makes all of the artifacts that were packaged into the template available for editing. Once the customizations are completed, the project can be recompiled and redeployed into the solution gallery. In this way, the organization can create the precise site templates desired.

Site templates have some limitations, however. There are certain items within the original site that are not reflected in the template's solution file.

• Customized permissions within the site are not retained.
• Running workflow instances and any associated tasks are not stored as content in the template.
• Certain types of field values are not retained including people/group fields and managed metadata.

Site templates can also only be created when using certain types of sites. “My Sites” and publishing sites depend on items that cannot be stored to the template file and therefore these types of sites are not supported for saving as a template. Site templates for these sites can still be created but only using a development tool such as Visual Studio.

Because site templates are stored in the solution gallery, the ability to create and use them is controlled by the solution gallery as well. Once created in the solution gallery, a site template is available to all users that have the permissions necessary to create sites in the site collection. To hide a template from end users it is necessary to turn on the publishing feature in SharePoint Server. This adds an option on the Site Settings page called Page Layouts and Site Settings. Ironically, turning on publishing, even on a site based on a non-publishing template, will prevent the site itself from being saved as a template. Clearly, careful planning is important when determining the site templates that will be allowed in your environment.