iFinity

Written by:
Friday, January 08, 2010 11:03 AM 

This blog post is going to cover a pretty small subset of problems that people have with auto-generated Urls using Friendly Urls in DotNetNuke.    All Friendly Url solutions in DNN, regardless of what module used to generate them, approach the problem of making Urls better by converting some of the querystring values into the actual Url path.

Explained simply, a url which looks like this :

/default.aspx?tabid=64&key=value&text=description

will be converted to a url which looks like this (assume tabid 64 is ‘DNNPage’)

/Tabid/64/DNNPage/key/value/text/description/default.aspx or /DNNPage/key/value/text/description.aspx

The differences between the DNN Friendly Url Provider and the Url Master module is that the DNN provider will keep the tabid and the /default.aspx on the end, whereas the Url Master disposes of these parts of the Url.  However, the main similarity remains : the querystring items are converted to be part of the Url path.

In most cases this is advantageous, it provides a simpler, cleaner Url that is easier for humans to understand, and search engines have no trouble parsing.  It has to be said, though, that the previous problems with search engines not being able to index querystrings are a thing of the past – so the original reasons for doing this have moved on.

Keeping Querystring Items in the Querystring

However, in some cases, the querystring needs to stay on the querystring.  This is a common occurrence with the inclusion of tracking parameters, such as Google Analytics campaign tracking parameters (&utm=xyz) and other affiliate and advertising linked tracking.   The other problem is that analytics packages like Google Analytics and others ignore the querystring, but separate out Urls for tracking purposes by path. 

To illustrate this problem, let’s assume I have setup an advertising campaign, and I want to track the effectiveness of it in Google Analytics.  To do so, I will tag the Url that I am going to send to an email list with special terms in the querystring.  The Url will look like this:

http://mysite.com/Buy-this-thing.aspx?utm_medium=email&utm_source=subscribers

When users click on this link in an email I send out to them, the ‘email’ and ‘subscribers’ tracking values will be traceable within Google Analytics, and I’ll be able to tell how successful this emailing campaign was.

However, if I’m running Url Master on my site, there’s a chance that the Url could end up being:

http://mysite.com/Buy-this-thing/utm_medium/email/utm_source/subscribers.aspx

Now, normally if the Url is valid, the Url Master module won’t convert the requested querystring into a friendly url path, but if there is a redirect triggered then the undesired Url can be generated.   The redirect reason could be : lower case change, page relocated, incorrect subdomain, explicit redirect, etc – most redirects would trigger this behaviour.  While the new Url will work just as well as before, an Analytics package will treat this new url as a completely different Url from the ‘original’ Url.  And that means the tracking data will be messed up and split across different Urls.  This is because the tracking data works off the actual Url entered in the browser – it’s a client-side (javascript) technology, so can’t see the server-side (rewritten) Url, which is what the DNN platform uses.

New Regex Value for Maintaining Querystrings

The solution for this problem has been introduced into the Url Master module from version 1.15 onwards.  This takes the form of a regex value to match any items in the querystring that should not be removed from the querystring.   Note that this works for any Url, anywhere in DNN, and not just for the narrow problem I have described.

This new Regex field appears in the ‘Advanced Regex Settings’ section of the ‘Friendly Url Settings’ page.  When a Regex value is entered into this string, it compares the components of a querystring that is to be converted into a Friendly Url path, and if a match is found, that portion of the match is excluded from the Friendly Url Path, and is left as a querystring.  This flexibility allows picking and choosing which parts of a querystring to exclude, and which parts to leave in.

Now, Regex isn’t the easiest of things to wrap ones head around without some prior exposure and practice.  But fortunately the problem is pretty rare and usually relates to key/value pairs in the querystring used for analytics tracking.   So it shouldn’t take too long before a good catalogue of solutions is published on common problems.

For the example above, to keep the ‘utm=medium&utm-source=subscribers’ in the querystring, I’ll need to create a Regex pattern that will match the full querystring.   It’s tempting to think you can just enter ‘utm’ and leave it at that – however, this would leave the ‘utm’ parts in the querystring, and leave behind the rest of it, resulting in a Url that looked like this:

_medium/email/_source/subscribers.aspx?utm&utm

That’s even worse than what we started with, because the Url would no longer work at all.  You’ll note that the ‘utm’ match has been left in the querystring, and everything else has been shuffled into the path.

Instead, what you need to do is expand the match to locate and find all parts to keep in the querystring.

Here’s a version that works as we want:

/utm_[^/]+/[^/]+

The difference is that this pattern expands to match any querystring parameter starting with utm_, and matches the path of it as well.

There’s a couple of things to note here:

1.  Because it’s a non specific match, it repeats and captures both the utm_medium and utm_source values.  You don’t have to explicitly match each if you can do a partial match (utm_) that works.

2.  The match is actually done on the friendly url path – not the original querystring.  In other words, the key/value pairs are split with path separators (/) rather than the & = of a Url querystring.   You need to write a regex that matches what the incorrect friendly url path is, not what the original querystring is.

If you’re interested in how the regex match works, it’s pretty simple.  The first part matches a part of a path that starts with /_utm – which is what we want.  The next part matches whatever comes between _utm  and the next / character.  This is done by repeating a character match, as long as that character isn’t a /.  This is the [^/]+ part of the match.  It means – match at least one character (+) as long as it’s not the / [^/] – the ^ is a ‘not’ character match.  The next part of the expression says match the next part of the path, up to the next ‘/’ character.  This is the /[^/]+ part of the expression – it is the same as the prior part, but just looks for a string of characters of any type, as long as they aren’t ‘/’.   By understanding this expression, it should be easy to develop an expression that matches the part of the Url.

Setting up the Expression in Url Master

Simply go to the ‘Friendly Url Settings’ page, and enter the regex expression in the textbox preceeded by the label:

Do not include matching items in friendly url path - force to be in the querystring (doNotIncludeInPathRegex)

You can then test it out on the page (before saving the changes) by going to the ‘Test Friendly Url Settings’ box above the regex fields.  Select a page from a site, and, in the ‘Add on the querystring’ section, type in the raw querystring value you would expect to see on the end of the ‘normal’ DNN Url.  In the example shown in this post, this would be &utm_medium=email&utm_source=subscribers

Once you have done this, click on the ‘Show Friendly Url Example’ button.  If you have set it up correctly, you should see the Url generated below the box.  In this Url, you should see that the part of the querystring that you’re trying to match in the correct place in the generated Url.

Once you’re done, click on the ‘Apply Changes’ button, and test the Urls in your browser, ensuring that the Querystring items don’t get transformed into the Friendly Url path.

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