Developing SharePoint Server 2007 Publishing Sites the Smart and Structured Way

The latest release of the SharePoint platform, Microsoft Office SharePoint Server (MOSS) 2007, introduces new capabilities to the SharePoint platform: hosting content-centric Web sites on SharePoint and providing a robust publishing infrastructure. This publishing infrastructure enables site owners to delegate to certain individuals the creation and management of content on the site. Other users have rights to approve and publish content for readers to see. Interwoven in this process is a robust controlled publishing infrastructure founded on the Windows Workflow Foundation (WFF). Combined with significant performance enhancements and improvements to the underlying foundation of MOSS, Windows SharePoint Services (WSS) v3, SharePoint is now capable of hosting content-centric Internet sites! This component of MOSS 2007 is commonly referred to as Web Content Management (WCM), and sites utilizing the WCM features are called Publishing sites.

A major component to Publishing sites is the development story: the process behind constructing a content-centric site. Most development concepts surrounding Publishing sites are really SharePoint concepts, because a Publishing site is just another WSS site with some extra functionality. So, how are you supposed to develop a Publishing site? To date, only one approach has been the leader in the WCM community. This is the approach you will find in virtually all documentation, every whitepaper, every Webcast, every conference or trade show presentation, and every magazine article. However, this approach poses certain challenges in the real world when many organizations have a strict change control process.

An alternate development process is presented in this article. It addresses many of the pitfalls associated with the conventional approach. Though many of the concepts in this article are tailored to work specifically with Publishing sites, they will also work with little or no modifications in general WSS v3 sites. Before any concerns arise from the process outlined in this article, rest assured everything is 100 percent supported by Microsoft. In fact, this is the process Microsoft’s out-of-the-box site templates (Collaboration Portal and Publishing Portal) utilize to create the site infrastructure and layout files to implement the default sites!

Another (and arguably better) option is to leverage the Feature and solution framework, a new addition in WSS v3.

Using Features and Solutions to Deploy Site Infrastructure and Layout Files

Both site infrastructure and layout files can be implemented with XML files in Features. Among their various capabilities, Features can be used to create site columns (also known as fields), content types, and provision files. Using these capabilities, developers can create a Feature (or multiple Features) that create the site infrastructure (site columns and content types) and layout files (master pages, page layouts, and so on), package up the Feature(s) into a solution file, and share it with other development team members, or hand it off to environment administrators to implement the changes to the production systems.

The ideal way to implement a Publishing site’s site columns, content types, and add files (also called file provisioning) is using a Feature(s) and deploying the Feature(s) with solutions. Quite simply, it offers developers the most granular control and the easiest way to implement the necessary elements in various environments.

Creating a Feature

NOTE

All files used in the following demonstration are available for download from the download page for Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs.

The first step in this alternate approach is to create a Feature. To create a Feature, create a new directory named AlternativeApproach in the following location:

C:Program FilesCommon FilesMicrosoft Shared
   web server extensions12TEMPLATESFEATURES.

All Features must contain a Feature definition file, so create a new XML file in Visual Studio 2005 named feature.xml and save it in the AlternativeApproach directory.

With feature.xml open in Visual Studio 2005, add the following code to the file to create the Feature definition. (Table 1 contains a list of the most common attributes used in the <Feature> node.)

<?xml version="1.0" encoding="utf-8"?>
<Feature 
         Id="6B0480D2-009A-49c1-9DCB-EBF5F7358873"
         Title="Alternative Approach Feature"
         Description="Creates site columns, content types,
         a master page, and page layouts for a Publishing site."
         Scope="Site"
         Hidden="FALSE">
</Feature>

Table 1: Feature Element’s Attributes


ATTRIBUTE DESCRIPTION
Id Unique ID (a GUID without brackets) of the Feature. This is required.
Title Name of the Feature to be displayed on the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional and limited to 255 characters.
Description Description of the Feature to be displayed on the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional.
Scope One of four values: Farm (applies to all sites in the entire SharePoint farm), WebApplication (applies to all SharePoint sites within the Web application it was activated in), Site (applies to all sites within a site collection), or Web (applies to the specific Web it was activated in). This is required.
Hidden If True, the Feature is not displayed in the Site Features or Site Collection Features pages linked from a site’s Site Settings page. This is optional (default value is False).
Version This optional value can be used to version the Feature. The format to use is: [#.#.#.#].

Only one attribute needs to be highlighted here: Scope. When creating site columns and content types, Scope can be Site or Web. However, when provisioning files, it should be Site.

NOTE

For more information on the <Feature> node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms475601.aspx.

Creating Site Columns with Features

With the shell of a Feature created, the next step is to create an element manifest file that will create a site column. Create a new XML file in Visual Studio 2005 named SiteColumn.xml and save it in the AlternativeApproach directory.

Then, add the element manifest file to the Feature by adding the following code between the <Feature></Feature> tags in the feature.xml file:

<ElementManifests>
   <ElementManifest Location="SiteColumn.xml"/>
</ElementManifests>

Next, add the following code to SiteColumn.xml that will create the site column when the Feature is activated. (Table 2 contains a list of the most common attributes used in the <Field> node.)

<?xml version="1.0" encoding="utf-8"?>
<Elements >
   <Field ID="{C3AA9C21-81F7-41d7-B5A5-CBEB40768C46}"
          Name="AlternateApproachColumn"
          DisplayName="Alternate Approach Column"
          Group="WROX"
          Type="Text" />
</Elements>

Table 2: Field Node’s Attributes


ATTRIBUTE DESCRIPTION
ID Unique ID (a GUID with brackets) of the site column. This is required.
Name Unique name for the new site column. This is the internal name used by SharePoint to uniquely identify the column within a list. This value will never change. This is optional. If not specified, the Name is automatically generated based on the DisplayName of the column.
DisplayName The user-friendly name of the column that appears in the SharePoint browser-based interface, such as the column name when a list is displayed in table format. This is optional.
Group Specifies the site column group that the site column will be added to. This is optional.
Type The data type of the field.

NOTE

For more information on the <Field> node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms437580.aspx.

Creating Content Types with Features

The next step is to add a content type to the Feature. Create a new XML file in Visual Studio 2005 named ContentType.xml and save it in the AlternativeApproach directory.

Then, add the element manifest file to the Feature by adding the following code between the <ElementManifests> tags, just after the existing <ElementManifest> tag in the feature.xml file:

<ElementManifest Location="ContentType.xml"/>

Next, add the following code to ContentType.xml that will create the content type when the Feature is activated. (Table 3 contains a list of the most common attributes used in the <ContentType> node.)

<?xml version="1.0" encoding="utf-8"?>
<Elements >
  <ContentType
ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3
DB064584E219954237AF3900213FEEC23C37400bBEC425C10E76F37F
"
               Name="Alternate Approach Content Type"
               Group="WROX">
    <FieldRefs>
      <FieldRef ID="{C3AA9C21-81F7-41d7-B5A5-CBEB40768C46}"
                Name="AlternateApproachColumn" />
    </FieldRefs>
  </ContentType>
</Elements>

Table 3: ContentType Node’s Attributes


ATTRIBUTE DESCRIPTION
ID Unique ID of the content type. This is required. For more information on content type IDs, refer to the note following this table.
Name The name of the content type. This is required.
Group Specifies the content type group that the content type will be added to. This is optional.

NOTE

For more information on the <ContentType> node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/aa544268.aspx.

Two things need some explanation in the preceding code snippet.

First, the content type ID is a unique ID that every content type requires. Every content type must inherit from another content type; no content type can exist without a parent. The first part of the content type ID (up to the third instance of 00) represents the ID of the content type’s parent. In the preceding code snippet, this is the Page content type that is created by MOSS when provisioning a new Publishing site. The latter part of the content type ID (00213FEEC23C37400bBEC425C10E76F37F) is what makes this content type unique from other content types.

NOTE

For more information on content type IDs (a complex subject), refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/aa543822.aspx.

Second, note that the <FieldRef> node’s ID and Name attributes are the same as the site column previously created. This is how a site column is added to a content type.

Provisioning Files with Features

Now that the site infrastructure components have been created and added to the Feature, the next step is to create the element manifest file that will provision the master page and page layout, each using a specific preview image. Create a new XML file in Visual Studio 2005 named ProvisionFiles.xml and save it in the AlternativeApproach directory.

Then, add the element manifest file to the Feature by adding the following code between the <ElementManifests></ElementManifests> tags, just after the existing <ElementManifest> tag in the feature.xml file:

<ElementManifest Location="ProvisionFiles.xml"/>

Next, add the following code to ProvisionFiles.xml that will provision the files when the Feature is activated. (Table 4 contains a list of the most common attributes used in the <Module> node, and Table 5 contains a list of the most common attributes used in the <File> node.)

<?xml version="1.0" encoding="utf-8"?>
<Elements >
  <!-- provision master page -->
  <Module Name="WROXMasterPages"
          Url="_catalogs/masterpage"
          Path=""
          RootWebOnly="TRUE">
    <File Url="ACminimal.master"
          Type="GhostableInLibrary">
      <Property Name="ContentType"
                Value="$Resources:cmscore,
                       contenttype_masterpage_name;" />
      <Property Name="PublishingPreviewImage"
                Value="~SiteCollection/_catalogs/masterpage/
                       Preview Images/wrox.jpg,
       ~SiteCollection/_catalogs/masterpagePreview Images/wrox.jpg" />
      <Property Name="Description"
                Value="Provisioned from the AlternativeApproach
                       Feature. "/>
    </File>
  </Module>
  <!-- provision page layout  -->
  <Module Name="WROXPageLayouts"
          Url="_catalogs/masterpage"
          Path=""
          RootWebOnly="TRUE">
    <File Url="AltApproachPageLayout.aspx"
          Type="GhostableInLibrary">
      <Property Name="ContentType"
                Value="$Resources:cmscore,
                       contenttype_pagelayout_name;"/>
      <Property Name="PublishingAssociatedContentType"
                Value=";#$Resources:cmscore,
contenttype_articlepage_name
;;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3D
B064584E219954237AF3900242457EFB8B24247815D688C526CD44D;
#"/>
      <Property Name="PublishingPreviewImage"
                Value="~SiteCollection/_catalogs/masterpage/
                          Preview Images/wrox.jpg,
                       ~SiteCollection/_catalogs/
                          masterpagePreview Images/wrox.jpg" />
      <Property Name="Description"
                Value="Provisioned from the AlternativeApproach
                       Feature"/>
    </File>
  </Module>
  <!-- provision preview image -->
  <Module Name="WROXPreviewImages"
          Url="_catalogs/masterpage"
          Path=""
          RootWebOnly="TRUE">
    <File Url="wrox.jpg"
          Name="Preview Images/wrox.jpg"
          Type="GhostableInLibrary"/>
  </Module>
</Elements>

Table 4: Module Node’s Attributes


ATTRIBUTE DESCRIPTION
Name Name of the file set. This is required.
Url Address of the folder, relative to the top-level Web in the site collection, where the files in the set will be provisioned. This is optional.
Path Address of the folder, relative to the Feature, where the files to be provisioned reside. This is optional.
RootWebOnly When set to True, the files in the set are installed only in the top-level Web within the site collection. This is optional.

Table 5: File Node’s Attributes


ATTRIBUTE DESCRIPTION
Url Path to the file. This is combined with the Path attribute in the parent <Module> node to determine the physical location of the file in the Feature. This is required.
Type When provisioning files, this should always be set to GhostableInLibrary. The other option, Ghostable, applies only to files that are not added to SharePoint libraries. This is optional.

In the preceding code snippet, notice that the master page is provisioned, followed by the page layout, and finally the preview image used by both files is added to the site. Each <Module> node contains at least one <File> node, which contains optional <Property> nodes.

Module Node Overview

The <Module> node, signifying a file set, contains a few attributes that define the common aspects of the file set. The Url attribute specifies the target SharePoint library where the files in the set should be provisioned. Path is the local, Feature-relative path where the files are located. In the case of the Feature in the preceding code, because all files are in the root directory, no path is necessary. If the master page and page layout were in the LayoutFiles directory within the Feature, Path would be set to LayoutFiles. The last attribute, RootWebOnly, specifies that the files are provisioned only in the top-level Web of the site collection the Feature is activated in. In the case of Publishing sites, RootWebOnly should always be set to True.

NOTE

For more information on the <Module> node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms434127.aspx.

File Node Overview

Modules are essentially file set groupings. Each <Module> node contains one or more <File> nodes. All files in a set will follow the directives set in the set they belong to, defined in the <Module> node. The Url attribute specifies the location of the file in the feature. This is combined with the Path attribute defined in the <Module> that contains the <File> node.

Although optional, the other attribute that should always be included in the <File> node is Type, which, when specified, dictates the file should be cached in memory on the SharePoint WFE server, regardless of the value. There are two possible values for Type: Ghostable and GhostableInLibrary. Ghostable is used when files are not stored in a library or gallery. In the case of a Publishing site, when provisioning files, this value should never be used because master pages, page layouts, images, CSS — they will all reside in a library in the top-level Web of the Publishing site collection. Therefore, always specify GhostableInLibrary here.

NOTE

For more information on the <Module> node schema, refer to the following MSDN documentation: http://msdn2.microsoft.com/en-us/library/ms459213.aspx.

Property Node Overview

<Property> nodes are contained within <File> nodes. These elements are used to specify the value of the fields within the SharePoint library the file is provisioned into. For example, for the master page and page layout files in the previous code snippet, three properties are specified:

  • ContentType — This value specifies the content type of the item. For master pages and page layouts, developers should use localized values. The master page localized value is $Resources:cmscore,contenttype_masterpage_name; and the page layout localized value is $Resources:cmscore,contenttype_pagelayout_name;.
  • PublishingAssociatedContentType — This is the content type that is associated with the page layout. The associated content type is the content type that defines the schema of the page. The value contains a delimited string which includes the name of the content type as well as the content type ID.
  • PublishingPreviewImage — This is the value where the preview image can be found. The field type of the PublishingPreviewImage field is of type URL. This explains why the preview image value is specified as a comma-delimited string with two values. One value is used as the description for the URL, and the other is used for the target. In the previous code snippet, the same address was used for both values, so content owners and administrators can easily identify where the image is located.

NOTE
The address of the preview image is pointing to the image that is provisioned at the end of the code snippet.

  • Description — This field is used to enter a user-friendly description of the file.

Notice that no properties are specified for the preview image provisioning. None are required, and in this demonstration, none were specified to simply add variation to the code snippet.

As with any process, there are advantages and disadvantages to using Features and solutions to implement a Publishing site’s infrastructure and layout files. Regardless of the advantages and disadvantages of this approach (which are discussed in Chapter 4, “Developing Publishing Sites The Smart And Structured Way,” of Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs (Wrox, 2007, ISBN: 978-0-470-17402-9). This is still the most preferred method in the development of a Publishing site.

This article is adapted from Professional Real World SharePoint 2007: Indispensable Experiences from 16 MOSS and WSS MVPs by Joe Duffy (Wrox, 2007, ISBN: 978-0-470-17402-9), from Chapter 4, “Developing Publishing Sites The Smart And Structured Way.”

Copyright 2007 by WROX. All rights reserved. Reproduced here by permission of the publisher.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read