Teun.ToString()

Recently, I have been working on a project where we created a fairly straight-forward web site for anonymous use on the internet, using WSS 3.0 as our platform. In earlier versions of the sharePoint product, this was not possible, as it did not (really) support anonymous use and the only authentication scenario was using windows user accounts. This restricted the use of SharePoint to a strictly Windows Intranet environment. The latest version of the product, however, allows for anonymous access and as it is built on top of ASP.NET 2.0, you can create your own authentication mechanism using a standard web form for login. Microsoft promotes the use of the (not very cheap) Microsoft Office SharePoint Server 2007 (MOSS) version for use on internet sites for content management, but we figured that for very simple sites, using the free WSS version would be sufficient. This article details findings in this project.

The approach

We imagined that a simple site would require only the following features:

• a custom look & feel, using a custom masterpage and stylesheet
• a document library containing web part pages
• an image library containing the images
• maybe some specific lists for use in the site (News, Events)

Anonymous access and logon style

In our situation, most users of the web site would never log in, but would just browse the site and maybe download some documents. Logging in was only necessary for content managers when adding or changing content. We decided to use Windows authentication for the content managers, but select 'Allow anonymous access' to allow all other users to access the site without logging in. This can be configured through Central Administration under Application Management | Authentication Providers. Obviously, anonymous access must also be enabled on the IIS web site and on the SharePoint site level.

Using web part pages for content management

The solution of placing web part pages in a document library and use this as a simple content management environment worked very well. By using versioning, you can have content managers work on pages while anonymous users still only see the last major version (you can set this up through Document Library SettingsVersioning Settings, see image below). You can even have approval required on the library. In our project we did not even use the concept of versioning and have the content managers work directly on the visible pages online. This causes some risk, of course, but in many environments this will meet the requirements and the possible confusion of having multiple versions would not be worth it.

For our site, we wanted to have a specific layout of zones in the web part pages. To do this, we created a custom content type, deriving from WebPart Page and a custom version of spcf.aspx. This is the screen where you can specify the name of your web part page and select a template from a list. For our custom type of web part page, we wanted to have only our specially designed zone layout available, including a thumbnail of our site design to go with it. Then we specified that our 'pages' document library could only contain our custom content type and voila: the library would only show our type in the 'New' menu and this would take you to our custom version of spcf.aspx. The only disappointment here was that it turned out impossible to create web part pages from a different file name than the existing spstd1.aspx to spstd8.aspx, so we had to replace one of these with our own.

Web Page Metadata

In internet sites, search engine visibility is always important. Most important of course is to be linked to by others, but the metadata in the pages can also help. This includes:

• a meaningful URL: this is pretty O.K. using WSS. A typical URL looks like www.sitename.com/pages/ProductSepcifications.aspx
• Keywords and Description meta tags: we created a custom control to include these in the page header based upon a site wide value that could be managed through Site Settings

Menuing

For navigation, our site used the standard structure of a top links menu and a quick links menu. The rendering of these was done with a custom control that rendered more tidy HTML than the standard Microsoft controls did. Maintaining the menu and it's URLs had to be done manually.

Drawbacks

Preview

Content managers like to have preview functionality. "Show me the page as visitors will see it". This feature is hard to accommodate. You can open a browser wihout logging in and view the page in this browser to check, but if anonymous users cannot even see the page while it has not been published yet, even this approach will not work.

Downloading Office documents

When you offer MS Office documents for download from the site, the Office tools on the client will recognize the SharePoint site as such and will ask the user to login for online editing. Even though the download is perfectly possible without logging in (hit escape), the login box will scare users away. This problem can be resolved mostly by turning off 'Client Integration' for the web application (same screen as allowing anonymous acces, see above). Sadly, even with this feature turned off, some configurations of browser and Office versions will still show the login box. The work-around we found is to remove the OPTIONS verb from the HTTPHandler registration in web.config (yeah, it's a dirty hack).

No master page picker or style library

These features are available in MOSS, but not in WSS. Both where implemented by having a WSS Feature called "Design" that included:

• Master page
• Stylesheets, images, deployed to a special folder under _layouts
• Default master change on activate/deactivate: activating the feature would set the default master of the site to our custom master page

This worked really well. Once the solution is handed over to the customer, the design can be turned on or off per site. When a change in the design is required, a new version of the Feature is deployed, updating the design in all sites using it. Selecting master pages by content managers is only confusing, really.

HTML editor

The HTML editor in both Rich Text fields in lists as in the Content Editor Web Part is very limited. It has no real functionality to clear out garbage HTML resulting from copying Word content and worst of all: you cannot select images from Image libraries or directly upload them. The only option in the "insert image" dialog is to manually enter a URL. For most systems this is really not acceptable. We created a small fix for the Word content, but decided to go live without image integration. Presumably, vendors like Telerik will provider better editors soon. I might even provide one myself some day.

Search results uses application.master

The search results page for some reason does not use the default master page of the site, but the application.master. This results in a results page that does not fit in with the rest of the pages. We decided to pull a quick hack here, updating searchresults.aspx to use our custom master instead, but a definite solution here has still to be found.

Performance

I have not performed stress tests, but the performance of the product could in my opinion be better. One of the features offered by MOSS is output caching. I am not sure how hard it would be to add such functionality to a WSS site.

Conclusion

All in all: when requirements of a web site are fairly simple, WSS 3 is very suitable as a web site platform. It allows to customize the look and feel reasonably well and anonymous access seems to work fine. WSS brings some of the flexibility of the SharePoint platform to the realm of internet presence sites. Add a new field to the list of news items on the home page and sort on this? Content manager can do it! All of the requirements for a full blown content management platform (autorization, versioning, flexible content types, workflows, ...) are built in. Most of them, however, lack a user interface.

Labels: sharepoint