News Feeds (RSS)

DNN 7.1 and Url Master

Mon, 22 Jul 2013 08:01:09 GMT

The release of DNN 7.1 brings about a major change in URL management within the DNN Platform. This is the version that incorporated much of the Url Master codebase, and introduced many new functions and features around URLs. These are all laid out as per the original iFinity Acquisition blog post that was written late last year.

This blog post is designed to provide a guide for those people who have been using the Url Master module and are now looking to upgrade their DNN site to DNN 7.1.

There are two choices for people in this category:

1. Continue to use the Url Master module to provide the URL functionality for their site

2. Switch over to using the new ‘Advanced’ URL functionality in the DNN Platform

The first thing to note is that a new version of Url Master has been released for using DNN 7.1. This is Url Master version 2.8. This contains important UI fixes related to the new jQuery version bundled with DNN 7.1, as well as a new feature to migrate settings and configuration from Url Master to the ‘Advanced’ URL mode of DNN 7.1.

Download Url Master 2.8 from the Downloads page, or from the DNN Store.

Regardless of your intention in terms of whether you fall into category (1) or (2) you should update your Url Master version to 2.8. This is a free upgrade for anyone who already has a license for any version from 2.0 through to 2.7. The upgrade can be done before or after you have upgraded your DNN site to 7.1.

Continuing to use the Url Master module with a DNN 7.1 Site

There are no issues to using the latest version of Url Master with DNN 7.1. The module works as normal, and, as before, all of the settings and configuration are held separately to the core DNN settings and configuration.

While the Url Master module will not be enhanced at all going forward, it is expected to remain compatible with DNN for the foreseeable future, and there is no plan to force existing users to stop using the Url Master module.

For people in this category, just upgrade to version 2.8 for the UI fixes and continue to use the Url Master module as normal.

This advice applies both to the DNN Platform (formerly DotNetNuke Community Edition) and those who are now using Evoq Content (formerly DotNetNuke Professional Edition).

If you are currently leveraging any of the Url Master custom module providers, you will have to stay with using Url Master until a 7.1 compatible version of your specific provider can be made. These providers are all open-source now, so it is possible to convert the Url Master module providers over to DNN 7.1 Extension URL providers if you have access to development resources.

Switching over from Url Master to the Advanced URL functionality in DNN 7.1

If you are planning to start using the new Advanced URL functionality in DNN 7.1, and you have an existing license for the Url Master module, there is a conversion path. This converts all of the Url Master redirects, portal alias settings and configuration settings over to the DNN format. The Advanced functionality is heavily based on the Url Master codebase, but they are not exactly the same. Many changes have been made in order to properly integrate the product into the DNN Core.

Therefore, I suggest that people test the switch-over carefully, and make sure that they have checked that redirects, third-party modules, and all other URL-related functionality works correctly. I strongly recommend that people do this in a ‘localhost’ test environment if they have the capability. If not, you must take a backup immediately prior to doing the conversion and be prepared to revert to the backed-up version of the site if the tests do not pass.

This process applies both to the DNN Platform (formerly DotNetNuke Community Edition) and those who have upgraded DotNetNuke Professional Edition to Evoq Content.   While the DNN Platform has very few UI configuration locations for the Advanced URL Settings, the functionality is fully operational once the Url Master settings are converted.

Please note : you need to have a fully licensed version of Url Master in order to activate the conversion functionality, except if you are running on ‘localhost’, in which case it will work with an unlicensed version.

The actual process of conversion is very simple:

1. Upgrade your Url Master version to 2.8

2. Go to the Host->Friendly Url Settings page, and find the ‘Convert to DNN Advanced Urls’ button


3.  This will load the Conversion Dialog:


Click ‘Start Conversion’ when you are ready to do the conversion.

4.  The conversion process will run, and then show a summary of the changes made:


The figures in the boxes apply to the entire DNN installation.   Check through the numbers to do a ‘sanity check’ and make sure that the figures seem correct.   You can then close the dialog – the conversion is complete and your site is now activated in DNN ‘Advanced’ mode.  Note that because this requires a web.config change, the site will automatically restart when the process is complete.  The ‘close’ button triggers a page refresh to complete this process.

5. Check functionality on your site to make sure that the conversion has worked correctly.    A brief set of tests should include:

  1. Basic site operation : all public URLs work as expected
  2. Edit Mode : does the Edit Mode functionality work as before?
  3. Any third-party module functionality : do blog posts, forum threads, e-commerce pages, photo galleries etc load up correctly?
  4. Login/Logoff functions : are you able to login and log out as normal?
  5. 404 Handling : if you had 404 handling configured, check that the 404 error handling works as expected.
  6. Admin/Host Urls : are you able to do basic functions like search for a user, save site settings, etc?
  7. Custom Urls : do custom redirects you had configured in Url Master still work OK?  Are any custom URLs showing for pages correctly? 
  8. Site Alias redirects : does the site respond correctly in terms of alias redirects (like –>
  9. User Profile pages : if you had vanity user profile URLs activated, do they still work correctly?  Are the profile pictures showing correctly, can users post updates, edit their profiles?

This is only a brief list to get you thinking; you should execute a comprehensive test plan to make sure the site is working as expected.  Your SEO depends on making sure there are no surprises and everything is working as before.   In the vast majority of cases, there should be no difference in behaviour or functionality, but it is imperative that this be tested and confirmed.  While I have tested this functionality to make sure a like-for-like conversion of settings is working as expected, it is impossible to test the entire universe of Url Master installations.

6.  When the conversion is finished, it’s up to you whether or not you uninstall the Url Master module.  You may wish to keep it installed as a backup for the short term in case you find a problem with the conversion process.   You can run the conversion process as many times as you like – it has been designed to be run repeatedly without causing any issue, to allow for iterative checks.   Each time it is run, the settings are taken from the Url Master configuration and applied to the DNN install – thus any changes in the DNN installation may be overwritten each time you do this.

Note: Anyone using Custom Module Providers for the Url Master module – the settings specific to Custom Module Providers are not converted during this process.  Any Custom Module providers will have to be replaced like-for-like with a DNN 7.1 specific Extension Url Provider which provides the same functionality, and the settings specific to that provider will have to be carried across.

Getting Support and Help

If you find any issues with the conversion process, please log them in the Url Master support forum.  

Wrapping Up

This is the last scheduled release of the Url Master module, and it will removed from sale very soon.   There has been a very long process in the making to get to this point in time, and I’m very happy that the ideas and concepts I developed and pushed over many years are now going out to a very large install base.   It’s the end of the road for the Url Master module, but the start of a whole new URL journey for the DNN Platform, and there are even more innovations and improvements yet to come.

More ...

DotNetNuke Corp acquires iFinity Software

Tue, 18 Dec 2012 13:59:00 GMT

It is with great pleasure that today I announce that DotNetNuke Corporation has acquired all of the assets of iFinity Software. In addition to this, I have joined DotNetNuke Corporation on a full-time basis to work on the Product Team, effective immediately.

The reason for this action has been to both provide DotNetNuke with tried-and-proven technology for greatly expanding the Url capabilities of the DotNetNuke platform, and to have access to my now extensive experience in dealing with all things related to Urls. Some of the regular readers of this blog will know what I am speaking of when I say I have dealt with numerous difficult situations related to the Urls of a DotNetNuke powered site, and managed to bring it all through. This opportunity allows me to take that hard-earned knowledge and experience to a much wider audience than the sizable but still relatively niche customers of mine.

The immediate plans for all the Url-related software are to integrate the codebase into DotNetNuke 7.1, a process which has been kicked off immediately. The underlying Url Master technology will become the standard way of powering all Url related functions in DotNetNuke, for all editions, for all versions from 7.1 onwards. The majority of the Url management features will go straight into the commercial editions of DotNetNuke, but the underlying capability and improved Urls will be in the open-source community platform. Many people will have questions about which features go where, so please see the table at the end of this blog post for a detailed breakdown.

Existing customers will continue to get support as normal, and the products will remain for sale for the immediate future. If you’re working on a project that uses any iFinity Software, you can continue to do so without fear of losing support or help.

Of course iFinity Software has produced many different pieces of software over the past 6 years, and all of the available branded products have had ownership transferred to DotNetNuke Corporation. The second table at the end of this blog post details the future of these products, which details the future and timeline of each product. It’s important to note that by far, the largest majority of code I ever released under this banner was open source –most of that has been already transferred to the DotNetNuke Forge as part of my ongoing project to do so – and this announcement doesn’t change the status of those projects.

No doubt there will be some who are disappointed that DotNetNuke didn’t just buy the products outright and then give it all away for free. While that would make writing this blog post a lot easier (everybody would love to announce the handing out of free stuff), the truth is that commercial realities define all business transactions, and it was up to me to accept the proposal or continue on independently as things were. To be honest, either choice was equally compelling as I have been very happy with the way things have been going, but joining DotNetNuke was an opportunity not to be missed. In the same way artists want people to see their work, authors want their books read and bands want their songs heard, the opportunity to provide input and direction on software that goes out to a very large audience was compelling.

I have had a strong belief in the DotNetNuke platform over a long period, and I made a successful business out of filling in some of the gaps in the feature coverage of the platform. This opportunity has allowed me to not only fill in that gap for all , but also gives me input into filling in some of the other gaps I am passionate about. Within DotNetNuke 7.1, I’m able to fulfil the request of the top-ranked Community Voice request, and satisfy at least one other (there may be more, I haven’t gone through the entire list yet).

An important thing for me is that I’m not going anywhere – I’m going to be working on the same technologies with mostly the same set of people. DotNetNuke has not only given me a business, but delivered a great set of customers and helped grow a great set of friends all over the world. During the process of working out the deal, I became aware of the very exciting things that are going on within DotNetNuke corp. It’s a place that is moving ahead quickly and some of the new things that will come out over the next 12 months or so are seriously impressive.

I am intending to use my new responsibilities within the company to help grow the products, features, revenue and community at large. And I hope that all of the existing people I have worked with and met throughout the life of this company will continue to do so as I transition into the next.

Acquisition FAQ List

What is iFinity Software?

iFinity Software, based in Queensland, Australia, is a software company specializing in the DotNetNuke platform. iFinity sells modules on the DotNetNuke store, and is well known for its Url Management software, based around the Url Master module.

What will happen to iFinity Software?

Bruce Chapman, the director and sole permanent employee of iFinity, will join DotNetNuke Corporation on a full-time basis. All of the available iFinity Software products IP will be transferred to DotNetNuke.

What is the reason for this move?

The bulk of revenue and consulting work for iFinity Software comes from the Url Master module and related plug-ins. These exist solely to plug a gap that is in the underlying framework. This acquisition will plug that gap and increase the ability of all users, customers, developers and vendors to manage the Urls in DotNetNuke.

What is going to happen to the Url Master module?

The Url Master module will be integrated into the DotNetNuke core. It will not be a stand-alone DotNetNuke extension. The targeted DotNetNuke version for this integration will be 7.1.

Please see the Software Plan for more details.

Will the full version of Url Master be available in the Community Edition?

The Url Master module will not be an installable extension as it currently is. Not all features of the module will be available in all DotNetNuke editions. Please see the Software Plan for more details.

How does this benefit the DotNetNuke Community?

The integration of iFinity technology into DotNetNuke will provide more functionality in the DotNetNuke core, for all editions, will benefit all end users, developers and vendors.

I have purchased an iFinity Software product. Can I still get support?

Yes, support for iFinity Software products will continue to be supplied either through the DotNetNuke store helpdesk system, or through the product support forums at All existing customers will continue to receive support in accordance with their existing licences. There will be no change in these arrangements.

I am a DotNetNuke professional customer – can I get the Url Master module now along with my Professional licence?

No. If you wish to install the Url Master software, you will still need to purchase via the DotNetNuke store.

I am a DotNetNuke professional customer and an iFinity Customer – will I be able to get support for my iFinity products through the DotNetNuke helpdesk?

Yes, you can. Just log the issue through the DNN Helpdesk in the normal way.

Will I be able to continue to purchase iFinity products after the acquisition?

iFinity products will continue to be sold through the DotNetNuke store for a period. See the Software Plan for more detail on the expected dates.

What will happen to the open-source modules currently available on

The open-source offerings on will be migrated onto the DotNetNuke forge, if they are not already hosted there. Individuals are welcome to join the projects on the DotNetNuke Forge as contributors.

Will I be able to upgrade from my current Url Master installation to the Core Functionality?

Yes, an upgrade path for configuration and existing redirects will be part of the transition.

iFinity Software Product Plan

All commercial modules will remain available on the DotNetNuke Store until their transition date.

Product Name


Expected Date

Url Master

Integration into DotNetNuke

Q2 2013 – DotNetNuke 7.1

Url Provider for Ventrian News Articles

Open Source – Dnn Forge

Q1 2013

Url Provider for Catalook

Open Source – Dnn Forge

Q1 2013

Url Provider for DotNetNuke Blog Module

Open Source – Dnn Forge

Q1 2013

Url Provider for DotNetNuke Social

Open Source – Dnn Forge

Q1 2013

Inline Link Master

Withdraw from market

Q1 2013

Canonical Linker

Integration into DotNetNuke

Q3 2013

iFinity Friendly Url Provider

Already on Dnn Forge


iFinity Search Engine Sitemap Providers

Already on Dnn Forge


iFinity Tagger module

Already withdrawn from market July 2012


iFinity Google Analytics module

Already on Dnn Forge


iFinity Cache Master module

Already on Dnn Forge


iFinity Social Dashboard module

Already on Dnn Forge


Advanced Url Features to be included in DotNetNuke 7.1 Editions

In general, the principal will be that all editions will have the same underlying Url Framework. The Commercial editions of DotNetNuke will have all of the functions built into to the product, fully integrated into the Page, Site and Host configuration areas. The community edition will use the technology to deliver better Urls, and will allow API hooks for third-party developers to extend the Url Handling of the core product.

Feature Name

Core Platform

Community Edition

Commercial Editions

Remove all ‘tabid’ values from all Urls




Replace characters in Urls with specified value (ie ‘-‘)




Replace characters in Urls using find/replace pairs





Page Extension removal/change




Automatic redirect of ‘unfriendly’ urls




Lower case conversion




Lower case redirect




Change Url Space Encoding




Illegal Url character filtering




Redirect /default.aspx urls to site root




Always set default site language




Friendly Urls for Admin/Host Pages




Regex Filters




Deleted and Moved page redirection *




SSL Server/Client redirect




Custom Module Providers Configuration




Custom Regex Redirect/Rewrite rules




404 Handling




404 Log




500 Error Handling




Test Url Generation Function




Test Url Rewriting Function




Primary Portal Alias Redirections**




Mobile specific Portal Alias




Language Specific Portal Alias




Skin per Portal Alias




Vanity User Profile Urls ***




Custom Urls for Tabs (2)




Custom Redirects for Tabs




Exclude Tab from Friendly Urls




Block Redirects for Tab




*New Feature

**Already in all existing editions of DotNetNuke

*** Possibility of deploying this functionality within the ‘Dnn Social Url’ provider rather than as a core feature – see ‘Key Engineering decisions;

Community Voice Suggestions

(1) ‘Configurable character substitution in Url rewriting’ :

(2) Addition of Url Name field to Page Properties :

Wrapping Up

The completion of this acquisition brings to the end a 6 year chapter, one in which I have made many new friends and leant many new things.  I look forward to working with even more people as part of DotNetNuke Corporation going forwards.

You can also read Shaun Walkers blog post as well.

More ...

Case Study : Multilanguage ecommerce with Url Master and Catalook

Wed, 12 Dec 2012 10:56:15 GMT

Probably the most common request I get these days is a variation on ‘how can I modify this Url to be more friendly’.   The Url provided as an example is always a variation of a forum thread, blog post, event entry or e-commerce product.   It usually involves a Url that includes lots of ‘tabId’ and ‘productId’ values, and little or no keywords or contextual information about what is on the page itself.

In fact these types of requests have been coming through for nearly 5 years now, which is about how long ago I started writing the Url Master module from very humble beginnings of a hacked-up copy of the DNN Friendly Url provider.

It’s more than twelve months since I launched the concept of Custom Module Url Providers, which are small plug-ins which provide a connection between the Url generation and rewriting of DotNetNuke, and third party content modules installed in DotNetNuke.   When I launched this, I built a provider for the DotNetNuke Blog module (which is why you see the Urls you see on this blog).  I also released as commercial products providers for the popular News Articles Provider, and the Catalook ecommerce module, which many people will be familiar with.

One of the early adopters of the Catalook plugin was Jose Cardoso of Refresh Multimedia.    The first site this was to be rolled out on was rather ambitious : a large product catalog including 32 advanced Catalook categories, 2000 products, and 6 languages to be supported.   The requirement was to have a clean, friendly and unique Url for each product and each category in each language.  There would be none of these :

  • ‘tabid’
  • ‘.aspx’
  • ‘default’
  • ‘productId’
  • ‘categoryId’
  • ‘categoryType’
  • ‘language’

If you’re used to looking at a multi-language catalook store, you’d be left wondering what was going to be left in the Url.   The answer is simple : just the category name or product name, cleaned up, non-ascii characters replaced, and nice and simple.  In fact, this site has 12,000 unique product urls, each localized and optimized for the products.

Case Study : Multi Language E-Commerce Site with Catalook

The site is called, and is a wine site which sells wines from a variety of countries, to a variety of countries, using a wide variety of languages.


Some example Urls are:

Australian Wines (Portugese) :

Australian Wines (French) :

Australian Wines (Italian) :

Penfolds Bin 128 Shiraz (Portugese) :

Penfolds Bin 128 Shiraz (German) :

(Penfolds make a very nice red, if you’re interested!)

Note that the Categories are all localised, and do not include any DNN page path.  In fact none of the e-commerce catalog Urls include the DNN Page name at all, giving a much more concise and clean Url.

You’ll notice that the product Urls have a language/productId code on the end.  This is actually an option with the Url provider, because it allows redirection to take place in the case where the Url changes.  Some products will always have the same Url, but in the case of wines, the vintage changes each year.   Because the vintage changes, you need to change the product title (ie Shiraz 2009 eventually becomes Shiraz 2010) – by tagging the Url with a product/language code you can always find the latest, correct and canonical Url.

As a comparison : here is a Url from the demo site (the version is old, but the Urls are still largely the same)

This is the type of Url that many people will be familiar with.   There is a very large difference in usability, SEO and plain aesthetics in comparison to the wine Urls listed above – and I am extremely confident that, if two sites were built identical apart from the Urls, the friendly Urls would outperform the unfriendly version in click through, SEO rankings and other metrics like successful social media shares.

Components used to build the Site

-> Url Master module – overall Url control

-> Catalook Store module – provision of ecommerce components

-> Catalook Url Provider for Url Master – links the Catalook pages to the Url Master module via friendly Urls

For the multi-language capabilities of the site, it uses multiple language packs, but does not use the DNN Multi-Language capability of running a page-per-language.  Instead, there is one single page, and the language controls the localisation of both the on-screen elements (search box, login/register, etc), and the language drives the multi-language listing capabilities of Catalook.

Site Content

In order to drive multi-language capabilities of Catalook, each product and category must get the following values set per language:

- product name

- product title

- product description

- category name

- category title

- category description.

Over a large number of products you can tell this becomes a significant translation job!

Site Configuration : How to replicate these results

1. Install the Url Master module, and the Catalook Url Provider.

2. Configure the Catalook Url Provider by going to the Admin->Portal Urls->Module Providers section, and enable the provider, and associate it with the Catalook store pages on the site.  In this case, the entire store is on a page called ‘Find Wine’, so that page is associated with the provider:


3. Choose the options for the Catalook Url Provider by clicking on the ‘Change Provider Settings’ link


4.  Ensure that you have completed all the localised content on the site, so that each product generates a unique Url

5. To ensure the search works well,  enter this value in the ‘doNotIncludeInPathRegex’ value in the Admin->PortalUrls->Regex setting section:


6. Save all changes and refresh the site.   You should now have nice, clean, multi-language Urls!

Note that the localisation in the site is driven by the language of the requested Url.  Because each product has a unique Url per language, the language can be derived and set just by knowing which language version of the product Url was requested.  So there is no need for different domain names, path qualifiers like /en and /fr.

In the case of ‘regular’ (ie, non product) pages, you can use the multi-language capabilities of the Url Master module to set unique-per-language Urls for the page, which again hide the language qualifier (see / / etc )


I hope this sneak peek inside a complex Catalook/Url Master configuration has provided a glimpse into what is possible.   I worked with Jose to get this site working, and I understand even bigger and better Catalook installs are planned.  If you have any specific questions about the install, please ask via the comments below, and I’ll either endeavour to answer them myself, or convince Jose to fill them in.

More ...

DNN 7 is go!

Wed, 05 Dec 2012 06:58:00 GMT

I just completed an upgrade of this site (and the demo site) to DNN 7.0.    I have also upgraded this blog to use the new 5.0 DNN Blog, which brings with it the change to no more anonymous comments.  Sorry for those who don't like to sign in to comment, but the need for social interaction requires contributors to have an account!

The upgrade went smoothly and took about 5 minutes from starting backups to looking at the new site.  The skin on this site (yes, needs updating!) was designed for DNN 5, and never quite worked properly with DNN 6.  But I'm happy to say that everything looks great with DNN 7, and the new control bar really is a great thing.  

If you haven't yet upgraded to DNN 7, I would plan to do so.  Just remember you need to have IIS 7 and .NET 4 on your site before you set out, and always, always, always have a backup prior to starting.
More ...

DotNetNuke 7 and Url Master

Thu, 15 Nov 2012 01:16:00 GMT

It’s that time again, when a major new version of DotNetNuke is about to drop onto us, and that means lots of testing to make sure that things are going to work with the new version.    I’ve been doing testing and fixing and testing and checking with the Url Master module, and it’s ready for DNN 7.   But there’s a few things you need to know before you go and upgrade to DotNetNuke 7.

The first is that DotNetNuke 7 has a great new upgrade wizard.   It’s an order of magnitude better than the old one.

Unfortunately, the existing version of the Url Master module can break this wizard in certain configurations

So you will need an upgrade of the Url Master module before you upgrade your DotNetNuke installation.   This is necessary to be certain that the new upgrade wizard will work perfectly.   You also have the option of disabling the Url Master module prior to running the DotNetNuke upgrade.

The version of Url Master that is compatible with DotNetNuke 7 is Url Master 2.7.  This is now available from the Url Master Downloads Page.

DotNetNuke 7 Upgrade Process for Url Master Users

Step 1 : Complete your full site and database backups

Step 2 : Go to the Host->Extensions page on your site, and install the new Url Master version 2.7.  Follow the install wizard all the way through, and check to make sure that the install process finished successfully.

Step 3 : Follow the regular Upgrade process for DotNetNuke by unzipping the files, running the upgrade wizard

Step 4 : Check to make sure the upgrade finished OK, and relax and check out your new DNN 7 site.

Frequently Asked Url Master / DotNetNuke Upgrade Questions

Q: What version of Url Master do I need before I upgrade to DotNetNuke 7?

A: You need Url Master version 2.7.  If you already have a 2.x version of Url Master, this is a free upgrade, and you can just download and install the new version.

Q: Do I need to disable the Url Master module prior to upgrading?

A: No, you don’t need to, but if you can if you want to.  Disabling the module by going to the Host->Friendly Url Settings page, and clicking the ‘Revert to Standard Provider’ button disables the Url Master module and restores the standard DotNetNuke Friendly Url Provider/Rewriter.  By doing this you ensure that the Url Master module is excluded from the upgrade process.

Q: Should I uninstall the Url Master module prior to upgrading?

A: No.  If you uninstall the module you will lose all of the settings you have entered for the module.

Q: I have already upgraded to DotNetNuke 7, and I have the Url Master module installed.  Do I still need to ugprade?

A: Yes, you do.  There are many compatibility changes and fixes in the Url Master 2.7 version that make the module run properly with DNN 7.

Q: I did my upgrade before reading this post.  Now my ‘upgrade’ screen is broken and I can’t continue with my upgrade.  Help!

A: If you run a DotNetNuke upgrade prior to upgrading or disabling the Url Master module, you will see a broken DotNetNuke upgrade screen.  It will show broken links for the DotNetNuke logo, and the layout will not look correct because the css and js files will not load correctly.

If you have this situation, you must manually disable the Url Master module in the web.config.   

To start the process off, take a backup of your web.config file.

Then, go to the section in your web.config, and find this entry:


(click to enlarge)

Replace it with this entry:


(click to enlarge)

The type name is ‘DotNetNuke.HttpModules.UrlRewriteModule, DotNetNuke.HttpModules’ – please note that this is case sensitive.

Once this is done, find the section, which is further down in the web.config file, and looks like this:


and replace the ‘iFinity.UrlMaster’ value with ‘DNNFriendlyUrl’ so that it looks like this:


Note that you will not have to remove the

Once you have made these two changes, save the web.config file, and do a refresh of the DotNetNuke Upgrade Wizard.  The page should now be fixed, and you should be able to proceed through the upgrade process as normal.

Once you have completed the ugprade for the site, you can go back into the Host->Friendly Url Settings page, and click on ‘Apply Changes’ to re-activate the Url Master module with your existing settings.

When your Upgrade is Complete

Don’t forget to do a full check on your site after you have completed your DNN 7 upgrade.  The DNN 7 upgrade contains a lot of new changes to the site, and some older modules and skins may be affected by the new layout changes.   Best to find them all now if you do have any issues like this.  Most module vendors and open source contributors will have updated the versions to allow for DNN 7 capabilities, so find the new versions and upgrade.

Enjoy your new DNN 7 site!

More ...

The Top 5 Things in DotNetNuke 7 that you will love

Mon, 12 Nov 2012 09:52:59 GMT

The word on the internet is that DNN 7.0 is about to drop any day now.   I’ve been following this one quite closely since the DNN World conference (a month ago now, how time flies!) and I’ve been doing extensive compatibility testing with my software.

In that space of time and testing, there are some things about DNN 7 that I think hit the ‘hey, that’s neat’ gong quite loudly.  So that’s what this post is all about.    Just a highlights package from my point of view, if you haven’t managed to see it yet.

Thing 1 : The new install and upgrade wizards

There was a time when everyone seemed to agree that installing DotNetNuke was a tough task fit only for the bravest of souls.  I didn’t ever really think that way, because the whole idea of a self-installing and self-upgrading web application was the stuff of fantasy not that long ago.   I mean, I can remember the day when you had to register COM components and restart IIS to get stuff to run.  I hope you, the reader, have no idea what I just said because that means the industry has made vast gains.  DotNetNuke itself was always an easy thing to get going, but now it is dead simple and informative.

How so?  Well, the installer is a one-page set of questions, many of which are pre-answered.  And then, you click ‘go’, and it whizzes through, installs all the various parts and then gives you a new screen with a couple of options – either explore more about the platform, or just let you dive straight in and get going.  And, just like in DNN 6, when you’ve finished the install, you’re already logged in.  Nice.


Above : The final page of the new installer.

The new installer looks, feels and is very slick. 

But that’s not all.  The Upgrade Wizard of DotNetNuke was always a poor cousin to the installer – the old upgrade page used to just run a set of code, and when finished, give you a link to visit the site.  Functional but not particularly pleasant to look at.  And then there was the problem of the wrong person unexpectedly tripping the upgrade.

All that is in the past.  DotNetNuke 7.0 now has an upgrade wizard with the same look and feel as the install wizard.  With the added feature of being required to log in as a super user account in order to start the wizard off.    Having done multiple upgrades with software testing now, I like everything about the upgrade wizard.

Thing 2 : Auto Save

We’ve all done it : typed in a whole mess of content, fixed this, nudged that, and then – wham! – something like a browser crash, an accidental close – anything that loses your data.  No more.  With the Text/Html module, your content can be auto-saved as you type.  No more lost content.  Much fewer curse words being sent in the direction of DotNetNuke installs.  A real positive step forwards.

Thing 3 : Default View Mode

Now here’s where things really start to get revolutionary.  For as far back as I can recall, when you logged into a DotNetNuke site as an administrator or content editor, the site went into ‘Edit’ mode.     I’m sure you’re familiar with edit mode.  Lots of menus here, there and everywhere.  On the majority of skins, a rather broken looking layout.  Slow page load times because there is a million little bits of edit code being sent down to the browser while you drum your fingers on the table. 

DotNetNuke 7.0 now defaults to ‘View Mode’ – which, despite the fancy name – just means the content, by default, looks as it will to the site visitors.    And, because it defaults to ‘View Mode’, the old ‘View Mode’ wording/button/control – it’s gone now.  It’s just the normal view, or edit or layout views.  Simple. 


Above : Accessing the page settings and editing the page using the ‘Edit Page’ menu

It might feel unintuitive to the seasoned DotNetNuke user at first, but to the newly-introduced, it works well.   It really works well.  When I go back to editing a DNN 6 site, the old way feels broken.  That’s a sure sign of progress to me.

Thing 4 : Drag and Drop

Along with the way of editing a page having changed, something else has also radically changed.   Since, well, forever, DotNetNuke has had the concept of adding a module to a page.  You’ve always selected the module by name, and then clicked ‘add’.  There’s been different variations of this – you could add directly to specific panes, copy modules from other pages, and so on.

But now there is something new.  You select the thing you want to add (Text/Html module) then you drag a copy of that to the place on the page you want it.   That’s it – couldn’t be simpler or more intuitive.  To me it is very elegant in operation because not only are you putting things where you want, but the page expands dynamically to show where the insert will be.


Above : Dragging an instance of the Html module onto a pane on the page.  The light-blue highlighted rectangle shows where the drop will take place and the content will be created.

Thing 5 : Control Panel

Our last thing is again UI related.   And it’s another update of the Control Panel.   I was pretty happy with the Ribbon bar in DNN 6, but things have been significantly moved on yet again.  It’s not just the drag-and-drop modules, or the new Edit Page access, it’s the very way the Admin/Host modules are organised.  I haven’t looked for a while, but back in the old DNN days there really wasn’t that many admin modules.  But they grow over time and now there is a very long list of them.  And it does get difficult to find the one you’re looking for in a maze of iconography. 

So the new DNN 7 control panel uses the concept of common, less common and user-configurable areas.  Or, in plain-speak, things you use all the time, things you don’t, and a place where you can make your own list. 


Above : The Host Menu in the Control Panel.   The three icons on the left are Common, Advanced and Bookmarked.  So very common actions like installing extensions or using the File Manager are close at hand.   Less frequent tasks like configuring Google Analytics are in the Advanced section.  And the bookmarked section allows you to bookmark the things that you use more often.  

Again, for the seasoned DotNetNuke professional there is a small learning bump because things have moved around.   But once you’re over that, it’s more productive.

The Minus

5 points of praise in a row might sound like a shallow review.  But I’m not enamoured with every change.  All the standard core icons have changed to a very flat, two-tone scheme in line with the Microsoft Metro direction.  And I think the lack of color sours things.   I like a bit of color.  Anyone following me on twitter has probably seen me griping about the direction of Visual Studio 2012 in the same way.    As someone who started on single-tone computer monitors, it’s difficult to convince me that dumping 30 years of color-monitor development is a serious step forwards.  But I suppose someone might give it a good try.


One conclusion really : get DNN 7 as soon as you can.

Sure, it requires more modern IIS and ASP.NET runtimes, so you can’t run it on an old IIS6 machine.  Think of it as a positive step forwards.  A very good reason to investigate that new hosting deal or find a new server for your site.  But get on the upgrade path as soon as you can.    You’ll agree with me : DNN 7 is a very solid step forwards for the platform.

NOTE : iFinity Url Master customers will need to upgrade their Url Master version with the upcoming 2.7 version before upgrading their DotNetNuke site to 7.0.  This information will be published very soon.



You can watch the cool launch video here:

DNN 7.0 : Simply Beautiful, Simply Powerful

More ...

Redirecting bad Urls in DotNetNuke

Mon, 29 Oct 2012 02:31:56 GMT

Recently I delivered a talk at the Orlando DotNetNuke User Group (ODUG) – the topic was ‘Url Best Practice for DotNetNuke’.   I enjoyed giving a talk to an enthusiastic audience and fielded some great questions, anecdotes and was hopefully able to impart some valuable knowledge to the attendees.  I have learned a lot of lessons in the years that I have been working in the Url space and some of those lessons are learnt the hard way.

[The entire presentation was recorded and is available at ODUG Meeting October 2012)

One thing I raised in the talk was the ability to use the siteurls.config file in DotNetNuke to handle redirects.  While this is an old feature of DNN (it has been around for many versions) there were quite a few people in the room who weren’t aware of it.

Today I was trying to sort out a problem with this site, and while checking the event log, I noticed a pile of exceptions from a bot that was hitting the site with malformed Urls.  One of these exceptions is shown below:


Essentially a bot had come up with a Url which looked like this:


It’s probably from someone posting some Html in a forum, which can end up with unfollowable links.  But it’s clogging up the event viewer so it needs to be dealt with.

The easiest thing for me to do is to plug this into Url Master to redirect back to the Support Forums page, by entering ‘Products/Support_Forums/forumid/8/postid/1432/scope/__doPostBack('dnn$ctr993$UrlOptions$lblRedirectResultsLabel$cmdHelp','')’ as a 301 redirect for the Support Forums page.

A quick check on the test function, and I can see it’s working OK:


However, this approach isn’t available unless you have the module, and doesn’t scale well if the bot is hitting many different variations of the underlying Url.

And sure, enough, if I poked through a few more pages of Urls, I find similar bad Urls being requested:



What I need was a more generic capture-and-redirect strategy to find these bad Urls and redirect them to a valid page, where they wouldn’t throw an error.

Using the siteurls.config file to redirect Urls

What I decided to do was use this as a teaching moment to show how to redirect a bad Url using the in-built DotNetNuke tools.

For this, we need to use some simple regex (cue groans at the back of the room).  This goes into the ‘match’ part for the rules (or the ‘lookFor’ if you’re working with the file directly, rather than using the UI).

It’s simple regex because we just need to match the same basic pattern, but allow for variations in the postId/threadId and the different ‘doPostBack’ values.

This is the regex I came up with:


This will match either of the two Urls listed above which are throwing the error. 

Breaking it down:

.*/ matches the first part of the Url, essentially the domain name

Products/Support_Forums is a direct match – this just matches if this is found in the Url

/forumid/(\d+) is a combination of directly matching the text, but also matching any integer value for the forumId (forumId/ – text match, \d+ – any combination of digits [\d])

/(postId|threadid)/(\d+) matches either postid or threadId (the | is an ‘or’ operator) and also any matching integer value.

/scope/__doPostBack[^/]+ matches when the /scope/ value has been provided with any __doPostBack…. value.  The [^/]+ means match any combination of characters, as long as they are NOT / (^ is the not operator).  So it just means match the rest of the Url if it starts with __doPostBack.

The second part of doing a redirect is telling DotNetNuke where to send it.  This is done by writing another (gasp) regex expression.

Here’s the regex I wrote to go with the ‘match’ part, which is the ‘Replace With’ value:$1/$3/$4/scope/posts

The key here is that the above value is an absolute Url – it includes both the domain name and the http://.   This is the way to differentiate from a rewrite rule and a redirect rule in the siteurls.config file.   This is the point I discussed at ODUG, which many people did not know.

In comparison to the match regex, this looks rather tame.  It’s just the absolute Url for the redirect, but with placeholders for matched sections from the first regex.  Wherever the ‘match’ regex has an expression in brackets, it’s called a ‘capturing group’.   And we can refer to the results of that group just by number, reading left to right.  That’s what the $1, $2, $3 etc means – take the matched values from the ‘match’ expression and put them into these spots.  So it will copy across the forumId, postId/threadId value, and the results of the postId/threadId parameter, and use that for the redirected Url.

That flexibility saves me from having to enter a different Url for each match that is possible.

This is entered directly into the Host Settings->Friendly Url Settings section, and saved.


(click image to enlarge – yes, the length of the rule breaks the layout somewhat)

You can also enter the rules directly into the siteurls.config file if you want (but be sure to use an xml encoder to make sure they are xml-legal)


Now that’s done, we can test the Url and see if it works OK.   I always check with Fiddler, but you can just use your browser to see. 


You can see that the Urls are now being redirected to a good, clean Url and won’t be bothering my event viewer anymore.

Note for Url Master users

Url Master takes precedence over the siteurls.config rules, so if you want a siteurls.config rule to run, you will need to add a bit more regex to the Url Master settings.

For this one, I just added |/scope/__doPostBack[^/]+ to the end of the ‘useSiteUrlsRegex’ pattern, which specifically identifies these Urls ending with /scope/__doPostback and then sends them to the siteurls.config file for processing.

More ...

DotNetNuke World Presentations

Sun, 14 Oct 2012 12:25:00 GMT

Well, the curtain has come down on yet another successful DotNetNuke conference, DotNetNuke World 2012 in Orlando, Florida.

This year I presented twice at the conference, participated in the new ‘Vendor Showcase’ and also presented at the Orlando DotNetNuke User Group the night prior to the conference starting.

I’d like to thank everyone who came to my sessions – it is gratifying to speak to a mostly-full room, and in the case of the ODUG meeting, a crowd that overfilled the room and spilled down the hallway.   I had a lot of good feedback from people and it was great to meet a lot of customers and colleagues, sometimes for the first time, sometimes to catch up again.

I'd also like to thank PowerDnn for a fantastic giveaway competition that really captured a lot of attention. It was the choice of a Lamborghini rental for the day, or $1000 in cash. Needless to say, I put my entry in. Well, I don't want to talk about the outcome too much more, but just wanted to post this photo:


The whole competition gave me a good chance to talk to Jeff and Tony from PowerDNN – they have just launched a new data centre in Brisbane, just down the road from me (when I’m home!) and have confirmed their commitment to helping us grow the South East Queensland DotNetNuke User Group (SEQDUG).  

As usual, the best part about the entire conference was the buzz, friendliness and sheer fun the whole event was.  It passes in a blur of activity, late nights and early mornings and always leaves everyone exhausted but keen to return the next year.  And that describes my feelings exactly!

Here are the slides that I have presented:

Advanced Google Analytics for DotNetNuke Social Websites

This presentation was all about showing attendees how the social features in DotNetNuke aren't able to be captured by the traditional pageview model, and how to use Analytics Events to capture the data

Developing Mobile Applications for DotNetNuke

In this presentation, I showed a new DotNetNuke dashboard mobile application that has been built in Windows Phone 7. I covered DotNetNuke services, Authentication and how to utilise your DotNetNuke web application as a cloud-based datastore to a mobile device.

Url Best Practices for Editors, Administrators and Developers

This was my Orlando DotNetNuke User Group (ODUG) presentation. In this topic I covered the use of links inside a site, how to structure links so that external links not only get created, but how they maximise the SEO value. I also talked about selection criteria for modules that use the right urls, and how to build modules so that you can maximise your Url strategy.

UPDATE : The video of this talk has been posted online:
Bruce Chapman - ODUG Presentation October 2012

To everyone I spoke to, caught up with and shared a good laugh with : see you next year!

More ...

Changing a Page Title with Javascript to update a Google SERP Entry

Thu, 04 Oct 2012 02:58:45 GMT

When it comes to SEO knowledge about what can and can not be done with Google, a basic rule of thumb is : beware of what you read and how old it is.  Once upon a time, it was regarded as common knowledge that Google can’t read querystrings on Urls – OK, I’m going back a way with that – but of course we all know that isn’t true nowadays.

Another common rule of thumb is that Google can’t read or execute javascript in a page.  Well, I’m here to tell you that Google can – and does – read and execute Javascript on a page.

The Problem

I’ve done a few posts on setting up your DotNetNuke site with the new DotNetNuke social features, which includes configuring your DotNetNuke site to be a social network, and how to set up Vanity Urls for your DotNetNuke site using Url Master.

That’s all good, but there is a shortcoming in the DotNetNuke user profile design in that it doesn’t change the page title to reflect the current user that is being displayed.  The page title stays at ‘User Profile for’, no matter which user is currently displayed. 


Above : SERP Title is derived from the DNN Page Title, which is not user-specific for profile pages.  This is taken from about a month ago.

(Do you want your Author profile to show up for your pages like in the screenshot?  See my post on getting your Author Profile to show in Google Search Engine results)

What we really want is for the Page Title to show something specific to the content on the page.   Assuming we want good SERP results for specific User pages, which is definitely the case if you have a Linked-In style directory.   Or even to avoid having Google Webmaster Tools not complain that we have x,0000 duplicate Page Titles for our pages.

The Solution

Initially, I thought the solution was going to have to be writing some little module that I dropped on the profile page(s) and which set the page title directly.   (Short of getting the Core team to change the User Profile page code).   But then I came across this little blog post : Use Javascript to generate SEO Friendly Title Tags – so I thought I’d give that a go.

The key, as outlined in the post, is to not get too fancy with the javascript.  I don’t know exactly how much javascript Google reads and interprets, but I’m guessing relying on the jQuery framework mightn’t be a good idea.

So, with that in mind, I wrote out a basic piece of javascript and put it in a text/html module at the top of my page, to get it executed as early as possible.

The code is this:

This would then set the page title to the person of which you’re currently viewing, by simply pulling the text for the ‘Register’ link.

This worked great as far as viewing the pages went :


Above : The Page Title changed by Javascript

I left that go for a while, to see what happened in Google.

And look!


Above : New Google SERP For the same link, taken at time of this blog post.


Wait, no so fast…

The Title is wrong.  It should be ‘iFinity User Profile – Bruce Chapman’

(NOTE: You can see here my new search engine sitemaps have outranked my old search engine sitemaps – interesting..)

This is just the Google Author changes making their way across the web.  In fact Google seems to have gone mad and Author-tagged any page it finds ‘Bruce Chapman’ on.   And to think I felt it was an achievement to get just one Author tagged-SERP!

Those awake in the back row would have put their hand up and pointed out the obvious problem – the ‘dnn_dnnUser_RegisterLink’ only shows the logged-in user, not the user in the profile page.  Google always crawls the web as an anonymous user, so won’t see the Display Name of the user when visiting the user profile.

A quick google of some other User profiles shows that this is true:


Apologies to Chris Hammond for using him as a guinea pig.

While this still brings up the Bruce_Chapman Url, what we can see is that the Page Title for this user profile has changed (ignore the fact it’s showing my Author profile again) – it says ‘iFinity User Profile – undefined’

That means that Google has read the javascript and changed the page title – even though my javascript was wrong (the anonymous view page doesn’t find the element, so returns ‘undefined’)

With that result, I’ve been spurred on to test this out further. 

The problem is finding the current User Profile name on the page.  Because the User Profile name on the page is updated by Knockout.js doing a web services callback to the server to load the user profile information.   So you can’t just stick some javascript in the header to find and load the Display Name from somewhere else in the page, because that in itself is being loaded by javascript.

But inspecting the SERP here, I can see that it has matched ‘Chris Hammond’ from the Journal feed on the user profile page.  Which means that Google must be executing the Knockout code to load the dynamic content for the profile page.

The New Experiment

So now I’ve updated the code on the page to this:

(Hint : if you’re adding some script like this using a plain Text/Html module, then I suggest switching out of ‘rich text editor’ view and into ‘basic text box’ with ‘text’ view – otherwise your script will be stripped out when you update)

You’ll note that the script is much the same, except now it’s surrounded by a ‘setTimeout’ call, which waits for 1 second, then updates the page title.  This should give enough time for the knockout to update the page title, but will it be enough for Google to read the new title and index it?

You can see the new Page TItle just by going to (or click on your own profile, if you have an account on this site)

Time will tell.   You can google it yourself now to find out if it has been updated.

Looking forwards

This technique is not limited to user profiles.  If you have any type of 3rd party content that doesn’t update the page title to the way you like it, you should be able to experiment with changing the page title.   This technique could be tried with blogs, e-comerce modules, forum posts – anything that isn’t updating the page title to your liking.  It should be possible to also apply this technique to updating the page description as well, something else I will try as time goes by.

The reason I have posted this before the experiment is complete is to hopefully encourage others to try similar experiments with their own sites to see if this works OK, and can be used to expand the ability of DNN sites to be SEO optimised even when you’re up against a code-wall, where the underlying code doesn’t do exactly what you want.  There’s always a way, after all.

More ...

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

Fri, 21 Sep 2012 07:40:44 GMT

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  - 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 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:


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.


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.


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. 


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.


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.


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


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 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!

More ...