Upgrading From Sitefinity 3: Blog Urls and Providers

This post is part of a series exploring my migration from Sitefinity 3 to 4.4. Some of this information may become obsolete as newer versions are released. Always watch the official Sitefinity website for the latest info.

As I've discussed previously, the Sitefinity Migration Module greatly simplifies and mostly automates the process of moving from the old version 3.7 up to the latest version. It imports all pages as well as any existing native content items such as news, events, and blogs.

It even preserves the existing Urls so that you don't lose any of your delicious, delicious existing SEO.

Default Url Format

I also mentioned in the previous post that although your original Urls for existing pages and content items are preserved, any new published blog posts will fallback to the default format. This also happens to any existing content that you republish. For blog posts in particular, the url follows the format of /[blogurl]/[date]/[blogposturl].

Now, this isn't necessarily a problem, because all of the original Urls are preserved, and by default the old replaced Urls will redirect to whatever the new default Url becomes.

However, I want to try and have a consistent naming scheme and use the default extensionless Urls that Sitefinity creates. In addition, I don't want the blog Urlname in my post links, because I would end up with Urls like http://www.selarom.net/blog/blog/whatever.

Custom Blog Data Provider to the Rescue

Fortunately, Sitefinity is, and has always been, about options. If something out-of-the-box isn't the way you want it, there's almost always a way to either customize it or replace it, and this is no exception.

Simple content items like News and Events have a Url format property you can you can modify to change the Url format. However, complex modules like Blogs have parent-child relationships (Blogs and BlogPosts) and require an extra step.

It is the Blogs Data Provider that is responsible for both saving and retrieving an individual post's Url, and it is here that we need to override the Url format. Thankfully there is already a helpful blog post on doing exactly this: Custom URL Formats for Sitefinity Content Modules.

Using this as a guide, I was able to make a simple provider with a custom Url format. Because I had already migrated my posts into the default provider I didn't follow the suggested path of adding a second provider, but instead replaced the default one with my custom provider type.

The provider itself couldn't be simpler. All I did was inherit from then override the UrlFormat property to return the format I desired for my blog posts.

public class SoftwareBlogProvider : OpenAccessBlogProvider
{
    public override string GetUrlFormat(Telerik.Sitefinity.GenericContent.Model.ILocatable item)
    {
        // Blog
        if (item.GetType() == typeof(Blog))
        {
            var urlFormat = "/\[Urlname\]";
            return urlFormat;
        }

        // Blog Post
        if (item.GetType() == typeof(BlogPost))
            return "/\[PublicationDate, {0:yyyy'/'MM'/'dd}\]/\[UrlName\]"; // Anything else
        return base.GetUrlFormat(item);
    }
}

The great thing about this approach is that it works for ALL the blog posts that use this provider, including the new Personal Blog I launched for those off-topic rants and raves that I'm sure nobody cares about, as well as any new blogs I create (the next one will be a good one, I promise!).

New Url Format

If any of you are regular readers of my blog (come on!) then you might have noticed that, once again, even though Sitefinity supports both preserving your old Urls AND defining a custom Url format, I decided to change my blog posts from the old [yyyy-mm-dd]/[Title] format to the new [yyyy]/[mm]/[dd]/[Title] that is the Sitefinity default.

I originally was going to show the provider modifying the Url to continue using the old format for consistency. Then I realized what that Url was doing, and how much more beneficial it was to switch. Because the Url now breaks up the date into paths (as opposed to a block), you can actually navigate my blog by date, including by day, by month, and even by year, straight out of the box!

So if you are considering manipulating the custom provider to keep your old Url format, I highly recommend you switch, because I have to admit, this is pretty slick!

Redirects

Just as I experienced with migrating pages, changing the Url format means that not only will I lose all my previous SEO, but I'll leave a wake of broken Urls from anyone who linked to my sites (okay I'm the only one who links to my site, but STILL!).

In our next post, we'll see how I used the IIS Rewrite Module to preserve all my old Urls and SEO even when using a completely new Url format.