iFinity Blogs 

Building Friendly Urls into DotNetNuke Modules – Part 1

by Bruce Chapman on Wednesday, November 10, 2010 6:06 PM

This series of posts is a blog version of the presentation I did at the DotNetNuke Connections 2010 Conference.    It covers the background, theory and implementation of better Urls in DotNetNuke modules.

Part 1 of this series might be called the Friendly Url Manifesto.  I’m going to put forwards my case for why would even bother, and what’s wrong with many DotNetNuke module Urls.

Short History of Urls

Urls have changed as the world wide web has changed.  I’ve identified 7 stages of Urls throughout the last 15 or so years of the World Wide Web*. 

In the beginning…

Everything at the dawn of the Web was a filename.  In fact, that was the driver of the invention – in order to access all the different papers, information and data available at CERN, the web made it possible to look at anything on any internet-connected server by ensuring that every piece of content had a Unique name.  That was called the URL or Uniform Resource Locator.

So all things looked like this :
http://example.com/example-page.htm

These Urls had to be relatively friendly because there wasn’t any Google to index them all and find them.  So people named them for what they were, and put them into directory folders that made sense.  The Friendly Url was born.

But then came the frames..

Frame based sites soon became popular.  With the advent of frames, website builders could locate a central frame, and vary the inner frame content.  This meant the whole site ran practically on one Url, which usually looked like : http://example.com/frameset.htm

Anyone familiar with Geocities will recognise this.   While the inner frames still had accurate filenames, the drift away from Friendly Urls was starting.

And then came CGI!

CGI stands for Common Gateway Interface (not Computer Graphics Imagery).  CGI was the advent of dynamic pages generated by a delegated program or scripting language.  In effect all dynamic content uses the same ideas as the original CGI, ISAPI is simply the IIS (Microsoft) implementation of the CGI idea.

But CGI gave us such horrible looking Urls as this one:

http://search.ebay.com/search/search.dll?MfcISAPICommand=GetResult&ht=1&ebaytag1=ebayreg&query=(sanrio,hello+kitty)&category0=&minPrice=&maxPrice=&ebaytag1code=0&SortProperty=MetaEndSort&st=0

…which is an ebay search Url taken from the Internet Wayback machine.  The Friendly Url was dead.

…and along came ASP

ASP was Microsoft’s entry into the CGI space, and allowed programmers familiar with vbscript to generate web pages.   The style tended to centralise around a set of .asp pages, which would take tortuous querystring values and dyamically build them, sometimes referring to other pages at the same time.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/wnf_Task.asp

The above Url is a MSDN link from around 2000.  The Friendly Url looked to be gone forever.

…but then ASP.NET was born

With ASP.NET came the idea that you could run all code through a central page and dynamically build everything.  To prove the point, Microsoft created IBuySpy Portal, which became the base upon which DotNetNuke was built.  And so the Urls looked like this:

http://www.dotnetnuke.com/default.aspx?tabid=795

The Friendly Url was lost forever.  Not only did everything have essentially the same Url, contextual text descriptions were dropped in favor of database id values.  From a programmers point of view, this was perfect – one file to maintain, all content stored in the database away from the code.  A pure architecture, a clean separation of code and content.  For the poor person trying to understand what it is on a page, it was baffling to say the least. “I wonder what tabid=795 means?”

…and Google was created and started to yield considerable influence

Google suddenly became very important, because if you didn’t rank on Google, you were nowhere.  And Google, in the early days, didn’t know or want to read querystring information.   So every page on a DotNetNuke site looked like /default.aspx.  Thus the concept of Url Rewriting was leveraged in DotNetNuke and many other web applications.   But in many cases, it was just a reformat of the existing Url into one that contained no querystring.

http://www.dotnetnetuke.com/tabid/75/default.aspx

Still no progress on the Friendly Url front, really.

…and Google’s influence continued to grow

Suddenly, everyone realised that the Url of a page was a significant ranking factor for Google (and other search engines trying to catch up).   The move to Friendly Urls was underway, and new Urls were created to match what people were looking for, and what was on the page:

http://www.ifinity.com.au/Products/Url_Master_DNN_SEO_Friendly_Urls

Descriptive, unique, understandable Urls were back – Friendly Urls are now a must-have for every site.  And the non-programmers of the world finally rejoiced as they could understand what was on pages once more.

*yes, I know the web is older than 15 years.  I was using it 15 years ago and I wasn’t the first.

Why Friendly Urls?

The previous block of text is a long way of proving a point, but it’s an important point to make.  Friendly Urls are important.  They’re:

  • Readable : often the first impression of a page that a user sees is the Url – before they even get to the site.  Think of it as the stationery of your site – the thing that the person sees in another site, in an email, in a search engine.  It’s nearly the only part of the site design that extends beyond it’s own boundaries.
  • Postable : posting links is the lifeblood of the world wide web.  It’s the reason the whole thing was put together in the first place.  Friendly Urls are easy to post (we’ll ignore Twitter until they fix things with an integrated shortener),  easy to email, easy to dictate over the phone.  They look good on the side of a bus, on a flyer or in the footer of your letter templates.
  • Indexable : Search engine bots don’t have to try and work out if there is any superfluous, non canonical information in the Url.  They can follow the links, they can easily work out what the link says about the content of a page.  They get indexed well, and rank well.
  • Relevant to Content : Sometimes in the SEO focussed world of websites, it’s easy to forget there are other ways of reaching a website.  But people deal with Urls all the time – copying, pasting, clicking, viewing, scanning.  The Url for a page should give the casual viewer an idea of what’s on the page.  It’s a known fact that Google Ad performance can be improved by changing the display Url (the green part in the ad that’s not actually the real link) to better match the keyword purchased for that ad.  This is because people strongly believe the name of the Url matches the content of the page.   So make it match their expectations, in the same way they expect the little ‘save’ icon to keep a copy of their work and not shut down the computer without warning.

 

So what is Url Rewriting?

I’m including this section because personally, I’ve found that many people have heard of the concept of Url Rewriting, but don’t actually know exactly what it means.

Url Rewriting is NOT the process of replacing the links in your Html with new links.

It’s related to this – a new link has to work and often it’s a Url Rewriting scheme that makes the links work.  But the act of replacing the links in the Html isn’t rewriting.  It doesn’t have a name at all.  I call it ‘Url Replacement’.  Url Rewriting only happens at the point when a Url is requested from a web server, well before the process of building a page and sending a response has happened.

(incidentally, if you need to dynamically replace the links in a page, either from old links or from text keywords, I have a product for that)

Url Rewriting is NOT the process of redirecting a Url to a new location.

There is a name for that, it’s called Url Redirects.  That’s the process of returning either a 301 or 302 status code, which tells a visitors browser that the Url they requested has moved to a new location.  It’s the mail-forwarding service of the internet, and it’s very important.  But it’s not Url Rewriting.

Url Rewriting is (my definition):

“The process of taking a virtual Url, and changing it into a Url that maps to a physical file, on the server only, so that the requesting visitor doesn’t know”

In other words, it’s a programmatic action which introduces a layer of abstraction between the website application and the visitor.  The visitor doesn’t know the Url has changed, but the website application on the webserver sees a rewritten Url.

In the sphere of DotNetNuke, every page has a TabId (because they were originally tabs, not pages).  So a friendly Url like http://www.ifinity.com.au/Blog is rewritten on the server to be http://www.ifinity.com.au/default.aspx?tabid=65. The visitor continues to see ‘/blog’ but the DotNetNuke application (and any modules installed in it) just see ‘TabId=65’.

The job of doing this in a DotNetNuke application is the Url Rewriter.  Which works in combination with the Friendly Url Provider.  The Friendly Url Provider creates the Urls that a page or menu uses when the page is being created on the server.  The Url Rewriter interprets those and returns them into a format that the underlying DNN and Module code understands.  The two have to work together and understand what the other is doing.

Incidentally, this is why you can’t (easily or successfully) use a generic ASP.NET rewriting solution for DotNetNuke.  Because implementing a new Url Rewriter without changing the Friendly Url Provider is like transplanting a kangaroo leg onto a dog. Two kangaroo legs would make it faster, but one is just going to cause trouble.

How are DotNetNuke Module Urls made (and rewritten?)

Now that we know what Url Rewriting is, and how it works with DNN, it’s time to look at the add-ons for DotNetNuke,  the modules.  

To give an example, here’s a Url from the dotnetnuke.com forum:

http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/77/threadid/381676/scope/posts/Default.aspx

The Forum is a DotNetNuke extension – it’s a core module, but the Urls are handled in a way that’s common to probably 90% of the third-party modules I’ve seen.

Assessing this from our list of Friendly Url traits, we can see that there is no querystring, but the Url is peppered with program-specific information.  It is full of database Id’s, which are great from a programmers point of view, but it means very little to the casual visitor.  In fact this link is for a post about language internationalisation.  But you (or a search engine) wouldn’t really know it.

When this is rewritten, it will look like this on the server:

/default.aspx?tabid=795&forumid=77&threadid=381676&scope=posts

The first part of the Url (tabid=795) handles the loading of the correct page in DotNetNuke.  The rest of the Url is used by the Forums module to identify and show the correct forum thread and display type.

It’s this second part of the rewritten Url that this series will concentrate on fixing.  And that will be in Part 2.

Companion Module

This Blog Series (and the associated Conference presentation) has a companion module.  This is called the ‘iFinity MultiContent’ module.  This module is a simple way of displaying different Text/Html content on a page, by varying the Url value.  It’s built with the purpose of displaying the techniques that will be shown throughout this series of blog posts, and comes available with source code.

You can download it (for free) from this location : iFinity MultiContent Module

More will be explained in the future posts in this series.

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.

8 comment(s) so far...

Anonymous 11/10/2010

Great write up Bruce. Well done.

 
Bruce Chapman 11/11/2010

@rich - thanks for that, more to come.

 
Anonymous 11/11/2010

Great explanation, thanks Bruce.

 
Anonymous 11/11/2010

Great tutorial for us. Thanks a lot and looking forwards to the next part 2.

 
Bruce Chapman 11/15/2010

@all part 2 has now been posted at <a href=" http://www.ifinity.com.au/Blog/EntryId/103/Building-Friendly-Urls-into-DotNetNuke-Modules-Part-2-ndash-Improving-Module-Urls" rel="nofollow">www.ifinity.com.au/Blog/EntryId/103/Building-Friendly-Urls-into-DotNetNuke-Modules-Part-2-ndash-Improving-Module-Urls</a>

 
Anonymous 12/6/2010

Hi, that post is cool! I want to know how we can add a separator character in DNN version 5.6 using the DNN Friendly URL, someone can help me?<br>Thanks a lot!

 
Bruce Chapman 12/6/2010

@christian : no, the standard DNN Friendly Url Provider can't add in separator characters.

 
Anonymous 2/2/2011

@Bruce<br>Excelent series of posts here, we have implemented some of the idea's into a couple of our production sites, which are now doing better in google!

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