I needed to throw together a quick geolocalisation demo for EPiServer v5 R2 the other day and to do that it was necessary to override some of the default URL rewriting behaviour of EPiServer. I knew it could be done, but I'd never actually had to write a custom URL provider before, so Ted Nyberg's blog post on rewriting in EPiServer gave me a good kick-start.

My geolocalisation changes worked a treat (maybe I'll blog about that another time) but I did come across one really nasty 'feature' in EPiServer. I did find a workaround though, so I'll share it with you. Some background first though.

As you may know, EPiServer has the nice ability to add a file extension on to pages. Before you rush off and try this out on your live site, be aware that it does change the default behaviour a little, for example it stops trailing slashes from working on the URL, e.g. this works:

http://myepisite/SomePage/

...but this does not...

http://myepisite/SomePage.htm/

In fact, I like this feature because when using an external cache provider (such as Akamai), page extensions are A Good Thing as it knows how to treat them, and it also reduces the number of a URL 'possibilities' for a single page, so reducing the cache usage. As a bonus, it can also help with security as it slightly abstracts the page engine from the URL. Why not use the extension 'cfm' and then watch and laugh as all the ColdFusion-specific attacks roll in :)

So I set an extension on my geolocalisation demo of '.htm' (done in the urlRewriteExtension property of the site settings element in Web.Config, make sure you put the dot in the extension as well otherwise you'll get SomePagehtm). So far, so good, and the out-the-box demo templates site appeared to run fine. But then I noticed a weird quirk. On the menu across the top, the various links made sense, for the most part:

News -> http://myepisite/en/News.htm

Events -> http://myepisite/en/Events.htm

and so on... but the Start link was all messed up:

Start -> http://myepisite/en.htm

What was strangest of all though was that this link actually worked! This made no sense on any level, and it was obvious that some internal fudge in the default URL rewriter was catching this as a special case. This was confirmed when I found this post from EPiServer support. They'd obviously found this 404'ing so built a special case for it.

So why do I care? Because this breaks the URL model and breaks my geolocalisation scheme quite badly. That link should 404 or else I have an issue. Ideally, I want to actually write out the proper link. So I started digging. It turns out that you get a link like this when you have an EPiServer Start Page and ask for the LinkURL for it. The default URL rewriter seems to munge it up and spit out this crazy short URL rather than a nicely formatted link. This is the same for any language, for example the Swedish start page gives sv.htm. Ideally though, I would want it to write out something like this (the page is actually called Public in the English version):

http://myepisite/en/Public.htm

I mean OK, it looks like any other page rather than a start page but surely that's better than en.htm! So... how do we go about getting the right page link rendered out and bypassing EPiServer's little 'fix'? Well, we can do it with the URL rewriter. I'll let Ted's post explain how to actually create the URL rewrite provider, but once you have the rewrite provider ready, you can override the ConvertToExternalInternal method as follows:

protected override bool ConvertToExternalInternal(UrlBuilder url, object internalObject, Encoding toEncoding)
{
    // apply default rewriting first
    bool bRewriteSuccess = base.ConvertToExternalInternal(url, internalObject, toEncoding);

    if (bRewriteSuccess)
    {
        string[] urlSplit = url.Path.Split('/');
        
        if (urlSplit.Length == 2)
        {
            // default page

            string DestinationCountryCode = urlSplit[1].Substring(0, 2);

            EPiServer.Core.PageData StartPage;

            try
            {
                StartPage = EPiServer.DataFactory.Instance.GetPage(
	new EPiServer.Core.PageReference(EPiServer.Configuration.Settings.Instance.PageStartId), 
	new LanguageSelector(DestinationCountryCode));
            }
            catch
            {
                // no page with that language, just grab the link anyway and it will
		 still work just with the current language name

                StartPage = EPiServer.DataFactory.Instance.GetPage(
	new EPiServer.Core.PageReference(EPiServer.Configuration.Settings.Instance.PageStartId));
            }

            url.Path = "/" + DestinationCountryCode + "/" + StartPage.URLSegment + 
			EPiServer.Configuration.Settings.Instance.UrlRewriteExtension;
        }
    }
    
    return bRewriteSuccess;
}      

This is not a fully-tested solution and it might need more work, but it shows that it is possible to fix this troublesome default behaviour. My geolocalisation demo then wrote out links as I would expect, and seemed to work perfectly across languages too. Hope this is of some use to anyone with similar issues even if it only gets you started on a fix!