When DotNetNuke 4.9.2 and 5.0.1 landed, they contained a new option on the Page Settings screen : 'Permanent Redirect'
This option allows you to define a new destination for the page in question. To use it, you tick the permanent redirect option, and select a destination Url by defining a Url in the 'Link Url' field.
Once you have saved this option, any request for that page will return a 301 redirect http status code, and provide the new Url as the destination. If you choose a page as the link, the 301 redirect will go to the current Url for that page. If you choose a url, the redirect will be sent to that Url, as is. For this reason, you need to include the full reference to the url, including the http:// prefix.
If you're not familiar with 301 Redirects, I've done a blog post covering their use : Understanding 301 Redirects
Note that you cannot redirect to a file using the drop down list, although you can redirect to a file by simply entering the full path of the file in the Url field.
A quick note to remember. Once you've saved the redirect, you can't use the original Url anymore. If you click on the page in the menu (assuming it's still visible in the menu) then you'll get redirected to the destination. So if you want to go back and uncheck the permanent redirect option, you'll need to go into the Admin->Pages page and select the 'settings' icon for the redirected page.
What's the Permanent Redirect option for?
I've talked extensively about 301 redirects in the past : they are very useful when performing Search Engine Optimisation on your site. This new DNN option allows us to move content from one page to another, and preserve the incoming link value of the 'old' page. Used properly, it will also let you move pages from one site to a completely new site. For example, if you decided to split your site in half and move half to a new domain, you could achieve this by setting up redirects for all the migrated pages. It's certainly a good tool to have.
Problems with the Permanent Redirect Option
There's one significant shortcoming with the Permanent Redirect option. If you have a module which uses a query string on the 'old' page, any redirect to the new page does not take the query string information with it. I'll give you an example:
Let's imagine I have had my blog on a page called 'weblog' for a while. I've done about 100 posts on it over time, and I have some good rankings for some of the pages. But the name 'weblog', I decide, is no longer in. Let's assume I want to change the page name to 'blog'. Now I know that if I change the page name in DNN, the new Urls will just show up under 'blog' instead of 'weblog'. No problem. However, all the links on other people's websites point to the 'weblog' page, and they look something like this : /weblog/tabid/45/entryid/1/my-interesting-post.aspx.
So I decide to 301 redirect all the pages to my new page : /blog/tabid/46/default.aspx. I setup the permanent redirection option, try out the old page : everything is fine. I enter /weblog/tabid/45/default.aspx into my browser and are successfully redirected to /blog/tabid/46/default.aspx. Works great!
I then try to look at one of my blog posts, so I enter /weblog/tabid/45/entryid/1/my-interesting-post.aspx - only to find I get redirected to /blog/tabid/46/default.aspx.
And there is the problem : any querystring information is not passed through to the destination Url. If you have good page ranks for individual module urls (such as blog posts or forum threads) then the rankings for those pages will be lost and transferred to the 'base' page.
Permanent Redirect and iFinity Modules
The first thing people started asking me when this came out was : how does this affect the iFinity Friendly Url Provider and iFinity Url Master modules? The simple answer is : great!
Because of this new flag, the Core team have inadvertently added a feature to my Friendly Url Provider module that was previously only in the Url Master module : the ability to do custom 301 redirects. Note that with the iFinity Friendly Url Provider, when you do the 301 redirect, you do carry across the querystring data, so you can safely use it with modules like the Blog or Forums modules which extensively use querystring information. But the restriction remains in that you can only 301 redirect from an existing DNN page to somewhere else, you can't migrate over old sites by redirecting from any old Url.
Of course the Url Master module could already perform custom 301 redirects, so it's nothing new. The core change does provide a distinct advantage though : something that couldn't be done before. You can now redirect to an completely external Url or file. Previously with the Url Master module, you could only redirect to other DNN Pages. The DNN Permanent Redirect allows you to redirect to an defined url, but you can only redirect from a DNN page url. The Url Master module has always had it the other way around : you could always redirect from any external url (as long as the domain name matched) but you could only redirect to a DNN page. With the release of 4.9.2/5.0.1 and Url Master 1.13.8, you can now do both.
I can see some interesting scenarios with this : I occasionally get requests to 301 redirect from specific pages to other websites (such as to a domain specific for a country or language). This should now be achievable with some creative use of existing DNN pages and destination urls.
Other changes I've made for the 1.13.8 release include showing on the Page Urls screen the redirect to value, if the selected page has the 'Permanent Redirect' option enabled. I experimented with ways to incorporate the Url into the list of urls for each page, unfortunately because it works in the reverse way, that couldn't be achieved simply. I may figure out a way in a future release : for now it is just shown under the page url.
So with this change, where does this leave the Url Master module?
Some people have asked me if using the Url Master module is necessary anymore, seeing as redirects can be done directly in the Page Settings of DNN. The answer is 'Yes, of course!' The addition of a simple 301 redirect system for DNN pages actually makes the module more valuable, because:
- It expands the simple 301 redirect of the Core DNN functionality to include the transfer of any querystring information from the original url to the destination url. This means you can redirect pages used with modules like the Blog module.
- It's still the best way to migrate from an old site to a new site; you can redirect from any arbitrary Url (including Urls for different extensions like .htm and .php) to destination DotNetNuke pages. The DNN Core Redirect only allows you to go from a DNN page to another DNN page, or another Url
You still get all the other great features of the module, including :
- the ability to change Urls for pages
- automatic 301 redirects of the 'old' DNN urls
- 301 redirection to a specified subdomain (ie, always use 'www')
- replacement of spaces with hyphens in urls for page names, plus automatic 301 redirects of the Url with no spaces in it
- replacement of diacritic characters with ascii equivalents, plus automatic 301 redirects of the diacritic character version of the Url
- quick and easy installation and configuration
- ability to change or remove the .aspx extension
- forcing lower case for urls;
- and more : please read the product information page for the full list.
In fact, the new 'Permanent Redirect' option actually enhances the module, as it does for any DNN Installation, no matter what Friendly Url solution you're using.
New Versions to Download
The new version of the iFinity Url Master Module is available from the Url Master product page
In order to run with DNN 4.9.2, you will need at least version 1.13.08 of the Url Master module.
The new version of the iFinity Friendly Url Provider is available from the Friendly Url Provider product page