Prescriptive Guidance for SharePoint Server 2007 Web Content Management Sites
Summary: Learn prescriptive guidance for creating and deploying Microsoft Office SharePoint Server 2007 Web content management (WCM) publishing sites. (14 printed pages)
Andrew Connell, Critical Path Training, LLC (Microsoft MVP)
October 2008
Applies to: Microsoft Office SharePoint Server 2007
Contents
Introduction to WCM Publishing Sites in Office SharePoint Server 2007
Considering Publishing Site Architecture and Implementation
Using Anonymous and Authenticated Publishing Sites
Using Publishing Site Definitions
Considering Development and Custom Code
Configuring Internet-Facing Publishing Sites for Production
Conclusion
Acknowledgements
Additional Resources
Introduction to WCM Publishing Sites in Office SharePoint Server 2007
In Microsoft Office SharePoint Server 2007, Microsoft has taken the best concepts and capabilities from an earlier product, Microsoft Content Management Server 2002, and added them to the SharePoint platform. These new capabilities, known as Web content management (WCM), facilitate the creation of content-centric sites on the SharePoint platform. Although they are SharePoint sites at their core, these sites have additional functionality that is facilitated by publishing features. These SharePoint features add special libraries and lists to SharePoint sites. Sites on which the publishing features are activated are known as publishing sites.
Publishing sites adhere to most, if not all, of the prescriptive guidance and generally accepted best practices for SharePoint sites. However, because of the noncollaborative nature of publishing sites and their generally larger audience, they require additional considerations and planning to be implemented successfully. This article addresses many areas that are specific to deploying successful and scalable publishing sites in the enterprise.
Considering Publishing Site Architecture and Implementation
All deployments from intranets to Internet sites start at the infrastructure and architecture stage. This section presents information about the following:
When to create Web applications, site collections or sites, and the Pages library in all publishing sites
When to use field controls instead of Web Parts in page layouts
How to take advantage of caching, code, and files
How to address multilingual site considerations and anonymous and authenticated site issues
Web Applications, Site Collections, and Sites
One of the most subjective decision points in the implementation of a publishing site project, or any SharePoint project, is when to create Web applications, site collections, and SharePoint sites. Most people tend to agree on one thing: There are no definitive rules to guide you about when you should create one or another. The guidance in this article is also not a definitive blueprint, but provides points to consider when you encounter these questions.
Web Applications
Web applications generally stand apart from site collections and sites, and have more concrete decision points that you can use to determine when to create them. Web applications are used as HTTP entry points to site collections, which contain the SharePoint sites that are loaded with content. All SharePoint site collections and sites within a Web application share the same settings for the following elements:
Alerts: Specifies how many alerts each user can create and whether alerts are enabled.
Outbound E-mail: Specifies the server location and e-mail address of the e-mail sender.
Recycle Bin: Specifies the amount of time items are kept in the Recycle Bin, and whether the Recycle Bin is enabled.
Max File Upload Size: Specifies the maximum size of files that can be uploaded as attachments to list items and into document libraries.
RSS and Blog API: Specifies whether RSS feeds and the blog API (for remote posting of blog posts) are enabled.
In addition to this list of settings, because Web applications have a single web.config file on the file system, anything that is defined in that file is shared across all SharePoint site collections and sites that are accessible via the Web application, including:
Name-value properties, commonly used for database connection strings.
Code access security (CAS) trust level.
Authentication providers, including membership, role, and profile providers.
HTTP handlers and modules.
A unique aspect of Web applications is that administrators can configure multiple applications to map to the same site collections. This technique, implemented when creating Web applications and selecting the option Extend an existing Web application within Central Administration, simply provides an additional point of entry to site collections. This technique enables administrators to configure multiple authentication providers for the same site collection.
Finally, because Web applications—also known as Internet Information Services (IIS) Web sites—are reached by users via a unique URL, all site collections and sites within a Web application share the same domain name in their URLs.
Site Collections
Site collections are used primarily as an administrative, management, and security construct in Office SharePoint Server. Deciding whether to create an additional site collection for a publishing project implementation is very subjective. Site collections are simply containers of SharePoint sites, where the content resides. A good guideline is to think of site collections as individual Web applications in the same way that Microsoft ASP.NET 2.0 applications are scoped and developed. Site collections, however, do have two very important characteristics.
First, all content within a site collection must reside in a single content database. This can prove to be a very significant factor for large publishing site collections. For example, consider a very large organization's intranet site that is implemented as a single site collection. In this scenario, everything—all documents, media lists, and other content—is in a single database. This content database could grow to be very large, for example, up to several hundred gigabytes or even terabytes! The backup process for this database could negatively affect the performance and access to the corporate intranet, and negatively affect the business. In addition, the single content database does act as a single point of failure. It might make more sense, based on the size of the project, to segment the implementation into multiple site collections.
Second, almost all built-in functionality of site collections does not cross the boundary of a site collection. For example, site navigation components and roll-up Web Parts such as the Content Query Web Part cannot merge data across site collections. If this functionality is required, you need to implement a publishing site as a single site collection, or build custom components that can aggregate data across site collections.
One exception to the limitation of sharing data across site collections is search: The Enterprise Search functionality in Office SharePoint Server crosses the site collection boundaries if it is configured to do so. The built-in Enterprise Search components can return data from multiple site collections. In addition, you can create custom components that use the built-in Enterprise Search Web services or SharePoint API to retrieve data via the search infrastructure.
Sites
SharePoint sites are used primarily in publishing sites to segment channels or sections of a content-centric site. For example, one site can be used for the "about us" section of a company's information, while a subsite within it is used for news and another is used for executive biographies. Each section contains content in the form of pages, images, and associated media.
Many people think liberal use of SharePoint sites within a site collection can lead to a heavy implementation, and instead seek ways to use a single site for multiple sections or types of content. Do not let a high number of subsites push a project in this direction. SharePoint site collections can scale easily to support tens of thousands of SharePoint sites, as addressed in the Microsoft TechNet article Plan for Software Boundaries (Office SharePoint Server).
You should use each SharePoint site to contain a section of content, not a type of content. In addition, a SharePoint site should not contain two or more sections of content. As described next, for supportability reasons, all content needs to reside in the top-level (root) folder of the Pages library in each site.
Pages Library
Each publishing site (a SharePoint site with the publishing features activated) contains exactly one Pages library. This library is used to store all the content pages for a site. Folders should not be used within a Pages library. Folders do not cause Office SharePoint Server to break, but many things in a publishing site are not configured to recognize folders in the Pages library. For more information, see Knowledge Base article 948614, New Pages That Are Created in a Subfolder of a Pages Library of SharePoint Server 2007 Are Saved in the Root of the Pages Library.
Images that are used within the content pages should not be added to the Pages library within a site. Instead, store them in the Images library found within all publishing sites. The same is true for documents and other collateral referenced within pages; store this content in the Documents library found in all publishing sites.
Content Roll Up
One of the most common tasks in content-centric sites is to display content from across a publishing site. While the content could reside anywhere within a site collection, the preference is not to replicate it on a landing page, but instead to "roll up" the content and simply show links to it. These roll-up lists of content can reside anywhere within the site collection.
For example, consider a site that is composed of multiple subsidiaries that are all in the same site collection. Each subsidiary issues its own press releases. However, the top-level Web site, representing the holding company, must show all press releases across all the subsidiaries. Instead of requiring content authors to enter and maintain two copies of the press release, or developing some elaborate custom replication solution, the top-level site needs to roll up the content. When people browse to the Press Release section of the top-level site, they should see a list of all the press releases, each linked to the individual instance in each subsidiary site.
Office SharePoint Server provides two roll-up Web Parts that are available for use within publishing sites: Table of Contents and Content Query. The Table of Contents Web Part is used primarily to keep the main navigation from becoming too crowded for sections that have a significant number of pages. You can configure it to show pages up to three levels deep. The Content Query Web Part is very flexible and heavily optimized to pull content from across lists and sites within a site collection. Both Web Parts support grouping, sorting, and filtering options, and robust styling and rendering options.
These two roll-up Web Parts, available within publishing sites, perform very well because they use the same infrastructure and caching techniques that are used by the built-in navigation controls. Navigation must be fast because it is on almost every single page in a SharePoint site. Consider using one of these two Web Parts, especially the Content Query Web Part, when rolling up content.
There are times, however, when the Table of Contents Web Part or the Content Query Web Part does not satisfy the business requirements, and you need custom code. Before you create a completely new solution, consider deriving a class from one of the existing Web Parts. For example, a common complaint about the Content Query Web Part is its lack of dynamic filtering. Fortunately, you can create a Web Part that inherits from the Content Query Web Part, and simply add the new functionality to facilitate the new dynamic filtering capability. Consider the Web Part in the following code example.
using System;
using Microsoft.SharePoint.Publishing.WebControls;
namespace MSDN.SharePoint.Samples {
public class ContentQueryExWebPart: ContentByQueryWebPart{
protected override void OnLoad (EventArgs e) {
// If a value was specified on the query string...
if (string.IsNullOrEmpty(this.Page.Request.QueryString["Filter1Field"]))
return;
// set the chaining of filter values to be combined by
// using the bitwise OR operation.
this.Filter1ChainingOperator = FilterChainingOperator.Or;
// Get the filtering field by name.
string filterFieldName = this.Page.Request.QueryString["Filter1Field"].ToString();
// Because the field name is not suffucient for the CQWP, get the field's GUID.
Guid filterFieldID = Microsoft.SharePoint.SPContext.Current.Item.Fields[filterFieldName].Id;
// Get the filtering field value.
string filterFieldValue = this.Page.Request.QueryString["Filter1Value"].ToString();
// Set the filtering info.
this.FilterField1 = filterFieldID.ToString();
this.FilterValue1 = filterFieldValue;
}
}
}
The preceding code derives classes from the built-in Content Query Web Part, and then retrieves filtering information (field name and filtering value) from the query string. It then sets the filtering values on the Web Part before rendering it.
Deriving classes will not work all the time, and there are other times when a more customized solution is required. In these cases, consider using the same infrastructure shared by both navigation controls and the Content Query Web Part. The Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider object exposes the site hierarchy to site map data sources. One of the key aspects of this object is its built-in caching mechanism. The PortalSiteMapProvider object caches the result set it retrieves from an expensive query to spare itself from running an additional query. Three methods—GetCachedList(), GetCachedListItemsByQuery(), and GetCachedSiteDataQuery()—address all the cache management for you.
Field Controls vs. Web Parts in Page Layouts
Page layouts are used in publishing sites as the templates that define the various rendering options for pages that are defined by using content types. Page layouts contain editable regions where content owners can enter, edit, and manage content. When creating page layouts, developers and designers have two options for adding editable regions: field controls or Web Parts. Each option has advantages and disadvantages with each implementation.
Using Web Parts in Page Layouts
When developers or designers insert a Web Part zone on a page layout, they give control to the content authors. Developers and designers have no control over the content that content authors insert into those zones. Content authors can add any Web Parts that are installed into the zone at authoring time. In addition, the content owners have full control over the content they insert into the Web Parts; designers and developers also have no control over the content or formatting.
Another concern associated with using Web Parts in content pages is the way Web Part data is stored. The ASP.NET 2.0 Web Parts Framework stores data within the context of the current page and for the current user (or shared user), with the personalization data store. Office SharePoint Server automatically configures ASP.NET 2.0 to store the data within the site collection's content database. However, Office SharePoint Server does not store the data within the context of the page's current version. This means that data within a Web Part is not versioned with the page.
Using Field Controls in Page Layouts
You can also use field controls within page layouts as the editable regions in a page layout. Developers and designers have full control over which field controls are used and where they are placed on a page layout at design time. They can also specify rules on the field controls, such as whether content owners are allowed to perform formatting on content, or to insert tables, links, or images. They can even specify rules about whether content owners have access to the raw HTML markup. Unlike in the case of Web Parts, in this scenario the designers and developers have ultimate control over the positioning and formatting of the content.
Just as with Web Parts, with field controls, it is important to understand how the data is stored. Field controls pull the content from the list item that represents the current page in the Pages list. As a result, the data that is displayed (and authored) in a field control is stored with the page itself. By default, when a page is created or edited, a new version is created. Therefore the data within the page, and thus the content in field controls, is versioned with the page.
When to Use Web Parts or Field Controls in Page Layouts
Determining when to use Web Parts and when to use field controls in page layouts depends on the situation.
Table 1 shows that the selection of field controls or Web Parts as the editable regions in a page layout depends on two issues: where the data is stored, and who should have ultimate control.
Table 1. Comparing field controls and Web Parts
| Area of Comparison | For Field Controls | For Web Parts |
|---|---|---|
Location where content is stored |
In a field in the underlying SPListItem object of the page |
Within the Web Part data of the page |
Personalization available |
No |
No |
Versioning |
Tied to the page with complete history |
Tied to the page without history |
Who control belongs to ultimately |
Page designer or developer |
Page designer (in placement of Web Part zones); content owner in managing of zone contents (add or edit Web Parts within Web Part zones) |
If the version history of pages is important within a project, or if control over the layout and formatting of content is important, field controls are likely the right choice. But, if content authors need more control over the page, consider using Web Parts. A good use of Web Parts in a publishing site is to provide some sort of functionality, for example, to serve as a content roll-up such as with a Content Query Web Part or to show weather, stock, or RSS feed updates instead of content.
Achieving Peak Performance Through Caching
Microsoft made significant performance improvements in the current releases of Office SharePoint Server 2007 and Windows SharePoint Services 3.0. Most significantly, an ISAPI filter was removed when the ASP.NET 2.0 team added System.Web.Hosting.VirutalPathProvider, which allowed the SharePoint team to plug in a custom mechanism to determine where the files that make up a SharePoint site are found (in the content database or on the file system). For more information, see Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0.
However, anonymous Internet-facing sites that are content-centric, which is a very common use of publishing sites, have higher demands for performance. First, the exact audience number is hard to determine and cannot be guaranteed. Second, the speed at which the content is delivered and rendered to the end users is the highest priority—not the collaboration capabilities offered by traditional SharePoint sites such as team sites or corporate intranet sites.
To address these additional performance demands, Microsoft added three caching implementations that are available to publishing sites. Two caching concepts—page output caching and object caching—are native to ASP.NET 2.0. Office SharePoint Server provides administrative interfaces to make the management and configuration easier. Notice, however, that the majority of caching is not enabled by default; site administrators must configure it to be able to use it.
There are two primary goals of caching: minimize the number of roundtrips between the SharePoint front-end Web servers and the database servers, and reduce the load on the front-end Web servers. Caching addresses these goals by persisting frequently requested pages and objects in memory on the front-end Web servers, reducing the subsequent roundtrips for the same objects in the database, and reducing the number of times the ASP.NET 2.0 page life cycle is spun up.
Page Output Caching
Page output caching in Office SharePoint Server 2007 publishing sites is exactly the same as in ASP.NET 2.0 sites. One person takes the hit for others by triggering the page construction, compilation, and execution process (otherwise known as the ASP.NET 2.0 page life cycle). The HTML that is generated is then saved in the server's volatile memory for a period of time. When the next user requests the same page, and if the request matches criteria similar to the previous request, the generated HTML is reused and the entire page life cycle is bypassed.
Also for page output caching, Office SharePoint Server 2007 adds detailed administrative control and a user interface that enables site owners and administrators to have granular control over the site. Office SharePoint Server introduces the concept of profiles that can be applied to individual sites. Each profile defines what makes one request unique from another. It also allows administrators to specify how long the rendered HTML of a page stays in cache and how Office SharePoint Server should perform:
Should each request trigger a check to see whether the underlying content is updated? If it is, the page in cache should be invalidated and rebuilt. For an anonymous Internet-facing site where speed is most important, perhaps having a page that is slightly stale is preferable to enable a faster experience. Therefore, disable setting this check to get a little more performance out of the site.
Should the permissions of the person who initiated the request be compared to those of the person who caused the generated HTML markup of the page in cache? This is important in the case of authenticated sites, but in the case of an anonymous site in which everyone has the same permissions, this extra check is unnecessary.
These profiles can then be applied to the site collection, one profile for anonymous sites and another for authenticated sites. The top-level site inherits the settings of the site collection and each subsite inherits its parent's cache settings. At any point, a site can break inheritance and set a site to use different profiles. Cache profiles are managed from the Site Collection Cache Profiles page (Site Settings menu).
Object Caching
Object caching differs from page output caching in that it does not store the generated HTML markup in memory; instead, it stores objects that are used in the page construction process to reduce the number of roundtrips to the database. These objects can include master pages, page layouts, and even the results generated from complex queries such as those from Content Query Web Parts.
Administrators can configure how much memory is used by the object cache on the Site Collection Object Cache page. This page also enables administrators to turn on the caching of results and determine the amount of time results are kept in cache, from cross-site queries such as those from the Content Query Web Part.
Disk-Based Caching
Disk-based caching is exclusive to SharePoint publishing sites. Office SharePoint Server stores almost all content in a site, including cascading style sheets (CSSs), ECMAScript (JavaScript, JScript), and images within the site collection's content database. Each time a request is issued for a page, the SharePoint front-end Web server must go back to the database to retrieve these files. Disk-based caching enables administrators to configure a SharePoint Web application to persist these static files on the hard disk of the front-end Web server. Subsequent requests for a page cause the front-end Web server to bypass the database roundtrip by serving the file off the disk.
Disk-based caching is configured within the web.config file of the SharePoint Web application, specifically by the <blobcache /> element. Attributes on this element allow administrators to enable or disable caching, and specify a regular expression that is used to determine which files to persist on the front-end Web server.
Using Anonymous and Authenticated Publishing Sites
Publishing sites are typically used as Internet-facing sites and so are commonly configured for anonymous access for the majority of the site. This is unlike most traditional SharePoint collaboration sites, which are typically set up to allow only authenticated users. Opening a SharePoint site for anonymous users adds other factors to consider.
Anonymous Sites
By default, all SharePoint sites have a permission level named Limited Access, which is granted to all users who have access to a SharePoint site. The Limited Access permission level grants the View Application Pages right, which enables users to view all the SharePoint system pages for items such as lists. For example, almost all lists (at least those built-in lists) have the AllItems.aspx page, which shows all the items within a specific list. This is needed in collaboration sites; however, it is not needed in a publishing site because it would permit the anonymous users of a site to see all the pages within the Pages library in the publishing site. This is not desirable because publishing sites are usually very structured and controlled. Content owners want to control what the users of a site can see.
To control this type of access, site administrators need to remove the View Application Pages right from the Limited Access permission level. Unfortunately, the Limited Access permission level is not editable through the browser interface. However, Microsoft has provided a feature named Restrict Limited Access Permissions (found in the path [..]\12\TEMPLATE\FEATURES\ViewFormPagesLockdown) that programmatically removes the View Application Pages right from the Limited Access permission level.
Authentication Mechanisms
Not all publishing sites are configured for anonymous users. In fact, not all anonymous sites are truly 100 percent anonymous. Instead, some are a mix of anonymous and authenticated. For example, an anonymous site can have a protected area where people need to authenticate to view the pages or download a file. In these cases, as with typical SharePoint collaboration sites, administrators can configure the site to take advantage of one or more forms of authentication.
Thanks to the stacked architecture of SharePoint Products and Technologies, built on top of the Microsoft .NET Framework, you can take advantage of everything that ASP.NET 2.0 offers. This includes the membership provider model that offers pluggable authentication. Not only can a site be configured for Windows authentication, but also for forms authentication. Forms authentication opens the site to many more options, because it removes the challenge-response dialog box and instead redirects users to a page where they can enter their e-mail addresses and passwords to authenticate on the site.
However, not all authentication mechanisms perform equally. Some are much faster than others. It all depends on the performance of authenticating the user against the authentication store and how often the application (Office SharePoint Server) needs to talk to the authentication store. For Internet-facing sites, performance is a significant concern and so should be factored into your planning of an implementation. The Microsoft TechNet article Additional Performance and Capacity Planning Factors (Office SharePoint Server) lists anonymous as the fastest mechanism, followed by Kerberos, NTLM, and finally forms authentication.
One way to mitigate the performance impact of forms authentication is to obfuscate it from Office SharePoint Server 2007. Forms authentication can be handled, for example, by Microsoft Internet and Security Acceleration (ISA) Server, which maps the forms authentication user to an Active Directory user. In this way, SharePoint Products and Technologies works only with Windows authentication (Kerberos or NTLM), and ISA handles the forms authentication portion.
Using Publishing Site Definitions
Office SharePoint Server 2007 provides two built-in site definitions that make use of the publishing capabilities: Collaboration Portal and Publishing Portal. Both site definitions generate a predefined site structure and add some content. Publishing Portal is designed to be used for an Internet-facing, content-centric site. When creating sites with the Publishing Portal site definition, additional master pages and branding files such as images and style sheets are provisioned into the site collection. The challenge with this approach is that most implementations have their own appearance ("look and feel") that does not match the built-in branding. One approach to this challenge is to create a site by using the Publishing Portal site definition, clean out all the extra branding that was added automatically, and then implement the custom brand.
Unfortunately, this is not an ideal solution because it involves some extra work cleaning out content that never needed to be added in the first place. A better option is to create a site definition without the extra branding. This is commonly known as a minimal publishing site definition, and it adds all the required elements for a publishing site without the branding. This is not nearly as complicated as building a custom site definition from scratch, and can enable you to spend time understanding how the Publishing Portal site definition works. Figure 1 shows the majority of the work that is performed by the Publishing Portal site definition: the activation of a network of Features.
Figure 1. Publishing features activation dependencies
.gif "Publishing features activation dependencies")
Again, the primary goal is to remove the branding that is created by the Publishing Portal site definition. Almost all of this can be traced back to the PublishingLayout Feature. Unfortunately the PublishingLayout Feature is interrelated with other features. Therefore, a new feature needs to be created to replace some of the other features.
If you elect to create a minimal Publishing Portal site definition, ensure that you do not change the existing Publishing Portal site definition. Instead, create a copy and assign it a new name and identifiers.
Note
The process of creating a Minimal Publishing Portal site definition is described in Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server (by Andrew Connell, WROX, ISBN: 0470224754). Chapters 14 and 20 from this book are available as excerpts in the MSDN Library.
Considering Development and Custom Code
Developers should always strive to use as many of the built-in components and functionality of Office SharePoint Server publishing sites as possible; however, virtually all projects require some level of custom component development. Real-world scenarios cannot rely on vendors such as Microsoft to predict every business requirement. Thus, developers must enter the fray to bridge this gap.
Take care in your creation of custom components, just as you would take care with any anonymous Internet-facing site. These types of sites incur a much heavier load, and even the most minor memory leak or poor performing component can dramatically affect the performance of a site in a negative way.
Planning in Advance for Multilingual Solutions
Office SharePoint Server 2007 publishing sites are used to present content in multiple languages to meet the needs of a vast audience. However, many times sites are created and tested under one language and rolled into production with translation happening in parallel. What most people do not do, however, is test custom development components in a multilingual scenario.
Publishing sites include a capability to assist in the translation of content known as variations. Variations facilitate the creation, management, and maintenance of multiple copies of the same site that are in different languages. Developers should take advantage of resource files (*.resx) to store localized strings just as ASP.NET 2.0 developers can, instead of including language-specific strings in the compiled code. Resource files can also be used from within features by using the $Resource token. For example $Resource:cmscore;contenttype_articlepage_name tells Office SharePoint Server to retrieve the value from the contenttype_articlepage_name token in the cmscore.resx file located in the path [..]\12\TEMPLATE\Resources.
In addition to localized strings, you should also plan for variations when creating custom Web Parts. Copying Web Parts from one label to another as pages are published also copies the Web Part metadata. This can pose a challenge because if a Web Part displays data in a list and gets a reference to the list by using the list's GUID, the Web Part will continue to pull the data from the list in the original variation label even after being copied to another variation label. One way to work around this is to have the Web Part inherit from Microsoft.SharePoint.WebPartPages.WebPart instead of from System.Web.UI.WebControls.WebParts.WebPart, and also implement the IWebPartVariationUpdate interface. This interface contains a single method, Update(PublishingWeb ownerWeb), called by the variation job as it is copied to the target variation. You can use this method to perform any additional work necessary after the Web Part is copied to the target variation.
Cleaning Up Disposable Objects
As in typical .NET Framework development, Office SharePoint Server is not a completely managed application. Many of the underlying components are still unmanaged objects that are contained in managed wrappers. These objects implement the IDisposable interface, which is a signal to developers that they should release the object's internal unmanaged resources as soon as the object is no longer needed by calling the Dispose() method. Failure to do so causes the .NET Framework garbage collector to record the objects without their real memory footprint when it runs through finding candidates to free up memory. This results in excessive memory consumption, which can lead to frequent application pool recycles, application crashes, and periodic OutOfMemory exceptions. What is frustrating is that many of these memory pressure issues do not surface in common development or testing. Unless a project has gone through serious load testing, the memory pressure issues do not arise until an application is deployed in production.
Understanding when to dispose of objects when doing custom SharePoint development is very important because this concept concerns two very commonly used objects: SPSite and SPWeb. The article Best Practices: Using Disposable Windows SharePoint Services Objects includes information about when to and when not to dispose of SPSite and SPWeb objects; however, a safe way to think about it is the following:
If an object implements IDisposable, call Dispose() as soon as the object is not needed.
Dispose of only those objects that are from the same code that is responsible for creating them.
Coding Performance Techniques
Aside from understanding the issues around disposable objects in development, there are other custom coding concerns that you should be aware of. For additional information, see Best Practices: Common Coding Issues When Using the SharePoint Object Model.
Unnecessarily Creating Objects
Office SharePoint Server is filled with collections. For example, sites have subsites, sites have lists, and lists have items. The objects that represent these collections expose the items in the collections by using indexes. This allows developers to get instances of a list item off of the SPList.Items collection by using either the item identifier or GUID. The same is true for SharePoint lists; the SPWeb.Lists collection can yield a specific list if you specify it by name or GUID. Look at the following code example.
string listTitle = SPContext.Current.Web.Lists["Pages"].Title;
int pageCount = SPContext.Current.Web.Lists["Pages"].Count;
The code demonstrates a very bad practice—each call to the Pages library causes Office SharePoint Server to do the following in the internals of the API:
Create an instance of an SPList object.
Hydrate the SPList object with the data from the Pages library.
Get a property (Title or Count) of the Pages library, and return it to the caller.
Free up the SPList object.
Thus, the code creates two internal instances of the SPList object and must perform two roundtrips to the database to hydrate the objects. The proper way to do this would be to get a reference to the Pages list and retrieve the necessary properties as follows.
SPList pagesLibrary = SPContext.Current.Web.Lists["Pages"];
string listTitle = pagesLibrary.Title;
int pageCount = pagesLibrary.Count;
Minimizing Database Roundtrips
When writing custom components or code-behind files for page layouts, master pages, or other types of pages, minimize the number of roundtrips to the database. This includes doing things such as creating multiple instances of SPSite objects to get references to other site collections. Each SPSite instance triggers a call to the database to hydrate the object.
A large number of database roundtrips slow the server-side processing of the page on the SharePoint front-end Web server to generate the HTML markup that is sent to the requestor, and it also increases the load on the database server. The Microsoft TechNet article Additional Performance and Capacity Planning Factors (Office SharePoint Server) recommends only two or three roundtrips on core pages.
Customizing and Extending Navigation
Office SharePoint Server 2007 publishing sites, just like typical collaboration Web sites, must have discoverable content. You can achieve this in many ways, one of which is through navigation. Most content-centric site projects include the requirement of customizing the navigation. In such cases, first try to use the built-in navigation controls and modification vehicles, because Microsoft implemented some significant optimizations and caching techniques to ensure the navigation controls always operate as fast as possible.
Developers often think that to modify the rendering of the navigation they must create custom navigation rendering controls. The controls that are provided by default in Office SharePoint Server are quite customizable. You can configure them to use specific CSS classes and show only a certain number of levels of depth. When you require additional customizations, consider purchasing a navigation control from one of the many third-party ASP.NET 2.0 Web control vendors; ASP.NET 2.0 navigation controls work in SharePoint sites and they are usually very inexpensive when compared to building controls from scratch.
There are also times when you need to customize the controls that provide the navigation data to the rendering controls. For example, what if the navigation should include or be generated from an external application? Or what if it should merge some additional links into SharePoint navigation? In this case, it might make sense to create a custom navigation site map provider. This is the component that is responsible for building the navigation hierarchical structure that is used to generate the markup used for rendering. It might seem intuitive to create one, but this is not a good idea. The built-in navigation providers, especially those used in publishing sites and that are included in the Microsoft.SharePoint.Publishing.dll assembly in Office SharePoint Server 2007, are highly optimized, perform very well, and employ sophisticated caching mechanisms. Therefore, it is a better option to use the built-in PortalSiteMapProvider navigation site map providers by deriving classes from them and creating a custom provider that can still take advantage of all the performance tweaks. The following code shows how to create a custom site map provider that never includes the contents of lists.
using System;
using System.Web;
using Microsoft.SharePoint.Publishing;
using Microsoft.SharePoint.Publishing.Navigation;
namespace MSDN.SharePoint.Samples {
public class CustomPortalSiteMapProvider: PortalSiteMapProvider {
public override SiteMapNodeCollection GetChildNodes (PortalSiteMapNode node, NodeTypes includedHiddenTypes) {
PortalSiteMapNode pNode = node as PortalSiteMapNode();
// If nothing is defined or if the node is a list, return nothing.
if (pNode == null || pNode.Type == NodeTypes.List)
return new SiteMapNodeCollection();
else
base.GetChildNodes(pNode);
}
}
}
Writing Custom Code and Managing and Deploying Files
Almost all publishing sites require some custom files. These files can include features, images, CSSs or assemblies containing Web Parts, event receivers, or workflow templates. All these files must be deployed to the staging and production servers in some way. One option is to simply XCOPY the files to the locations you want. However, this is not recommended in a SharePoint environment. Instead, always deploy files in production systems by using the Windows SharePoint Services solution package framework, known as WSP (*.wsp) files or solutions.
WSP files are preferred for the following reasons:
They include all the files that need to be deployed in a single, easily portable package.
Their deployment can be scheduled at a given time in the future.
Office SharePoint Server automatically determines whether to deploy a solution to one server or multiple servers in the farm. For example, a Web Part should be deployed to all front-end Web servers in the farm that hosts a site.
If a new server is brought online and joined to the SharePoint farm, Office SharePoint Server automatically deploys the necessary solutions to the new server.
When solutions deploy Features, the Features are automatically installed.
Solutions make the process of creating custom code access security policy file changes much more repeatable and less prone to error.
As a general rule, all custom code and files should be deployed by using Windows SharePoint Services solution packages.
Configuring Internet-Facing Publishing Sites for Production
Before launching an anonymous Internet-facing Office SharePoint Server 2007 publishing site into production, developers or administrations should verify that a few key tasks are completed to ensure a clean, secure, and well-performing site transition. These tasks include verifying that all of the appropriate cache settings are configured and enabled where applicable, the site is locked down so SharePoint application pages are not accessible to anonymous users, and that the site is stripped of all but necessary permissions and identity information, and all code is secured.
Conclusion
Office SharePoint Server 2007 Web content management sites, also known as publishing sites, follow many of the same good practices and guidance that apply to the development, deployment, and configuration of any SharePoint site. However, publishing sites also have unique considerations around the topics of architecture, performance caching, and aggregation of content from across one or more site collections. This article addresses each of these topics to provide good guidance for those who want to implement successful and highly available publishing sites.
Acknowledgements
The author would like to acknowledge Spencer Harbar (Microsoft MVP) for his help in technical feedback and reviews of this article.
About the Author
Andrew Connell is an author, instructor, and co-founder of Critical Path Training, a SharePoint education–focused company. Andrew is a five-time recipient of the Microsoft Most Valuable Professional (MVP) award for Microsoft Content Management Server (MCMS) and Microsoft Office SharePoint Server. He has contributed to numerous MCMS and SharePoint books over the years. In June 2008 he published the only book on the subject of developing Publishing sites by using Office SharePoint Server 2007: Professional SharePoint 2007 Web Content Management Development by WROX. Andrew has spoken on the subject of SharePoint development and Web Content Management (WCM) at various events and national conferences, such as Tech·Ed North America and EMEA, SharePoint Connections, VSLive, Office Developer Conference, and Microsoft SharePoint Conference in Sydney, Australia. You can always find Andrew at his SharePoint development and WCM–focused blog.
Additional Resources
For additional information, see the following resources.
On Microsoft TechNet:
On MSDN: