Custom Web Part Pages in WSS (Part 2)

Following on from Part 1, we will create a custom content type for a Web Part Page for use in a Pages library that supports versioning and is able to be crawled by WSS Search…

Creating a new Site Column

The page body for the custom web part page is to come from a new custom site column, imaginatively called Page Body.  This should be configured to be of type Multiple lines of text and allow Enhanced rich text as shown below:

Note: the Allow unlimited length in document libraries option must be set to Yes.

Creating a new Content Type

The next step is to create a new Custom Web Page content type to be used for the custom web part page; this content type will allow for the page’s content to be stored within the page rather than in a web part:

Create a new Document Library

Add a new Document Library to the WSS site; use Web Part Page as the document template and ensure that versioning is switched on:  

Once this has been created, update the document library settings to use content types via the Advanced settings page.  

Then add the Custom Web Page content type to the library:

On the document library settings page,  click on the link for the Custom Web Page content type to open the List Content Type configuration page.   Add the Page Body site column using the Add from existing site of list columns link:

 

Finally, remove the default Document content type from the list of content types for the library.

As this point the document library settings should look like this:

Update the WSS Web Part Page templates

The final step to complete is to update the WSS Web Part Page templates to make use of the new Page Body column and display the content.  

To do this, simply add the following code to the template in the location you want the content to be displayed, e.g. within the content area with ContentPlaceHolderId=”PlaceHolderMain”:

<tr>
  <td class="ms-pagebody" colspan="3" valign="top" width="100%">
    <SharePoint:ListItemProperty Property="Page_x0020_Body" runat="server"/>
  </td>
</tr>

Of course nothing is ever *that* simple.

WSS ships with eight Web Part Page templates located in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\STS\DOCTEMP\SMARTPGS folder.  These files, named spstd1.aspx through spstd8.aspx cannot be renamed as they are used by the spcf.aspx page which serves as the document template for Web Part Pages.

Note: if you edit these templates you will be editing them for all Web Part Pages on that server, so bear this in mind.

Alternatively, create a new page template and associate it with the Custom Web Page content type created earlier.  This is done by specifying a new document template to replace spcf.aspx: open the content type definition for Custom Web Page, select Advanced Settings and then enter the location of the new document template:

The new document template must replicate the features of spcf.aspx, i.e. create a new instance of the page template.  

In WSS 3.0, the functionality for this has been moved from embedded code in the aspx page to the owssvr.dll assembly.  Unfortunately this assembly expects the page templates to be named spstd1.aspx through spstd8.aspx.  So you’re left with editing the default pages or attempting to replicate the entire functionality yourself.  

Apparently it is possible to make use of a file written for WSS 2.0 to do this.  Instructions are to be found on MSDN here.  Ignore references to editing create.aspx; we’ve already associated the custom document template with the content type.  Just follow instructions 1 through 6 in the Adding a new Template section.

Using the Custom Web Part Page

Use the Create buttom on the document library task bar as normal.  Select the Web Part Page layout from the standard eight available with WSS.  

To add HTML content to the page, use the context menu for the page to select Edit Properties …

…and then enter content into the Page Body field:

The Page Body field will be rendered as HTML on the page:

Any HTML content added to the Page Body field will be versioned…

…and crawled for searching via the standard WSS Search.

Install and Configure Telerik RadEditor for MOSS Lite Edition

Whilst not necessary to provide versioned and searchable pages, the RadEditor is recommended as a superior HTML editor.  If deployed, ensure that the RadEditor feature is enabled for list items:

The Lite Edition of the RadEditor for MOSS can be downloaded free of charge from Telerik.

Custom Web Part Pages in WSS (Part 1)

Okay, so WSS 3.0 doesn’t have the nice publishing features available with MOSS 2007.  However, there are a few things that we can do to improve upon the Web Part Page available out-of-the-box with WSS.

This series of posts will guide you through the process of creating a content type for an enhanced Web Part Page that can be versioned within a document library, searched using WSS Search and takes advantage of the Telerik RadEditor Lite content editor.

Background

To place these posts within context, I’d recommend reading this blog article by Tuen Duynstee.  Tuen’s article was really my starting point for creating an internet-facing WSS 3.0 site.

Now to the fun stuff…

Problems with WSS Web Part Pages and the Content Editor Web Part

The most obvious way to provide users with a Web Content Management system using WSS is to drop the Content Editor Web Part onto a Web Part Page.

Unfortunately there are several serious issues with this approach:

1. Content Editor Web Part content isn’t versioned.  You can create as many versions the web part page as you like, the actual content – which is contained within the Content Editor Web Part – isn’t versioned.  This is a wider problem with web parts in general, but especially of note when attempting to provide web content management.
2. Content Editor Web Part content can’t be searched.  Yes, this is as bad as it seems.  Add your content to the Content Editor Web Part and it can’t be seen by the WSS Search.

 

There is another issue with the Content Editor Web Part; whenever you re-open the web part to update content it turns all server-relative URLs into absolute URLs.  Therefore if you have your content accessible from different addresses (when you have an extranet and an intranet for example) any linked content will be broken for one of them as soon as anyone updates the content.  The only way around this is to edit the HTML directly.  Hardly suitable for non-technical users.

Solution

In a nutshell: create a Content Type to contain the web content within the page itself and make use of the superior Telerik RadEditor Lite content editor.

Stay tuned for the step-by-step guide on how to do this in Part 2.

Internet-facing WSS Sites – redirecting anonymous users

Most internet sites are aimed at anonymous users which causes a few problems if your site is built using Windows SharePoint Services 3.0.  The anonymous user settings for a WSS site contain the following options:

Entire Web site permits anonymous users to browse the contents of your web site, including such behind-the-scenes pages such as View all site content.  (You can try this for yourself, just browse to most WSS (and MOSS 2007) internet sites and add /_layouts/viewlsts.aspx to the URL of the site.  Clearly this isn’t good.)

Lists and libraries on the other hand allows each individual list or library on the site to specify whether or not anonymous users are permitted to view its contents.  Much better, I’m sure you’ll agree.

However there is one major problem with the Lists and libraries option which becomes apparent very quickly: anonymous users cannot access the default page of the web site.

The default page for a WSS site is <site>/default.aspx and this cannot be changed using the SharePoint user interface (unlike MOSS).  This page is special as it’s not contained within a library, as such, cannot be made available to anonymous users when using the Lists and libraries option.

Solution

A solution to this problem involves writing an HTTP Module to redirect anonymous users to a page within a document library that has anonymous access turned on. 

HTTP Modules seem to strike fear in the hearts of some developers, however this one is very easy:

namespace AccessControl
{
  public class AnonymousPageRedirector : IHttpModule
  {
    public void Init(HttpApplication context)
    {
      context.PreRequestHandlerExecute +=
        new EventHandler(context_PreRequestHandlerExecute);
    }
    void context_PreRequestHandlerExecute(object sender, EventArgs e)
    {
      // if no path is specified in the request
      if (HttpContext.Current.Request.Url.AbsolutePath.Equals("/",
         StringComparison.InvariantCultureIgnoreCase)
         && !HttpContext.Current.User.Identity.IsAuthenticated)
      {
        // redirect unauthenticated users to the custom welcome page
        HttpContext.Current.Response.Redirect("/Pages/Welcome.aspx", true);
      }
    }
  }
}

This piece of code checks if an anonymous user is attempting to access the site without specifying a target page, and therefore would be otherwise be directed to the unreachable default.aspx page, and instead redirects them to a welcome page within the Pages document libary.

To deploy, drop the dll into the GAC and then add the HTTP Module to the web.config of your WSS site by adding the following to the <httpModules> section:

<add name="AnonymousPageRedirector"
  type="AccessControl.AnonymousPageRedirector,
    AccessControl, Version=1.0.0.0, Culture=neutral,
    PublicKeyToken=<your public key>" />