SharePoint 2010: Customize SharePoint content
SharePoint includes a handful of tools for customizing site content you can use to ensure consistency with corporate standards.
Steve Wright and Corey Erkes
Adapted from “Pro SharePoint 2010 Governance” (Apress)
SharePoint has a certain appearance right out of the box. It has a set of colors, fonts, page layouts and navigation features built into the default site templates. This look and feel is designed to work well for general-purpose intranet sites, but can sometimes feel bland and utilitarian. Fortunately, SharePoint has a number of tools with which you can dramatically customize its appearance. The process of changing the site-wide look and feel is referred to as branding.
You can apply your own brand to your SharePoint sites in different ways. You can change the default colors and fonts on the site using themes, or change the overall page layout using master pages. You can also change the site’s navigation features using master pages when they’re embedded with a set of custom SharePoint controls that render menus in the Web browser. Here’s a look at how you can apply these design components.
Master pages
Master pages let several pages inherit their structure and other common elements from a shared source file. This lets you maintain these elements from 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 common to all pages, such as navigation menus and common CSS links.
SharePoint extends the functionality of ASP.NET master pages by managing the relationship between the master pages and the pages that use them. You can have a SharePoint site associated with a new master page, thereby completely changing its layout and appearance.
Your master page files will be stored in a Master Page Gallery, which is created automatically in all SharePoint sites. You should 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’s also a good idea to limit the number of users authorized to create, edit and apply master pages in the gallery. You can do this by setting specific permissions on the gallery itself. You should remove or restrict access to any master pages not standard in your environment. This will prevent people from using them by mistake.
Themes
If you’re familiar with themes from previous versions of SharePoint, the themes in SharePoint 2010 will seem entirely new. Microsoft Office 2010 has a new “theming” engine that has been incorporated into the various Office applications, as well as SharePoint.
Specifically, a theme is now much more of a lightweight concept than it was in the past. Instead of referring to a collection of CSS files and images, in Office 2010 a theme is just a small set of font and color declarations. These are typically stored in a file with a THMX extension. When you apply a theme to a SharePoint site, the theming engine processes a set of standard CSS files to create the actual CSS files sent to the user’s Web browser.
Unlike in previous versions, you shouldn’t tamper with these standard CSS files. Instead, if you need additional CSS definitions, place them into separate files applied outside of the theming engine.
Theme files are stored in the Theme Gallery, which is a special library in each SharePoint site collection. There’s a default set of themes in the Theme Gallery. If your organization intends to control its brand, 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 used by all sites. You can also restrict permissions to edit and create themes to prevent users from creating their own themes. This will ensure your organization’s standards are maintained.
In some cases, you might need to leave more than one theme in the Theme Gallery to allow for creating different brands or types of sites. Different divisions within a company may have their own brands they need to support. Also, public-facing sites may use a rigidly defined theme, whereas internal-facing or extranet sites might have more flexibility.
The key thing to remember is that the Theme Gallery exists at the site-collection level. Areas of the site that require different sets of themes are probably good candidates to store in separate site collections.
Your organization’s themes are typically set by a design or marketing department. You can create themes using an Office application such as PowerPoint 2010 and export them to THMX files. You can upload theme files to the gallery using the Web browser or as part of a solution package your developer creates. This choice will be driven by how you plan to manage the themes. If a non-IT department will be in charge of managing your themes, it will usually deploy them using a Web browser. An application development team will generally use a solution package to deploy custom themes.
There are times when you need to extend the standard CSS files provided by SharePoint. In this case, you have several options for adding additional style information to a page. You can add style tags to the master page or content areas of the individual pages. However, this can result in difficult site maintenance because all of the style information won’t be 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.
You can then deploy the CSS files themselves using a solution package or by placing them on the site as content files. The CSSRegistration control is typically embedded in the site’s master page.
Publishing sites
Another way to provide styles to your site is by using publishing sites. The SharePoint publishing feature creates 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 useful for governing the creation and approval of content:
- Content changes on a non-publishing site are visible to all users as soon as they’re saved. Publishing site changes aren’t visible until they’re approved.
- Content on a publishing site can be scheduled to appear or disappear at an arbitrary time in the future.
- You can customize the approval process in a publishing site using the SharePoint workflow engine.
- Publishing sites have additional functionality to support style sheets, navigation and controlling the master pages applied to the site.
- You can stage content changes in a separate environment and migrate them to the production farm using content deployment paths. This prevents unauthorized or unreviewed changes from being inadvertently exposed on a public-facing Web site. This can support complex topologies of authoring, staging and production servers.
Publishing site pages contain an additional level of structure called a layout page. 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. 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.
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 compliance easy. Site templates are 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 creates a predefined set of lists, libraries, master pages and even content. 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 site contents when you first create the site. 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 the Site Settings page.
SharePoint packages all of the lists, libraries, forms, workflows, pages and content items (if desired) into a single file in the Solution Gallery. The Solution Gallery holds solution packages deployed to the local site collection.
You can customize a site template using Visual Studio. Developers can download the template file and import it into a new Visual Studio project. This makes all the artifacts packaged into the template available for editing. Once your customizations are complete, you can recompile and redeploy the template into the Solution Gallery. This way, you can create the precise site templates your organization requires.
Site templates do have some limitations, however. There are certain items within the original site that aren’t reflected in the template’s solution file:
- Customized permissions within the site aren’t retained.
- Running workflow instances and any associated tasks aren’t stored as content in the template.
- Certain types of field values aren’t retained, including people and group fields and managed metadata.
You can only create site templates when using certain types of sites. My Sites and publishing sites depend on items that you can’t store to the template file. Therefore, these types of sites aren’t supported for saving as a template. You can still create site templates for these sites, 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 permissions 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, you have 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 which site templates you’ll allow in your environment and who will have access to those templates.
.jpg "Steve Wright")
Steve Wright is a senior manager in business intelligence management (BIM) for Sogeti USA LLC in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.
.jpg "Corey Erkes")
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He’s also one of the founding members of the Omaha SharePoint Users Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.