C H A P T E R  7

Managing Publishing Sites

The publishing features of SharePoint Server 2010 provide a sophisticated web content management (WCM) architecture for SharePoint-based sites. Publishing sites use a multilayered page structure that allows for tight control over and efficient maintenance of web content. Pages are created and published based on a common data management and approval workflow. Content can be managed centrally or through a series of content repositories that allow for the staging of content.

In this chapter, you will explore the concepts and procedures used to manage web content via SharePoint’s publishing features. You will examine the security and workflow for publishing content and learn about the construction of publishing sites. You will see the SharePoint features that enable the publishing functionality.

You will learn about the following topics in this chapter:

• How to create web content by using SharePoint’s publishing features
• How to manage the approval workflow
• How to schedule site changes to be applied and withdrawn on a predefined schedule
• How to design the master pages, page layouts, and content pages to produce the desired visual effect and maintenance experience
• The importance of additional publishing features such as navigation, site variations, and content deployment

Exploring the Publishing Process

SharePoint Server 2010 Enterprise’s publishing features provide a complete WCM solution for sites built on the SharePoint platform. When a change is made to a publishing site, it is not immediately visible to all users of the site, as is the case with non-publishing SharePoint sites. Published pages must go through an approval process before they are visible to the site’s general audience. They can also be scheduled for release at a later time.

User Roles and Permission Levels

Publishing sites use the same security mechanisms as any other SharePoint site. When the publishing features are enabled, a set of SharePoint permission levels and groups are created that allow users to perform content editing and publishing tasks.

The permission levels for publishing include the following:

• Approve: Users with this level of permissions can edit and approve published items including pages, documents, and list items.
• Manage Hierarchy: This level allows users to create new publishing sites as well as edit published content.
• Restricted Read: Users with this permission can view published items but cannot access any of the publishing metadata behind them such as revision histories.

These permission levels are deployed to a standard set of roles represented by these SharePoint groups:

• Approver: The members of this group have the right to edit and approve published items including pages, documents, and list items.
• Designer: The Designer role is intended for those users who are responsible for the look and feel of the site. These users create page layouts and other publishing artifacts that control the appearance of the site.
• Site Member (a.k.a. Contributor): Each site has a default group for members of the site. Site members are generally those users who contribute content to the site. They can edit pages and submit them for approval.
• Site Collection Administrator: This role is not deployed as a SharePoint group but is built in to the SharePoint Foundation. In the context of publishing, site collection administrators are responsible for approving changes to page layouts and master pages by default. This is because changes to these files do not affect a single site, but every site in the site collection.

Publishing Workflow Overview

The publishing of content is controlled through a SharePoint workflow that manages the state of each published item throughout its life cycle. In this section, you will examine the flow of content items from creation through final publishing.

Workflow Sequence

Figure 7-1 depicts the typical publishing workflow for a published item.

Figure 7-1. Page publishing workflow

The first step in the process is the submission of the changes by a site member or contributor. This initiates the publishing workflow and assigns a task to a set of designated approvers. By default, this task is assigned to the Approvers group for the site.

Approvers have several actions they can take with regard to the approval task:

• Approve: This action accepts the changes and publishes them to the site.
• Reject: This action rejects the changes and returns the draft to the contributor for possible resubmission at a later time.
• Request change: This action allows the approver to provide feedback to the contributor without terminating the publishing workflow. The contributor can make changes to the item and send the changes back to the approver for review.
• Reassign task: This action transfers the approval task to another user or group. This might be used, for example, when an organization wants to have all changes managed by a central group that is responsible for routing the changes to the correct department for approval.

Once an approver has approved or rejected the changes, the publishing workflow ends. SharePoint maintains a detailed log of all actions taken during a workflow, as you can see in Figure 7-2. This log can be accessed through the Status item on the Publish menu tab for a page.

Figure 7-2. Workflow status and history page

Versioning and Statuses

The most common type of item that is published in SharePoint is a web site page. Other items such as list items, images, and documents can also follow the publishing process, but our examples are pages. Just remember that a page is a type of document, and a document is a type of list item. SharePoint treats all items the same when publishing is enabled and approval is required in the list or library.

Each page in the site has a version history associated with it. the This is a record of each set of changes that the page has gone through over time. A major version is one that has been released to the general user community, or published. A minor version is one that has not been published. A page may go through several minor revisions before being published or republished. Each version has a number associated with it, such as 3.2. The whole number represents the published version, and the decimal represents the draft version. Whole-numbered versions, such as 3.0, are published versions of the page. Other versions are drafts based on the previously published version. A history of all versions of a page can be accessed by viewing the Version History for a page, shown in Figure 7-3.

Figure 7-3. Version History dialog box

As a page goes through the publishing process, it has a different approval status depending on the last action taken with respect to that page. The types of approval status are as follows:

• Draft: A draft version of this page has been created. A draft version can be viewed by users authorized to review drafts depending on whether it is checked in or not.
  • A checked-in draft can be seen by all reviewers.
  • A checked-out draft can be seen only by the user to whom it is checked out. All other reviewers will see the previously checked-in version.
• Pending: When a page is submitted for publishing, its status becomes Pending.
• Approved: Once a draft version is approved, it becomes a major version and its status becomes Approved.

Scheduling Content

By default, when a draft is approved, it becomes visible to site visitors immediately. In some cases, this is not desirable. For example, when preparing the web site content for a new product release, the entire content creation and approval cycle may need to be complete weeks ahead of time. SharePoint’s publishing features allow content changes to be scheduled to appear, and disappear, automatically.

Content scheduling is available only in lists that require content approval and maintain major and minor versions of pages in their version history. These options can be set on the Versioning Settings page for the list or library. Scheduling can be enabled on the Manage Item Scheduling page for the list or library.

When creating content changes, the contributor can set a publishing schedule that includes conditions for starting and ending the publication of the version. Content can be scheduled to be published immediately upon approval (the default) or at a specific date and time in the future.

Content can also be scheduled for removal under a variety of conditions. The item may be configured not to be automatically removed, but instead a reminder can be sent to the page’s registered contact user for review on a periodic basis. Alternately, a specific date and time can be assigned for the version to be automatically removed. An optional notification can be sent to the page’s contact user to warn them of the impending expiration of the page. By default, published changes remain in effect until they are superseded by a later version.

Simple Moderation

While the publishing workflow provides a robust review mechanism, in some cases a full review process is not necessary or desirable. If the group of content authors is the same as the group of content approvers, there would seem to be little point in a full approval workflow. In this case, SharePoint publishing supports a lite publishing process called simple moderation. In simple moderation approval, a member of the Contributors group submits an item for approval, and a member of the Approvers group simply approves or rejects it. There are no workflows or tasks assigned to users in simple moderation.

Publishing Templates

The publishing features of SharePoint are very versatile in that they can be applied to any site or list. By enabling the publishing features and configuring options such as versioning and content approval, the publishing process can be tailored in many ways. Additionally, Microsoft has provided a set of templates to create sites specifically designed for managing published content. This simplifies the configuration of these sites dramatically.

Out of the box, SharePoint provides two templates at the site-collection level. When one of these is used to create a new site collection, publishing is automatically enabled for both the site collection and the root site. By default, only publishing site templates are available for creating new sites under a publishing site collection root site. This default can be altered by the site collection administrator if desirable. The two templates are as follows:

• Publishing Portal: This is a general-purpose publishing site that uses all of the publishing features including workflow. The site contains lists and libraries for pages, reusable content, images, and more. This template is ideal for public-facing Internet sites or internal intranet sites.
• Enterprise Wiki: This template provides a customized wiki authoring environment that includes SharePoint’s publishing features. Unlike a team wiki site, this template requires that content changes be approved.

Once a publishing site collection is created, the following set of site templates can be used to manage content in subsites:

• Publishing Site with Workflow: This template creates a subsite that employs all publishing features including workflow.
• Publishing Site: This template does not enable the publishing workflow. Sites created with this template use simple moderation for approval, as described earlier.
• Enterprise Wiki: This template is designed for creating subsites within an Enterprise Wiki site collection.

Understanding Published Pages

Site pages that appear in publishing sites have a different structure than those contained in nonpublishing sites. In this section, you will examine what makes publishing pages unique.

Anatomy of a Publishing Page

In a nonpublishing site, pages are essentially normal ASP.NET pages that contain two layers: a master page and a content page. The master page contains the markup that defines the structure and general layout of the page. This usually includes headers, footers, menus, and content placeholder controls. The content page is then created by defining content to be placed in each of the content placeholders in the designated master page.

Figure 7-4. Comparative web page anatomy

Publishing pages are based on the same framework as nonpublishing pages, but the content page layer is split into two sublayers: the page layout and the content. A page layout (a.k.a. a layout page) defines the content that goes into the placeholders defined in the underlying master page. The page layout also defines its own controls that act as placeholders to be filled in by the content page.

At first glance, this may seem to be an unnecessary complication of the page structure. Why should adding a third layer make any difference? The answer is found in the mechanism used to deliver the content to the controls in the layout page.

Publishing Content Types

Each page layout is associated with a SharePoint content type. Recall that content types allow us to define the data fields associated with list items in SharePoint. The content types used with page publishing always derive from a base type named Page. These types, creatively called page content types, contain fields that support the publishing and scheduling mechanisms of publishing sites.

The content type for a particular page layout contains fields, in addition to those associated with the Page type, that represent the content that should appear on the site page. As a result, the content changes for a web page are reduced to simple data fields, making them much easier to manage than the HTML and ASP.NET markup that make up a nonpublishing content page.

Figure 7-5. Page content types

Standard Publishing Content Types and Layouts

As a site designer, you can create your own page content types and page layouts or you can modify one of the standard components provided by SharePoint, which are listed in Table 7-1.

Page layouts are not stored in the site but in the Master Page Gallery associated with the site collection. This is important because it changes how page layouts are managed. When a page layout is modified, it affects the entire site collection, not just one site. Therefore, the security and approval requirements for page layouts are more like those for master pages than for ordinary site pages in nonpublishing sites.

Field Controls

Page layouts are composed of three major components: HTML markup, field controls, and web part zones.

The HTML markup that appears in a page layout is simply rendered to the final site page. It is important to remember that the final output from the page must be valid HTML. All HTML in the master and layout pages must be consistent when the final page is rendered.

In Chapter 4, you learned how to use web parts and web part zones in your site pages. The concepts are the same for layout pages. By placing web part zones in your layout pages, you make them available to your site page authors. Remember that because web parts are not stored in your page content type, they are not versioned with the rest of the page.

Field controls are the key to managing content when using layout pages. Field controls are ASP.NET controls that are designed to read and manage data fields in the content page’s underlying content type. Depending on the type of data the field contains (an image vs. rich text, for example), a different field control will be used. In SharePoint Designer, you simply drag the field onto the Page Editor, and the correct field control is created automatically.

The magic of field controls happens when the page is viewed in editing mode in the web browser. In normal page-viewing mode, a field control simply renders the content stored in the page’s data field. In Edit mode, the field control renders an on-page content editor that the user can use to create or modify the content in the field.

A special type of field control is the edit mode panel. This type of field control is visible only in Edit mode. This control allows the page author to update page fields that do not appear directly on the page. A common example is shown in Figure 7.6; the edit mode panel is making the page title available for editing.

Figure 7-6. Field controls in Edit mode

Using Additional Publishing Site Functionality

Beyond the ability to publish web pages and other documents, the publishing features of SharePoint allow users to manage other aspects of publishing web sites. This section introduces these features, but a full exploration of them is beyond the scope of this book.

Navigation

In standard nonpublishing sites, navigation is handled by the global navigation bar across the top and the Quick Launch menu on the left of the page. In publishing sites, the Quick Launch bar is replaced by a menu called Current Navigation, which serves a similar purpose but behaves differently.

The Global and Current Navigation bars can be extensively customized by using the Navigation link that is added to the Site Settings page when publishing is enabled. The navigation bars can be configured to show or hide subsites and site pages. They can be sorted, grouped, and have items added or hidden as needed.

The navigation controls for publishing sites are sensitive to the pages that are published in the Pages library as well as their status. For example, a page that is not yet published will not appear in the navigation menu for users who cannot see the page yet.

Variations

Site variations are sets of publishing sites that are designed to be very similar to one another but with certain well-controlled differences. Variations allow a number of sites to share some content while allowing for slight modifications between sites.

A single root site is created with the content that is common to all sites. Then, variants of that site are created based on the specific needs of the site. When a user navigates to the root site’s URL, that user is redirected to the correct site variant automatically.

The most common use for site variations is to create multilingual web sites. The root variation site might contain the site’s content in English. Each additional variant would be for a specific additional language. It is even possible to create multiple levels of variation sites for different dialects of the same language. SharePoint contains site translation workflows to help organize the generation of site variations in different languages. When a user enters the root site’s URL in a web browser, the default welcome page detects the language being used by the visitor’s browser and redirects that userto the correct site variation.

Variations can also be used to route visitors to content that is specific to the user in ways other than their language. For example, site variations can be used to customize content for different brands, mobile devices, or geographic locations. Essentially, anything a web page can detect about the user could be used to select a site variation.

Content Deployment

Content deployment refers to the process of moving published content from one site collection to another. The most common use of content deployment is to allow designers and content contributors to work in a nonproduction environment. Only after content is approved for publication does it move into the production server farm.

Content deployment is carried out by a series of timer jobs that can be scheduled or run manually. It is important to use the correct type of deployment job to get the desired effect. The jobs are as follows:

• Full: Moves all content from the source collection to the destination. Any existing content in the destination collection is not removed prior to copying over the new content. Therefore, deletions that have occurred in the source will not be reflected in the destination after a Full deployment.
• Incremental: Moves only new changes from the source to the destination. Any added, updated, or removed content items in the source will be reflected in the destination. An Incremental job will perform a Full deployment the first time it is run to ensure that all content is initially moved. Subsequent runs will move only updates.
• Quick Deploy: Moves only items that have been specified for quick deployment. This timer job generally runs more often than Incremental or Full jobs. This type of job is ideal for patching content that has been found to be incorrect in a staging or production environment. .

In software development, it has long been standard operating procedure to develop in one environment, test in another, and operate production on yet another set of servers. Content development in SharePoint can benefit from a similar approach. The advantages of this approach revolve around allowing only certain types of operations in each environment. There are also different numbers of users and network infrastructures to consider, as follows:

By using SharePoint’s content deployment feature, these environments can be separate site collections within the same server farm. As a best practice, at least the production environment should be a separate SharePoint farm. Three common designs for content deployment are one-, two-, and three-farm topologies.

In a single-farm topology, shown in Figure 7-7, authoring is performed in one site collection, and content is deployed to production in a second. There could also be a third site collection for staging if desired. The weakness of this approach is that many of SharePoint’s security controls are applied at the farm level and therefore cannot protect against accidental changes in this configuration.

Figure 7-7. A single-farm topology

In a two-farm topology, shown in Figure 7-8, authoring is performed in one SharePoint farm, and content is deployed to production in a second. The authoring farm need not contain as many servers as the production farm, because it will presumably have far fewer users.

Figure 7-8. A two-farm topology

A three-farm topology, shown in Figure 7-9, adds an intermediate staging environment that can be used for a detailed review of the completed content before final deployment to production. There are two ways to handle production deployment in this topology. Content can be deployed to production either from the stage farm or directly from the authoring farm.

Figure 7-9. A three-farm topology

Enabling Publishing Features

SharePoint’s publishing site functionality is implemented in a pair of features that can be enabled in any site or site collection. A third feature implements the publishing workflow. When using the publishing site and site collection templates provided by SharePoint, these features are automatically enabled. If you want to use them in an existing site, you need to activate them manually. This section describes the contents of these features and how to control them.

SharePoint Server Publishing Infrastructure

The SharePoint Server Publishing Infrastructure feature can be activated at the site collection level. In the root site of the collection, select Site Settings from the Site Actions menu. On Site Settings, select Site Collection Features under Site Collection Administration. Find the SharePoint Server Publishing Infrastructure feature in the list. The feature can be activated or deactivated from this page.

When the publishing infrastructure is activated in a site collection, a large number of artifacts are added to the SharePoint environment, including the following:

• Site templates
  • Publishing Site with Workflow
  • Publishing Site
  • Enterprise Wiki
• Permission levels
  • Approve
  • Manage Hierarchy
  • Restricted Read
• SharePoint groups
  • Approvers
  • Designers
  • Hierarchy Managers
  • Quick Deploy Users
  • Restricted Readers
  • Style Resource Readers
• Site settings links
  • Options to manage content structure
  • Options to manage navigation
  • Site collection actions for managing page layouts and site variations
• Navigation changes
• Master pages and page layouts
  • New master pages
  • New page content types and page layouts
• Site collection lists and libraries
  • Style library
  • Content and Structure
  • Reusable Content
  • Site Collection Documents
  • Site Collection Images
• Web parts
  • Summary Links web part
  • Table Of Contents web part
  • Content Query web part
  • Media web part

Publishing Approval Workflow Feature

The Publishing Approval Workflow feature provides the publishing workflow used with publishing sites. This feature should generally be activated at the site collection level whenever publishing is in use.

SharePoint Server Publishing Feature

The SharePoint Server publishing feature is activated at the site level. On the Site Settings page of the site, select Manage Site Features under Site Actions. Find the SharePoint Server Publishing feature in the list. The feature can be activated or deactivated from this page.

When the publishing site feature is activated, the following additions are made to the site:

• Site settings links
  • Control site output caching
  • Apply master pages and CSS styles
  • Control available page layouts and site templates
  • Set the site welcome page
  • The Save Site as Template link is removed because this feature is not available on publishing sites.
• Site lists and libraries
  • Documents: Contains site-specific document files
  • Images: Contains images for use within the site
  • Pages: Contains the site’s publishing content pages
  • Workflow Tasks: Used by the publishing workflow to manage approval tasks
• Other site configurations
  • Published item scheduling is enabled.
  • Document versioning is set to create major and minor versions.
  • Draft items are made available only to users who can edit them.
  • Pages are set to require a check-out operation prior to being edited.

Exercises

In this section, you will explore the functionality of SharePoint’s publishing sites by creating and modifying content. SharePoint’s publishing features are an enormous subject that could easily fill a book on their own. Because this book focuses on SharePoint Designer, these examples focus on using SharePoint Designer within the context of publishing. Please don’t make the mistake of thinking that what you see here is all there is to publishing in SharePoint.

You will begin by deploying a standard publishing template. Then, you will experiment with the workflow that governs the publishing of content pages. The key value of SharePoint Designer in publishing comes into play when designing page layouts. You will continue by modifying one of the default page layouts. Finally, you will create an entirely new kind of page by defining a new page content type and a page layout to go with it.

EXERCISE 7-1. SET UP A PUBLISHING SITE

EXERCISE 7-2. EDIT A CONTENT PAGE

EXERCISE 7-3. PUBLISH A PAGE LAYOUT CHANGE

EXERCISE 7-4. CREATE A NEW PAGE CONTENT TYPE AND PAGE LAYOUT

Figure 7-40. Completed content page

Notice that, when you published your product page, it appeared in the left-hand navigation control for the site. This happened because of the changes you made to the navigation configuration for the site in the first exercise in this chapter.

Summary

In this chapter, you have

• Configured SharePoint’s publishing features and created a full-featured publishing site
• Created and approved web content changes by using the approval workflow
• Explored the relationships between master pages, page layouts, and content pages
• Examined advanced publishing techniques including custom navigation, site variations, and content deployment

Figure 7-41. SharePoint publishing road map