Blog posts by Ben Morris

Using Google Mini as an EPiServer search solution

Tue, 28 Sep 2010 16:18:07 GMT

Google Mini can provide a low-cost alternative to Lucene-based searching in EPiServer. Although its text-based search is simple and powerful, the devil, as ever, is in the detail.

What Google Mini does

Google Mini is a stand-alone hardware unit that provides a configurable “Google in a box” on your network. It indexes site content by reading web pages and following links, deciding on page relevancy in much the same way as the real search engine.

A single Google Mini box can be used to provide search for any number of different sites. All the crawled content is kept in a central index and you specify any number of sub-sets of this index as collections, allowing for a rudimentary partitioning your search index. Google Mini also allows you to create different “front-ends”, which are a collection of client settings that include different keyword matches and synonyms.

It’s very easy to get up and running. All you do is point it at a website, wait for the content to be crawled and then start firing requests at it. The Google Mini API is simple enough, relying on a simple RESTful call to the device that can return a set of results as XML. Putting together an API abstraction to format requests and deserialize responses is a pretty trivial development task.

It’s important to bear in mind that Google Mini is still a bit of a “black box”. You can filter your search and adjust the way in which it indexes a site, but you cannot go in and directly tweak any of the indexed content. It merely reports back on what it sees and optimising your EPiServer page output for Google Mini is where the real work lies in an implementation.

Maximising page relevance

If you want your search results to make sense then it is incumbent on you to make sure that your page mark-up is optimised for search engines. As this is a Google-based engine, the normal SEO rules apply here. You need to ensure that your page structure is optimised for SEO and that your internal linking distributes page rank appropriately.

The amount of unique content in a page is also important – this is, one of the ways in which Google decides what a page is “really about”. Many page designs use a lot of boiler plate mark-up which is pretty much the same between every page, i.e. a large header, footer and side bar. With this kind of web design the amount of unique content between each page can be a relatively small proportion of the overall content.

One way of getting Google Mini to focus on the relevant content is to selectively render page content for the Google Mini device. You can assign a unique user agent string to the Google Mini so you can detect it when a page loads and choose which parts of the page to render.

Although this can be an effective way of optimising Google Mini indexing do not be tempted to selectively render content for external search engines. Google regards this as a spamming technique and it will penalise your site in the search rankings if it discovers that you’re sending out different content to search engine spiders.

Property-based search via meta-tags

Google Mini provides fantastic text-based search complete with all the richness and intelligence you’d expect from Google-based search. However, many websites require a search solution that provides more than just text-based searching. In particular, some level of filtering by specific page properties is often required.

There’s nothing to stop you using FindPagesWithCriteria() in some circumstances, but Google Mini does provide a meta-data catalogue that you can use to support property-based searching. You can publish any EPiServer property as a meta-tag and Google Mini will store these tags, allowing you to specify them as parameters for searches. The tags are also returned as part of the search result information for each page, allowing you to pick up information about a page without having to resort to the EPiServer data factory.

Ideally, you would only want to publish these tags to the Google Mini device rather than exposing details of your EPiServer implementation to normal website visitors. This is easy enough to accomplish given that you can assign a unique user agent string to the Google Mini device.

The Google Mini meta-tag catalogue does have some limitations as it will only store up to 1,000 characters and the only value data types it recognises are strings and dates. It can be used to support most simple property-based search scenarios, but if your requirements are for more sophisticated faceted search then you ought to be looking elsewhere for your search solution.

Custom sorting via meta-tags

By default, Google Mini only allows you to sort search results by relevance or the date on which the content was originally indexed. This isn’t enough for more specialised searches that may need to sort results by a particular EPiServer property.

The Google Mini meta-tag catalogue can be used to sort results, but you will have to construct a full result set first and then sort it manually. Given that Google Mini returns a maximum of 100 search results with each call this means making successive calls to the device to build up a large result before you can sort it. Once you’ve sorted the result set you should also consider caching it somewhere rather than suffering the overhead of having to re-construct it for successive pages of results.

This is not an ideal solution – it is, in fact, nothing more than a slightly dirty-feeling work-around. That said, it does work for simple sorting scenarios that do not involve more than a few thousand results. More demanding sorting scenarios may demand a different search technology.

Crawling meta-data on files in the VPP

Although Google Mini is very effective at crawling text-based content there is no way for it to pick up any meta-data associated with files in your VPP. It can index image and video files, but will only index the filename. If you have a large body of images and videos that have been described and categorised via file summaries then you will need a work-around to ensure that this information will be incorporated into search.

The solution that we used was to create an EPiServer page provider that reads a VPP and renders a web page for each file that contains the file summary information. These pages are only visible to Google Mini so if a user actually visits the page then they are redirected to the actual resource rather than the page provider page.

Again, this is a work-around, but an effective and flexible way of incorporating file summaries into your search index.

Duplicates on the master language branch

One problem that is specific to EPiServer and Google Mini is caused by the URL language selector on the master language branch. Google Mini will regard the following URLs as separate pages, even though the content is exactly the same.

www.example.com/mypage
www.example.com/en/mypage

To overcome this problem, Google recommend that you add a link tag specifying the canonical URL to the page’s header section. Although using a canonical URL can help, and is regarded as good practise in any event, we have found that it is not necessarily enough to guarantee that duplicate results will appear with a Google Mini.

Ultimately, if you want to be sure that duplicate pages on the master language branch will not appear in your results then you will need to filter them out of the Google Mini index – this is easy enough to do in the Google Mini crawl and collection settings.

Low-cost search, but beware of the implementation time

A Google Mini box requires a relatively small investment – a single unit costs only £2,400. This is cheaper than any licensed search solution for EPiServer but it does come at the cost of extra development work.

One advantage of a Google Mini implementation is that you will almost certainly be left with a site that is very heavily optimised for search engines. The need to define appropriate page titles and descriptions, think through your internal linking and tweak output for relevancy will pay dividends with your external search.

However, if your search requirements involve complex facets, extensive property-based sorting or more than a few hundred thousand pages then you may need to invest more heavily in your search technology.

Converting EPiServer 6 to use claims-based authentication with WIF

Wed, 16 Jun 2010 11:58:40 GMT

Claims and federated security are increasingly big news in enterprise architectures that seek to implement single sign-on across different domains and technologies.

This article describes how to modify EPiServer 6 to delegate authentication to a claims issuer as well as discussing the issues that have to be overcome to make it all hang together.

What is claims-based security?

Claims-based security is a means of de-coupling the whole process of authentication from applications and services. It’s a different way of looking at authentication – instead of users and roles being defined from a central location, you have the notion of claims that can be provided by a number of issuers.

Claims are statements made about users – for example their name, group or privilege – and they provide a much more flexible way of describing identity than a role-based model. For example, some claims issuers support the idea of private user identities, so an application can authenticate users without having to know any personal details about them. Claims effectively de-couple roles from authorisation logic, allowing for more finely-grained permission schemas.

In claims-based security, applications are no longer responsible for authenticating users and this role is delegated to Issuers. These issuers are completely separate systems that authenticate users and make claims about them, passing the claims to applications in the form of a signed and trusted token. This approach allows for greater flexibility in security configuration, as an application will expect to receive claims about a user, but they don’t care where these claims actually come from.

This gives rise to the notion of federated security, where users can be authenticated across different domains, organisations and technologies. In the Windows world this is supported by Microsoft’s Active Directory Federation Services, which allows Windows 2008 Server to act as a federation server and share identity with other security realms via tokens through a trust relationship.

The Windows Identity Foundation provides a programming framework that supports issuing and consuming claims in applications. It provides a model that allows ASP.NET applications to be easily converted to use claims-based authentication through HTTP.

How does this impact EPiServer?

The main impact that claims-based security has on EPiServer is that you are delegating responsibility for authentication and authorisation entirely to another system. EPiServer will not have any role in creating, managing or authorising users, nor will it have any direct access to any store of users and roles. It just accepts claims that have been created by an issuer and acts on them accordingly.

The diagram below shows [in grossly simplistic terms] the current EPiServer security model which involves EPiServer interacting directly with an authentication store via providers:

The diagram below illustrates [again, pretty simplistically] how EPiServer fits in to a claims-based model, where authentication takes place in a separate system that EPiServer does not have any direct access to:

From a technical point of view, adapting an EPiServer site to claims-based security involves several major changes:

Forms authentication is not used – it is turned off in web.config.
Authentication takes place much earlier in the HTTP pipeline – a couple of HTTP modules are added to authenticate a user at the start of the page request cycle and re-direct them to an issuer if they are not authenticated.
The membership and role providers do not have any role to play in authentication – everything is handled by an external claims issuer.

Setting up EPiServer to use a token service

Setting up an EPiServer 6 site for claims-based authentication with WIF only requires a few tweaks of the web.config file.

You will need a security token service to connect to and you can mock one up if you have installed the Windows Identity Foundation SDK - this article explains how to set up a simple security token service using Visual Studio 2008.

To make an EPiServer application claims aware, a new configuration section needs to be added to the configSections element:

<configSections>
  ...
  <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>

Next, you need to switch off forms authentication and deny access to the site:

<authentication mode="None"/>
<authorization>
  <deny users="?"/>
</authorization>

The two HTTP modules that perform the authentication should be added to the system.webServer\modules section:

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    ...
    <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </modules>
  ...
</system.webServer>

Next, you configure the Identity Foundation itself by adding a microsoft.identityFramework element into the end of your configuration section:

<microsoft.identityModel>
  <service>
    <audienceUris>
      <add value="http://EPiServer6Site/"/>
    </audienceUris>
    <federatedAuthentication>
      <wsFederation passiveRedirectEnabled="true" issuer="http://SecurityTokenService/" realm="http://EPiServer6Site/" requireHttps="false"/>
      <cookieHandler requireSsl="false"/>
    </federatedAuthentication>
    <applicationService>
      <claimTypeRequired>
        <claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" optional="true"/>
        <claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" optional="true"/>
      </claimTypeRequired>
    </applicationService>
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <trustedIssuers>
        <add thumbprint="575BC741AAE8F063DD76615EE8152879B3C0F5EA" name="http://SecurityTokenService/"/>
      </trustedIssuers>
    </issuerNameRegistry>
  </service>
</microsoft.identityModel>

Finally, just to demonstrate that claims are really driving authentication, you can disable the membership and role providers by replacing the membership and role declarations in the system.web section with the following:

<system.web>
  ...
  <membership>
    <providers>
      <clear/>
    </providers>
  </membership>
  <roleManager enabled="false">
    <providers>
      <clear/>
    </providers>
  </roleManager>
  ...
</system.web>

This is all you need to do to get EPiServer up and running with claims. When you try to access your site you will be re-directed to your security token service website where you will submit your credentials. Once the security token service has logged you in then you’re re-directed back to EPiServer with a set of claims.

Inevitably, there are some catches…

On the surface, things work quite smoothly as claims authentication provides an identity object that implements the IPrincipal interface, so the EPiServer API seems to play nicely with claims-based credentials.

However, things get more tricky with the EPiServer UI, mainly because EPiServer expects direct access to the authentication store through the role and membership APIs, making a number of direct calls to them. Once role and membership providers have been taken out of the equation then a fair amount of the functionality in the EPiServer UI either becomes redundant or just plain fails.

The details of how you would solve these UI issues depend very much on the nature and type of claims that your are receiving from your issuer, but there are two main issues to solve.

Firstly, when assigning access right to content in EPiServer, a call is made to a role provider for a list of all the currently available roles. If you want to be able to assign access rights for content and features to roles that are returned by claims then you will need to create a custom role provider for EPiServer that supplies a list of all the valid roles that your claims issuer is likely to use.

The exact implementation of this custom role provider would depend on the number of roles, the source of roles and the frequency with which they are likely to change. Whatever the approach, there is no getting away from having to create some kind of custom role provider to serve a valid list of roles to the EPiServer UI.

The second issue is that EPiServer exposes a lot of functionality that is no longer available in a claims-aware application – e.g. creating and managing users and groups. In some cases – such as the log-out button – this functionality will just fail, while in other cases it will fail with some pretty ugly exceptions.

Again, the solution to this depends on circumstances and your users’ tolerance for a slightly flakey UI. You can resolve this issue either by educating your users (difficult, but straightforward), customising the EPiServer UI (clever, but risky) or by creating “dummy” custom providers that return empty results for every significant method (dirty, but effective).

Summary

Although EPiServer does not provide direct support for claims-based security, the fact that its security model is pluggable and closely aligned to ASP.NET’s standard design patterns means that, with a bit of tweaking, you can get an EPiServer-based site to be claims-aware.

However, the devil is in the detail – or the EPiServer UI – and you will probably need to do some work with custom role and membership providers to deliver a solution. The exact details of these would depend on the nature of the claims that you are receiving and the authentication store that they are coming from.

Implementing Dublin Core meta data for EPiServer pages via a plug-in

Fri, 12 Feb 2010 13:00:00 GMT

Dublin Core is in heavy use in the UK public sector – anybody who has had to complete an RFP document for a UK public sector customer will be familiar with questions regarding your proposed CMS platform’s support for it.

Dublin Core is a meta data standard that is used to describe resources across different platforms and technologies in a way that makes them easy to find. It’s an XML-based resource description format that is used to describe a wide range of resources, including video, images, text and – perhaps most commonly – web pages.

The Simple Dublin Core Metadata Set (DCMES) is composed of a list of fifteen separate elements which include simple descriptive items such as title, creator, subject, description and creation date. These basic elements have been extended to include a number of other tags and qualified with a set of recommended encoding schemes, such as ISO8601 for date formats. Dublin Core is implemented on web pages as a set of meta tags that conform to the published Dublin Core schema, although the mixture of tags used tends to vary considerably between different sites.

A typical set of Dublin Core tags look something like the example below:

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<meta name="DC.title" lang="en" content="Home page" />
<meta name="DC.creator" content="Ben Morris" />
<meta name="DC.publisher" content="Acme Corporation" />
<meta name="DC.date" scheme="ISO8601" content="2010-04-23T16:27" />
<meta name="DC.type" scheme="DCMIType" content="Text" />
<meta name="DC.format" scheme="IMT" content="text/html" />
<meta name="DC.identifier" content="/dublin-core-meta-data-plug-in-for-episerver-pages/" />
<meta name="DC.language" scheme="RFC1766" content="en" />
<meta name="DC.coverage" content="World" />
<meta name="DC.rights" content="/terms-and-conditions/" />

The content for all of these tags can be easily generated from EPiServer – this post explains a technique for developing an EPiServer plug-in that will automatically insert Dublin Core meta tags to EPiServer pages that can be dropped in to an existing site without requiring any code changes to your site or templates.

This plug-in works via an http module, which intercepts requests for EPiServer pages immediately after the content has been processed, formats a set of meta tags based on the page’s EPiServer properties and inserts the tags just before the end of the page’s </HEAD> section. A code sample of the whole thing can be downloaded from here (ZIP archive, 7KB), but the following is an explanation of the mechanics.

Creating the http module

An http module allows you to hook into a number of events that are raised during the http request cycle. The event that we are interested in here is the PostRequestHandlerExecute event, which occurs just after the page has finished execution and the HTML content is ready to be sent back to the browser.

Creating an http module is pretty straightforward – you create a class that implements the IHttpModule interface and register it in web.config. This interface requires two methods: Init(), where you hook up any events that you want to execute code on, and a Dispose() method to clean up any resources that you have used.

The code sample below shows a basic module that hooks into the PostRequestHandlerExecute event.

using System;
using System.Web;
using EPiServer;
using EPiServer.Core;

namespace EPiPlugins.DublinCore
{
    public class DCHttpModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            //* Subscribe to PostRequestHandlerExecute
            context.PostRequestHandlerExecute += new EventHandler(context_PostRequestHandlerExecute);
        }

        public void context_PostRequestHandlerExecute(object sender, EventArgs e)
        {
            //* Do some work...
        }
    }
}

The event handler for the PostRequestHandlerExecute event will have to do the following work:

Get the current application context – this will give you access to the Request and Response objects.
Check that the current URL refers to an EPiServer page and ignore everything else (note that every request handled by ASP.NET will pass through your http module – this includes javascript files, images and style sheets).
Get the PageData object for the current page.
Format some Dublin Core meta data on the basis of the PageData object.
Filter the out-going response in order to insert the meta data.
The basic outline of this event handler will look something like this:

public void context_PostRequestHandlerExecute(object sender, EventArgs e)
{
    if (sender != null)
    {
        //* Get the application reference - this allows us into the HttpContext
        HttpApplication senderApp = (HttpApplication)sender;

        //* Only process aspx pages
        if (senderApp.Context.Request.Url.AbsoluteUri.IndexOf(".aspx", StringComparison.InvariantCultureIgnoreCase) >= 0))
        {
            //* Try to get a page reference from the URL
            PageReference currentPageRef = PageReference.ParseUrl(senderApp.Context.Request.Url.AbsoluteUri);

            //* If there's no PageReference then this is not a request for an EPiServer page, so ignore it
            if (currentPageRef != PageReference.EmptyReference)
            {
                //* Fetch the page data
                PageData thisPage = DataFactory.Instance.GetPage(currentPageRef);

                if (thisPage != null)
                {
                    //* We have page data - format some Dublin Core tags based on the page data
                    string tags = FormatTags(thisPage);

                    //* Apply the DCStream filter to the response and it will insert the Dublin Core meta tags
                    senderApp.Context.Response.Filter = new DCStream(senderApp.Context.Response.Filter, tags);
                }
            }
        }
    }
}

Creating a stream wrapper class to filter the content

Note that at the end of the PostRequestHandlerExecute event we set the Filter property of the current Response object to a new instance of a class called DCStream. This is where we wrap the http response stream into a custom object that allows us to modify the entire response before it goes to the client.

The DCStream class is a wrapper around the Stream object that manages an internal representation of the response stream, inserting the Dublin Core tags via an over-write of the Write() method as shown below:

public override void Write(byte[] buffer, int offset, int count)
{
    string strBuffer = System.Text.UTF8Encoding.UTF8.GetString(buffer, offset, count);

    //* Look for the closing HEAD tag
    int insertionPoint = strBuffer.IndexOf("</head>", StringComparison.InvariantCultureIgnoreCase);
    if (insertionPoint >= 0)
    {
        //* Add the Dublin Core tags in to the content
        strBuffer = strBuffer.Insert(insertionPoint, _DCTags);
    }

    //* Look for the closing HTML tag
    if (strBuffer.IndexOf("</html>", StringComparison.InvariantCultureIgnoreCase) < 0)
    {
        _ResponseHtml.Append(strBuffer);
    }
    else
    {
        //* Transform the response and write it back out
        _ResponseHtml.Append(strBuffer);
        string finalHtml = _ResponseHtml.ToString();
        byte[] data = System.Text.UTF8Encoding.UTF8.GetBytes(finalHtml);
        _ResponseStream.Write(data, 0, data.Length);
    }
}

Adding your http module to web.config

To get your website to pick up the http module you need to add a reference to it to your web project and then add a declaration into the system.webServer/modules section of your web.config file. This declaration will look like this:

<add name=”DCHttpModule” type=”EPiPlugins.DublinCore.DCHttpModule, EPiPlugins.DublinCore” />

Configuration

Not every field in the Dublin Core set has a direct equivalent in the EPiServer PageData object, so you will need to map some of the fileds onto EPiServer page properties. You may want to map the Dublin Core “description” element onto a specific EPiServer property that will be present on all EPiServer pages, or assert a particular copyright message for the “rights” element for every page.

There are a number of ways to implement this kind of configuration – I have used a custom configuration section in my code example that lets you define your own section in the web.config file.

Code sample

You can download a full working sample of the code from here (ZIP archive, 7KB).

Bear in mind that this code is a proof of concept rather than a match-fit piece of production code.

Note that the references for the sample project are set to EPiServer 6 DLLs (v 6.0.530), but it works on EPiServer 5 too.

Social Media Gadget for EPiServer 6 CTP2

Mon, 09 Nov 2009 15:20:23 GMT

Here’s my entry for the EPiServer gadget contest.

It’s a social media gadget – you can use it to track what’s being said about your site, brand or business through a number of different channels, including Twitter, Google blogs search, Google news search and Flickr.

It’s designed to be as easy as possible to set up and use. It gets feeds from the public methods from the Twitter, Google and Flickr APIs so you don’t have to mess around entering API keys to get it to work. You just enter a key phrase in the setup screen and you’re away.

Installing the gadget

I have put together an installer that can be used in the EPiServer Deployment Centre. It will install all the necessary files in an EPiServer 6 CTP 2 website as well as adding in the necessary entry to web.config.

The installer can be downloaded from here (zip archive, 42kb).

The source code is also freely available - setup instructions are included in a readme.txt file in the root of the project.

The source code lives here (zip archive, 90kb).

Developing EPiServer page providers: optimizing performance

Mon, 12 Oct 2009 15:26:22 GMT

The how-to of EPiServer page providers is covered in a variety of places - the best place to start is EPiServer's white paper on the subject which contains an XML-based page provider sample. It all looks simple enough from the outset, but it's only once you start developing implementations for "real-life" data sources that you realise how much coding is involved in a page provider implementation. Given that the feature is relatively new, there doesn't appear to be too much explanation over what really goes on under the hood and how to develop with efficiency and scalability in mind.

Having developed providers for relatively large (10,000+ records) data sources, the following are some suggestions for things to bear in mind when developing your page provider.

Understanding what EPiServer caches - and what it doesn't

EPiServer relies very heavily on the cache for performance, but it's important to understand when EPiServer uses the cache and when it will attempt to query your provider's data source. Once you have constructed a page in your provider's GetLocalPage() method it will be placed in the EPiServer page cache and served from memory from then on. However, there are still a number of instances where you will need to refer to the underlying data source - this happens more often than you might think:

EPiServer caches page content, but it does not cache the content structure, i.e. the arrangement of parent and child pages. This means that the structure is constantly re-queried as you access pages, even if the page content is sitting in the page cache.
If you are looking at a page in edit mode then EPiServer does not retrieve the cached version of a page - it constructs the page from scratch every time.
If you want to provide property-based search on your page provider then you will have to implement FindPagesFromCriteria() yourself and plumb the criteria directly into your data source.
Any page updates will, of course, have to be routed back to your data source.

Despite the aggressive page caching, EPiServer does reference the data source for pages pretty regularly - i.e. every time you show a menu or do a search you will be hitting the data. This is worth bearing in mind if you access your data source via a relatively expensive operation such as a web service method.

The importance of an optimised data store

Given the fact that a page provider requires constant access to the data source, it's worth caching the data in a structure that is optimised for the kinds of search operations that EPiServer will perform on it. The structure of your cached data is vital for effective provider performance - it is worth doing some performance tests to ensure that you've got the optimum structure for the following types of page search (in descending order of frequency):

Searching for a page based on a page reference - this is by far the most common
Searching for a page based on its parent's page reference
Finding a page based on its GUID
Property-based searches using FindPagesWithCriteria() - if you're implementing search.

For a very large data set, my solution was to cache the data source by encapsulating the underlying data for a page in a class and using a generic dictionary to store the data, with a PageReference being used for the key, i.e.Dictionary<PageReference, MyPageClass>. This structure provides for super-fast searches pages based on a PageReference, while other, less frequent searches can be carried out in reasonable time using Linq.

Caching your data source in an optimised data structure does break the direct link between EPiServer and the data source, but in cases with large amounts of page data served by slow interfaces it is pretty necessary. You are also creating processing overhead when you create your cache - this can be mitigated by caching the structure and refreshing it periodically through a scheduled task.

GUIDs and unique IDs

In order to support EPiServer's internal linking you will have to maintain a permanent mapping between each page served by your provider, a unique integer-based ID and a unique GUID. If your data source provides the ID and GUID values then you're in luck, otherwise you will have to develop a mechanism that creates these unique ID and GUID values and persists them against a page.

There are no short-cuts to creating a GUID for every page. The EPiServer community has suggested a Guid-less provider as a solution to creating GUIDs for every page, but given that this involves hacking the bits in a GUID it is not recommended for live systems as it undermines the whole point of GUIDs - i.e. that they should be unique.

This requirement for persisting ID and GUID values makes the idea of a pattern based on an optimised data structure even more attractive on performance grounds. Ultimately, you are likely to be storing these values in a database table, so caching them in memory through your optimised page structure will save you an untold number of unnecessary data reads whenever EPiServer tries to look up a GUID on the basis of a page ID and vice versa.

Cache the page references, not the IDs

The golden rule with page providers is to always work with PageReference objects, never with the raw integer-based ID values. EPiServer constructs a page reference from a combination of the provider name and unique identifier for the provider - the ID value itself is not unique across a website.

If you want to compare page identifiers then you must use the base class's ConstructPageReference() helper method to form a PageReference before performing the comparison. The over-head of always having to construct a PageReference may appear small, but over thousands of repetitive operations it does start to add up. It makes a lot of sense to cache the PageReference for each individual page to save yourself countless method calls.

Consider providing read-only access

Adding support for creating, updating and deleting content doesn't necessarily have to impact on the performance of your provider. After all, page updates are comparitively rare operations so you can afford to suffer a performance hit on updates in order to maximise the performance of read operations.

That said, there's no point writing more code than you really have to. In order to save yourself the development overhead of writing in the plumbing for updating your data source it's worth taking a long, hard look at whether or not you really need to provide data updates through EPiServer. The key question here is what role is EPiServer playing in your information architecture, i.e. is it there primarily to publish web content? Most optimisation scenarios don't necessarily need a two-way page provider integration as other systems take responsibility for managing the life cycle of of the underlying content.

Security descriptors

EPiServer's XML Page Provider sample contains an interesting custom security descriptor pattern. This allows the security settings for each page to be set by the data source and passed in to each individual PageData object when they are created.

Managing the security settings for each individual page in your provider can be quite an overhead. If an individual page does not have an ISecurityDescriptor object defined for it then it should check the parent page for the security information.

This overhead may be unavoidable, but if you are applying the same security settings across every page in your provider then it is worth caching a custom security descriptor in your provider and applying it to every page. This does provide a considerable performance boost as you are not having to do the work of checking parent pages to find and apply security settings.

Making life easier for editors

When you are serving up thousands of pages in flat, single-level structure, this can provide real performance issues for content editors. When you click on a node in EPiServer, it will query the structure below that node and for the level below that - which is quite a lot of work when you have 10,000 pages. If a user accidentally clicks on a node containing thousands of provider pages then they will have a long wait on their hands while EPiServer populates the page tree.

This does call for some automatic sorting for your provider content if you are serving up more than 500 pages through a provider. If you are constructing a cached content structure then you can also write in a system of category pages for the provider - sorting pages into at least two levels in this way will help to protect your content editors from some very frustrating load times.

The caveat - search

Finally, a warning: EPiServer's text-based search does not work with page providers. This makes sense when you consider how EPiServer's search works, but it does have a big impact on your site. If you are going to make heavy use of page providers then you will also have to consider implementing a third party search solution if you want your provider content to be included in a site-wide text search. Spider-based solutions such as Google Mini will do the job here, but you are adding cost and complexity to your project.

Adding new languages to EPiServer 5

Fri, 02 Oct 2009 19:20:37 GMT

We’ve recently run into problems with adding the less commonly-used language and locale combinations on an EPiServer installation. How do you add a new language to EPiServer 5 if it doesn’t appear in the list of available languages?

EPiServer takes the list of the languages that you can enable for a site from the languages that are installed on the host operating system. This can be a problem as the available languages can vary between different machines - for example, Indian English (en-IN) is shipped with Vista but not with Windows 2003 or XP. The big catch is that if you have a language enabled in your EPiServer database which is not installed on your target machine then EPiServer will throw an exception on start-up, which will pull your whole site down.

If you want to add a new language to EPiServer then you will have to install it on your operating system. This can be done via the CultureAndRegionInfoBuilder class in System.Globalization. This class allows you to create a new language from scratch or by copying it from an existing language, although you will have to run the code in the context of an Administrator account for it to work.

The code sample below shows how CultureAndRegionInfoBuilder can be used to create and register a new language based upon an existing language – in this case creating Hong Kong English (en-HK) from UK English (en-GB). Note that you’ll need a reference to sysglobl.dll in your project for this to compile.

public static void CreateCulture()
{
    //* Get the base culture and region information
    CultureInfo cultureInfo = new CultureInfo("en-GB");
    RegionInfo regionInfo = new RegionInfo(cultureInfo.Name);

    //* Create the a locale for en-HK
    CultureAndRegionInfoBuilder cultureAndRegionInfoBuilder = new CultureAndRegionInfoBuilder("en-HK", CultureAndRegionModifiers.None);

    //* Load the base culture and region information
    cultureAndRegionInfoBuilder.LoadDataFromCultureInfo(cultureInfo);
    cultureAndRegionInfoBuilder.LoadDataFromRegionInfo(regionInfo);

    //* Set the culture name
    cultureAndRegionInfoBuilder.CultureEnglishName = "English (Hong Kong)";
    cultureAndRegionInfoBuilder.CultureNativeName = "English (Hong Kong)";

    //* Register with your operating system
    cultureAndRegionInfoBuilder.Register();

}

Once you’ve run this code, fire up EPiServer in Admin mode, select Manage Web Site languages from the Config tab, click on Add Language and your new locale will be ready to use.