iFinity

Written by:
Wednesday, July 07, 2010 8:48 PM 

Today is the announcement of a release about 18 months in the making.  I started out with a quick sketch of functionality for a major upgrade of the Url Master module and added some of these points into my issues tracking system back in June 2008, only months after the first release.  A roadmap and prototyping was started in January 2009 and the Version 1.x code was branched in April 2009, the first workable Alpha version was going by January.  But as any developer knows, the 90% complete mark means that 90% of the work is yet to be done.  Finally that is the case and the module is ready for the wider DotNetNuke community, and I think it will make a big impact on what DotNetNuke site owners can expect from the platform with regards to Urls.

What’s new in Url Master 2.0

The main areas where the 1.x versions could be improved was in these key areas:

- Portal specific settings : most of the settings were specific to an entire DotNetNuke installation and all settings were applied to all portals.

- Multi-Language Urls : On a Multi-Language (ML) site, the Urls for the secondary languages all used the same domain name, and all used the same page names.  They also carried the /language/en-US style path parameters as the way of specifying which language to use both in core features (like logon/logoff links) and in content modules (using the myriad of third-party content localization modules).

- 404 Error Handling : A large shortcoming of the ASP.NET platform is the use of a 302 redirect to handle the 404 Error page.  I understand the reasons for doing it this way, but in the modern web, working with search engines is very important, and search engines want to know which links are dead and which to index.

- User Interface : There was no hiding the fact the old interface was more focused on getting as many options into a page as possible and less focused on making those options understandable by the majority of DNN site owners and administrators.  The old interface made little effort to separate out the basic, understandable settings from the complicated (and frightening to the uninitiated) advanced settings.

- Performance and Memory Management : The Url Master module runs a cached index of DotNetNuke pages.  This new version has improvements to reduce the size of the cache and to reduce the number of lookups used.   Other code refactoring has resulted in detecting much earlier in the logic when to redirect, preventing rewriting from occurring on Urls which are to be redirected anyway.

Portal Specific Settings

In version 1.x of Url Master, all major settings were shared across all portals in an installation.  This applied to items like the replacing of spaces with hyphens, the choice of page extensions and the choice of using lower case Urls.  For many people this wasn’t an issue because they only ran one portal per installation, while for others, particularly those who host a variety of customer sites in one installation, this meant that there was a loss of flexibility.

Version 2.0 improves on this situation by allowing for per-portal settings.  It works by specifying a ‘base’ set of settings which apply to all portals.  Any portal in the installation can have a different setting, which will override the base setting, or can be left to use the ‘default’ base settings.  This keeps the flexibility of changing the settings at a base level and working for all portals, but allows individual fine-tuning of portals where necessary.

Multi-Language Urls

This has already been covered in my blog post Multi Language Features of Url Master 2.0.  To recap, there are now two ways in which you can define language specific Urls in the Url Master module – by domain and by page (or both).

By Domain

Essentially this means that you can associate a domain [in this case, equivalent to a portal alias] with a specific language.  This might be a subdomain (fr.example.com) or it might be a different top-level domain (example.fr).  It can even be a top-level path imitating a child portal(example.com/fr).  When this is done, every single Url generated by DotNetNuke with language/fr-FR in it will have the /language/fr-FR path removed and the domain name returned as the chosen domain name.  

In addition to this, any old Urls for the site (example.com/pagename/tabid/xx/language/fr-FR/default.aspx) will be automatically redirected to the new Url (example.fr/page-name).

This means you can transform the language-specific Urls for your site and run a well-separated multi-language strategy.  Google Webmaster guidelines recommend using a specific domain name or top-level path with localized content, as it assists with Google recognising language-specific sites and ranking them well for the associated language.

By Url

Setting a language by Url means creating a custom Url for each language on a page.  By default, all page languages use the same page name as created in (presumably) the default language.  This is then used with the language/xx-YY modifier to deliver different language content for the page – both in core skin objects (login, terms, etc) and with content-localization modules which present different content based on different culture codes.

This means, for a hypothetical French language page, you’d see example.com/products/tabid/xx/language/fr-FR/default.aspx.  Without a customised Url for the page, Url Master will automatically reduce this to example.com/language/fr-FR/products.aspx.   With a custom language-specific Url, you’ll get example.com/produits.aspx.  This Url will automatically rewrite the Url to include the &language=fr-FR behind the scenes, so all content localization will still work in the same way.  You can also combine the custom page urls with the language-specific domain names, so you can end up with fr.example.com/produits.aspx.   This is the best-case ML SEO solution, because it (1) signals to search engines that the content is localized to the fr-FR culture, and is more likely to match the Url to a keyword a French-speaking person would search for (produits).

404 Error Handling

For the uninitiated, a 404 error relates to the Http status code returned by a website when a requested Url doesn’t match any content on the server.  The term ‘404’ has entered common usage as a shortcut for referring to a ‘page not found’ situation.

By default, standard DotNetNuke doesn’t really handle 404 Errors at all.  You’ll either get the default 404 error page (which is optimised to answer the most common installation issues) or you’ll get an ASP.NET 404 Error when you request an invalid page.   If you set up a ASP.NET 404 error handler, you end up with the strange situation where a page not found is redirected to a found page, which says ‘page not found’.   As far as visitors are concerned, this is OK.  As far as search engines are concerned, it’s not good because they rely on the http status codes, and can’t tell the difference between a valid redirect and one that is the result of an invalid Url being followed.  People make mistakes linking to your site all the time, and these generate a lot of 404 errors for an established site. 

Google has recently started handling this ‘not-really-a-404-error’ problem itself, and now has the concept of ‘soft’ 404 errors in Google Webmaster console.  This means you can get a page on your site incorrectly identified by some type of Google code as a ‘soft 404’ – which means that Google thinks it’s an error page and takes it out of the index.  This recently happened to one of my more important old blog posts, which was happily bringing in a lot of visitors for long-tail searches, but Google decided it was actually an error page (nothing of the sort) and removed it from the index.

The result of all of this is that you need a ‘real’ 404 error handler.  And that’s what is in Url Master 2.0 : you can choose to use your current setup, or you can specify a Url on your site [example: a 404.htm page you have written] or you can create a DNN page and specify that as your 404 page.  By doing this, any 404 error on your site will result in the specified page/Url being shown, but crucially, it will return a 404 http status code and thus search engines (a) know it is an error and (b) stop making guesses as to which pages on your site might be error pages.

In addition to 404 Error Handling, the new version also includes a 404 error log.  This log shows a list of all the Urls which have resulted in a 404 error page being shown.  By reviewing this list you can detect commonly requested Urls and either create a redirect to somewhere correct, or find out where the visitors are coming from and get the link fixed.

You can read more about the 404 Error Handling in the blog post : Real 404 Error Handling for SEO in DotNetNuke

User Interface

It’s an awfully clinical phrase : ‘User Interface’.  No doubt coined by computer scientists a long time ago, and I’ve been using it by training and habit for the last 20 years or so – and so unlikely to stop anytime soon.  In reality it’s the visible parts of the program, the way that real people interact and control the functions.    The first iteration of the module was done with the emphasis on getting the ‘oily bits’ of the program to work correctly – very little time was devoted to making it pretty to look at or intuitive to use.   This next iteration has resulted in a large amount of time spent on making the interface usable.  There’s a fresher design, AJAX functionality in tasks like lookups and the test functions, client-side script for other items.  The interface is faster to use, and is logically grouped into areas allowing first-time users to get to grips with the basics and not be overwhelmed, but allowing experienced hands the ability to endlessly tune configuration to get the best results.

I thought about posting some examples of the interface here – but instead decided to let people’s curiosity drive them to the download button!

Performance and Memory Management

The Url Rewriting and Friendly Url generating solution for any site is one of the most heavily used parts of the code, as it literally runs all the time and is used many times in each request.  The original version always performed as well as the standard DotNetNuke Url Rewriting, and this was down to the care taken when building the core of the module to work within the constraints of the platform and to consider throughput as the first priority.  This new version takes up where that left off, and introduces important new changes, including per-portal memory caching.  In version 1.x, when the first request came in for one portal, all portals Urls were then loaded into the memory cache.  This left the site ready to handle requests for any and all of the portals, but in larger installations slightly penalised that first request.  This new version optimises this further by only loading the page index on a portal-by-portal basis.  It’s actually quite common to have one portal dominating all the traffic for a DNN installation, so with this change, a dominant portal will not get slowed down by its less-used installation siblings.   

Another improvement in this front is the loading of Urls for portal alias entries that are used.  One of the key improvements in this version is the much stronger ability to detect and redirect away from Urls which use a portal alias not designated as the ‘chosen’ portal alias for the portal.  It’s very common to have example.com and www.example.com for a portal – the old version would cache all the urls for each, meaning the cache size was [num of portal alias entries x number of tabs] for each portal.  Now this is [num of chosen portal alias entries x number of tabs] – in the most common case, the administrator chooses www or non-www – this immediately reduces by half the amount of memory taken up by the page index.  It’s not a huge difference but all these small enhancements add up to a better and faster product.

Other Fixes and Enhancements

There are plenty of other fixes and enhancements in the module – a small example is the dropping of the requirement to enter both the www and non-www version of the portal alias.  The module will now work with one or the other, and will automatically redirect to the one that is entered in the portal alias table.   The Test Url Rewriting and Test Friendly Url Generation pages are now located on the same page, so you can quickly test generation of Friendly Urls and immediately check the Url Rewriting results without scrolling around and copy/pasting bits of Url everywhere.  In the middle of all this is the usual fixing of small bugs found by the active and vocal community of people who use this module for their live websites.

And remember – all the other existing features are still there : better friendly urls, automatic redirects, user profile Urls, custom redirects and much, much more.

It’s ready – go and get it!

After that long build up – the module is ready and released to the wider community.  You can download it for a free trial from the Url Master Product Page – even that has had a makeover as part of the release.  It’s compatible with all DotNetNuke versions after 4.6, including all the 5.x versions.

Upgrading from Url Master 1.x

As 1.x versions have been out for over two years, there are a lot of people around with this module installed in their site and relying on it from a day-to-day basis.   The upgrade path is very simple : you just install the new version and it completely upgrades the old version, carrying across all the old settings and configuration.  About the only thing you need to do is to remember to press Ctl+F5 to refresh the stylesheets so you get all the new interface details.

However, it is a paid upgrade from any 1.x version to 2.0.  Unless you purchased your copy since June 22, 2010, you will need to purchase a module upgrade and request a new licence Keyfile.  The cost of upgrading your existing Url Master 1.x version to Url Master 2.0 is $30. 

I don’t recommend upgrading your installation until you have purchased an upgrade and received your updated licence keyfile (which has a product version of 2.0 in it).  If you upgrade your install first, you’ll have an unlicensed copy until you receive your keyfile.  It’s all automated delivery now, but things can get delayed and I would hate to have customers disappointed.

If you purchased a copy since June 22, 2010, you should have already received a Url Master 2.0 licence keyfile.  You can easily check this by looking in the licence keyfile, it should have a licence version of 1.4 and a product version of 2.0.  If so, you can just upgrade your install by downloading the new version and uploading via the DNN Module installer.

Comments, Questions, Feature requests for Version 3.0?

This new version of the module is the result of a lot of feedback, discussions and requests from committed customers who help to make this product great.  I’m hoping that the module will prove to be a real step forwards in the arena of DotNetNuke Url generation and rewriting.  If you’ve got any comments, questions, feedback, or just want to get started on the feature requests for the next version, please pile in via the comments.

For bug reports and specific problems, please post in the support forum.  You’ll get a specific answer in the forum.

Trackback Print

Tags:

Categories:

Location: Blogs Crafty Code

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel