iFinity Blogs 

Upgrading a custom Sitemap provider to the new iFinity Sitemap Provider version 2.0

by Bruce Chapman on Friday, September 21, 2012 5:40 PM

When I decided to do a major upgrade of the now-ancient iFinity Google Sitemap Providers project, I was faced with a couple of sticky issues:

  1. They’re no longer called ‘Google’ sitemaps.  It’s now an open standard located at http://sitemaps.org  - I wasn’t comfortable with the ‘Google’ moniker anymore.
  2. The base provider was designed on the underlying ASP.NET provider base, and not the DotNetNuke provider base.  This means it ‘lived’ outside of the DotNetNuke configuration, and wasn’t quite integrated into DotNetNuke as it should be
  3. I wanted to add a proper manifest file, and allow the extension(s) to be installed as first-class DotNetNuke extensions, which meant needing to bring all the settings into the <dotnetnuke> configuration

Normally, I’m the last person to want to break any backwards compatibility, but in this case, if I wanted to move the project forwards, it had to be done.  So I did it.  Any provider built for the 1.x specification of the iFinity Googlesitemap Providers will not work with the 2.0 version, unless you re-compile the project and update the references. 

To further make this distinction complete, I changed all the namespaces, assembly names and just about everything else.  So there’s no way of ever getting the two versions mixed up – in fact you can probably run a site with both installed side-by-side (not that I recommend doing this – I don’t).   I also took this tearing-up-the-past momentum further and removed deprecated methods and properties altogether, taking the opportunity to clean up a few code dead ends from past changes of mind.

Further, the new version is compatible with DNN 5.2 and up, and requires .NET 3.5 as a minimum base. 

This blog post is a guide on updating your project to be compatible with the new 2.0 ‘Search Engine Sitemap Provider’.  It assumes that you have loaded up the source code of your sitemap project into Visual Studio.

Step 0 : Back everything up

And I mean everything.  Source code, website, whatever you’re going to play with.

Step 1 : Get the new version DLL

The one you need is the DotNetNuke.Providers.SearchEngineSitemaps.dll.   You can also pull the source from codeplex if you want.

Step 2 : Reference the DLL in your project

In your Visual Studio project, add a reference to the DotNetNuke.Providers.SearchEngineSitemaps assembly (or project, if you’re working with source code)

If it’s still referenced, remove the reference to the old ‘iFinity.DLL.GooglesitemapProvider’ assembly.

Step 3 :  Fix your provider inheritance

Now that the old provider has been removed, and the new one added in as a reference, you can change the inheritance of your Sitemap Provider.  Open the source code for your Sitemap Provider class.  The old inheritance will be broken:

image

Above: Broken Inheritance (incorrect assembly reference also highlighted)

- Remove any references to iFinity.DNN.Modules.GoogleSiteMap (underlined with red)

- Add in DotNetNuke.Providers.SearchEngineSiteMapProvider as a ‘using’ (C#) or ‘Imports’ (VB) statement

Once this is done, the SiteMapProvider inherited class should be fixed.

Step 4 : Add in a constructor

One of the changes resulting from the change from a ASP.NET provider to a DotNetNuke provider is the requirement for the Provider class to specify a constructor.

Previously, Sitemap providers had to specify an ‘Initialize’ method, which was called as the providers were initialized.  This is no longer the case : now the providers must have a constructor specified.

image

Above : There is no longer an ‘Initialize’ method to override.

The easiest way to do this is to change the Initialize method into a constructor instead.  So replace the public override void Initialize with public {classname} and include the : base(name, config) at the end of the constructor declaration.  This turns the initialize into the provider constructor.  Note that once this is done, you don’t need to call the base.Initialize() method anymore – because by overriding the constructor, this is done for you.

image

Above : Initialize method redefined as constructor method, and base.Initialize removed.

Step 5 : Re-implement any SitePagesForTab() overridden methods

In the previous version, there were several overloads of ‘SitePagesForTab’.  Each of these overloads signified a point in time when a deeper understanding of the issues behind creating module-specific sitemaps was created by the author (ie, when I figured out why something wasn’t working the way it should).   Each overload added more and more variables that needed to be provided to create a better set of Urls for a module.    The last addition was to allow ranges of sitemap entries to be split out into sitemap index files and linked sitemap files.

If you compile your project at this point, and you have used one of the deprecated methods, you will get a compiler warning. 

image

Above : Compiler warnings for deprecated methods

To get rid of these warnings, just deleted the deprecated overrides in your project, leaving the SitePagesForTab declaration with the longest amount of parameters (this is now the only base method).

Note that at this point you should take heed of the Compiler description remarks of the SitePagesForTab method which contains the startingCount and endingCount values:

This method is used to produce all of the variations of page Urls a DotNetNuke module can create.  This is normally due to query strings (or, friendly urls). You shouldn't write overriden versions of both SitePages/SitePagesForTab methods unless they return unique sets of SitePage objects.  Note that it is up to the module provider to return a set of items within the specified index bounds.  Any items returned greater than the number of places left (up to the 'endingCount') will be discarded for the called sitemap.  It is the responsibility of the sitemap provider to hold state on which urls have been returned and which have not been included in this range.

This might sound a bit scary, but it isn’t really.  The person who implements the module has the ability to control how many sitemap entries go into a sitemap file.  If your particular module returns more than that, the others will be discarded.  The module provider *may* be called (depending on settings) for a 2nd time, this time with the next range, and, if this happens, your provider has to return the next set of Urls.

It might go like this:

call 1 : sitemap 1,  Urls in range 1-1000, total Urls : 5000 (startingCount 1, endingCount 1000, urlCount 5000)

call 2 : sitemap 2, Urls in range 1001-2000, total Urls : 5000 (startingCount 1001, endingCount 2000, urlCount 5000)

NOTE: a sitemapNum value of  0 means there will only be one sitemap file, and thus the overall length is restricted to 10,000 urls.

If you don’t want to mess around with providing multiple ranges, you can code your provider to ignore the index count, sitemap number and other values.   This just means that it might be possible that a range of Urls might be truncated, depending on the settings.   In most cases the amount of Urls isn’t worth worrying about (few module produce 10,000 urls).   If you do have a very large number of urls (such as a forum with a lot of posts, or a set of classified listings) it will be worth your while to investigate how to use the values better.

image

Above : The ‘old’ SitePagesForTab overloads were just deleted, and the single call used to return the List of SitePage objects.  Note that this particular provider ignores the urlCount/startingCount/endingCount ranges.

Step 6 : Compile

At this point you should be able to compile your provider.  If not, go through and carefully check to see that the right namespaces, assemblies and other items have been changed correctly.

Step 7 :  New web.config entry

The old web.config ‘googlesitemapproviders’ is no longer used.

image

This will be deleted when you install the new version on your site (assuming you use the Extension install package)

image

The provider definition needs to be moved into the /dotnetnuke/searchEngineSitemap declaration (note: you need to install the 2.0 version of the base provider first).

You can just copy/paste your <add name=”module name”… definition from the old ‘<googlesitemaps> section to the new section, assuming you haven’t changed any of the type or assembly names.

Step 8 : Check your results

Once you compiled, copied your new assembly file to the /bin directory of the site, and then updated the web.config file, then you’re ready to try.

The ‘new’ provider is requested from {domain}/SearchEngineSitemap.aspx  - request this Url on your site, and then inspect the results to check that your module has provided the correct Urls.

Bonus section : Create an installer package

If you look at the source code for any of the providers available on Codeplex, you’ll see that they have a ‘packageForInstall.bat’ file, and a provider-name.dnn manifest file.  The manifest file can be copied and altered to provide the ability to install your provider using the DNN installer, instead of having to drop in files and modify config files manually.

Wrapping Up

If you’ve got a sitemap provider written for the original project, it shouldn’t take too much time to update it and get it ready.  If it’s for a popular module, consider if you would like to update and load it onto the DotNetNuke Forge / Codeplex project.   It’s a good idea to keep all these things in the one place!

Blogs Parent Separator Crafty Code
Author
Bruce Chapman

The craft of writing code. The outcomes from being crafty with code. Crafty Code is tales from the coding bench.

Bruce Chapman
Hi, I'm Bruce Chapman, and this is my blog. You'll find lots of information here - my thoughts about business and the internet, technical information, things I'm working on and the odd strange post or two.
Connect with Bruce Chapman on Google+

Share this page
Get more!
Subscribe to the Mailing List
Email Address:
First Name:
Last Name:
You will be sent a confirmation upon subscription

Follow me on Twitter
Stack Exchange
profile for Bruce Chapman at Stack Overflow, Q&A for professional and enthusiast programmers
Klout Profile