iFinity Blogs 

How to configure Vanity Urls for Members in DotNetNuke using Url Master

by Bruce Chapman on Thursday, July 19, 2012 8:55 PM

Vanity Urls are simply using a user-chosen Url in order to show a user profile or home page for the user.    They’re very common in websites from twitter to ebay.   People like to have simple and, yes, vain Urls for their home page.   With DotNetNuke moving to more social features over time, culminating with the release of the 6.2 module, more site administrators are looking for ways to give their site members vanity Urls.

The Url Master module has had the feature of creating Vanity Urls for some time (since version 2.0 was released).   This feature allows the designation of a specific page in DotNetNuke as the ‘User Profile’ page, and any references to user accounts on that page are changed to a simplified vanity Url.

Url Master Vanity Urls explained

The Url Master module vanity Urls are controlled by the user accounts in the DotNetNuke website.   They are a built-in feature because the data (user accounts) are present on every DotNetNuke installation.

Whenever I explain about manipulating the Urls on a DotNetNuke site, I refer to a three-legged strategy.  (I have described this in the past as a three-legged stool)

The first leg is url replacement – which means the process of taking an unfriendly Url (/default.aspx?tabid=654&userId=135) and transforming it into a Friendly Url (/user-name) for the links on the page.

In the User Profile functionality, the page path of the User Profile is removed from the Url, and replaced with either the username or Display Name of the user.   By doing this, the generated Urls throughout a DotNetNuke site are replaced with the vanity version.  This is most visible in the link for the register/user control, which shows the display name of the logged in user by default.

The second leg is url rewriting – which means the process of taking a friendly Url, as requested by a browser, (/user-name) and transforming that back into a format that the underlying website code understands (/default.aspx?tabid=654&userId=135)

The User Profile rewriting code looks for matching requests for the username or display name, and then constructs the rewritten querystring using the saved User Profile tabId.  This ensures that DNN will load the correct user profile page, even though it isn’t specified in the Url.  The module then constructs the user-profile specific part of the Url by taking the parameter specified in the ‘User ID Parameter Name’ field, and adding that, along with the matching User Id, to the querystring for the rewritten Url.  These two actions generate the ?TabId=xx&userId=yy (where ‘Parameter Name’ is ‘UserId’)

The third leg is url redirecting – the process of looking for Urls which aren’t the ‘canonical’ version of the vanity Url, and forwarding any request for them to the canonical version.  Essentially, this means, if you request  userprofile/userId/6, it should redirect to /my-user-name.

Dealing with the Exceptions – or – why users make it so hard to give them Vanity Urls

So far, so easy.  Just match up the Url on the username, and put the matching userId into the rewritten Url.  Simple?

Unfortunately, nothing is ever that simple.

For a start, some administrators prefer that the Username of all of their members are hidden at all times.  This is because the username is part of the authentication pair of username/password to gain access.   It’s a security measure for the username to at least not be readily available.   Coupled with this, the Display Name is often more ‘vain’ than the user name, as people may use a simple username (ie user432) but more complicated Display Name (J. Long Fancy-Name, Jr.).

This is why the option of using a Display Name to create the vanity Url is more popular than using the username.   But, as any seasoned developer will tell you, once you give the users free reign to input data, that’s when all your troubles begin.

For a start, prior to DotNetNuke 6.2 (and, even with 6.2, it’s an option) the Display Name has no restriction on being unique.  So, you could have 60 ‘Fred Jones’ people on your website.   This rather dents the usefulness of using the Display Name as a canonical Url.  The Username field doesn’t have this problem as uniqueness is enforced at the time of creating a user account.

For a second, Urls are formed by a very restrictive character set, (the basic ASCII character set, minus the reserved characters).  But Display Names (and to a point, usernames) are not.   I got quite a comprehensive lesson in this when the user profile Urls functionality was first released and used on a large site.  The members of that site seemed to take particular pride in coming up with incomprehensible combinations of Unicode characters and even non-display characters like tab and page feeds into their Display Names.  It would seem that trying to foul up code with inventive Display Names is an active pastime amongst some folk.

So, in order to make some Display Names usable as Urls, they need to be cleaned up.  This means replacing and/or removing any characters in the display name to make it suitable for use as Url.   However, here’s the rub : if you remove part of the display name to make it suitable for a Url, you can’t use the resulting Url to find the user, simply because the display name changed.   Take an example : a user has a display name of ‘<"pâü",?>’ – you might think nobody would use that as a display name, but that’s an actual example.   By the time we remove all the Url-illegal characters, the resulting lookup name is something like –p-.   When it comes time to finding the matching username, looking up for a user with a display name of ‘-p-‘ won’t find the correct user.

Along with the removal problem, there is the duplicates problem.  Any display name that is duplicated cannot be used, because looking up on the display name (even if no characters were removed) will result in two or more users being returned.   Another solution is required.

In these cases, another solution is needed.  Simply, the display name cannot be used as a lookup value.  To solve this issue, the Url Master module ‘falls back’ to a Url which contains the DNN page name, userId parameter and a cleaned version of the display name.  Thus, the example User Profile Url becomes /User-Profile/UserId/48/-p-.aspx

It’s not a very friendly Url – but the user doesn’t give us much to work with.   It’s important to remember that this is a fallback position – if people use sensible display names like ‘Bruce Chapman’, then there is no problem in providing /bruce-chapman.aspx as a Url.

There is one further wrinkle to this story – the list of characters removed from the Urls has always been ‘hard coded’ in the Url Master module.  However, some administrators have wished to allow certain punctuation characters into their Urls, but this hasn’t been possible.

DotNetNuke 6.2 to the Rescue

Thankfully, with DotNetNuke 6.2 there are some remedies to this problem.   In the ‘Site Settings’ of DNN 6.2, there are some new fields:

- Display Name Format : which constructs the Display Name field from other fields, such as the First Name and last name.

- Require Unique Display Name : which enforces a unique Display Name field so that it can be assured to belong to only one user in the site.

However, this still doesn’t completely solve the problem of users including characters which are not legal for Urls, but it is an improvement for the majority of sites.

DotNetNuke 6.2 Profile Pages

Much of the new social changes in DotNetNuke 6.2 centers around ‘Membership’ – that is, of users joining groups, making friends with one another and generally being referenced throughout the site.    As such, there is much more information present in a new DotNetNuke 6.2 site.   The old ‘User Profile’ page has gone from a private, authenticated visitor only page to a public open page, including ‘Friends’ and ‘My Profile’, while the ‘Activity Feed’ page becomes the base page.

This impacts the Url Master module Vanity Urls because, while the bottom-level page configured to use the Vanity Urls works the same, the other pages revert to the original format of /activity-feed/my-profile/userid/45.aspx  - which breaks the Vanity Url flow.   For consistency, it would look better as /user-name.aspx /user-name/my-profile.aspx etc.

Url Master 2.6  - DotNetNuke 6.2 specific Changes

There has been a new release of the Url Master module, (version 2.6) which contains some changes to address the issues already mentioned.

These are in two broad areas:
1.  Child pages for Vanity Urls

With 2.6, any child page of a User Profile page will appear as a child of the vanity Url.  So, if your display name is ‘Fred Jones’, your user profile page will be /fred-jones.aspx, and your ‘My Profile’ and ‘Friends’ pages will be /fred-jones/my-profile.aspx and /fred-jones/friends.aspx.    There are no configuration changes to make, this will happen automatically for any first-level child pages of the page configured as the User-Profile page in the Url Master settings.

2.  Harmonisation of Url Cleaning routines

Url Master 2.6 contains some under-the-hood changes to harmonise the way the Urls are ‘cleaned’.  By this, I mean the way in which Url illegal (: ? &) and Url unwanted characters are removed from a value used to make up a Url (like a DNN page name, or User display name).   This just means you’ll get better vanity Urls – if you want to fully understand the impacts of this more, please go to this blog post which explains the entire concept of how the Url Master module creates clean Urls in detail.

Configuring Vanity Urls using the new Options

Finally, after all the explanations, we get to the point of configuring Vanity Urls for DotNetNuke 6.2.  Here’s how you do it:

(These instructions assume a fresh DotNetNuke 6.2 ‘out of the box’ – you may have to adapt the tabs/settings for your installation if you have upgraded a prior version).

1.  Go to the Admin->Portal Urls page, and click on the ‘Portal Setting’ tab.  Scroll down to the bottom, and find the ‘User Profile Rewrite’ section.

Above : the User Profile Rewrite section

2.  Select the ‘Activity Feed’ page in the list of tabs.

3. Choose either the ‘Username’ or ‘Display Name’ field for the source of the Vanity Urls

4. Add in ‘UserId’ as the parameter*

5. Leave the ‘other parameters in rewritten profile’ blank.

6. Check the ‘Redirect old profile Urls’ box.

Once this is done, click the ‘Apply Changes’ button, and the Vanity Urls will start working.  You can check by clicking on anywhere in the site that a User profile is linked.

NOTE: The DNN 6.2 ‘Members’ module uses a way of matching UserIds and doing a replacement.  Hence, if you look at the Urls, it will still be in the /user-profile/userId/xx style of Url – this is because each member Url is not fed into the Friendly Url Provider API.  However, if you have the redirect option activated, it will redirect to the correct Vanity Url.

Friendly Urls for Social Groups

Once you have Vanity Urls for your DotNetNuke site set up, you may also want to configure your Social Groups to have friendly Urls.  That is achieved by using the Url Provider for DotNetNuke Social, which is a free download.  With these two features installed and enabled, you’ve got true vanity Urls for your DNN Social site.

Comments, Questions?

If you’ve tried this out, please let me know of successes and failures, and don’t feel shy about shameless links to your DNN Social site.

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.

3 comment(s) so far...

Anonymous 8/15/2012

Thanks Bruce, this looks interesting. Going to have to give it a go...

 
Anonymous 10/3/2012

Do you know how to get the title of the page to change? They all seem to say "My Profile"

 
Bruce Chapman 10/3/2012

@lance - as it so happens I've been experimenting with this by using javascript to change the user profile title in such a way that google reads the javascript-modified value and indexes it. I hadn't checked for a while until your comment, and then I looked up <a href="http://www.ifinity.com.au/Bruce_Chapman" rel="nofollow">www.ifinity.com.au/Bruce_Chapman</a> on google (my profile on this site) and the Title has updated in the SERP. So I will blog about how I did that very soon.<br /><br />Of course, it needs an update in the core User Profile module to handle this instead, but this way is a way to work around the problem until that is done.

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