I’m sorry but I couldn’t let myself write a post about portals without making a Portal reference. In the title.
One of the things that always got me when working with DotNetNuke was how portal aliases needed to be defined explicitly (well, now I’m used to it since I have to install DotNetNuke about 20 times a day). And if you forgot to set one up it would very quietly redirect you to your localhost or whatever URL you used during install.
Consider the following scenario:
You are a cupcake entrepreneur who has made a living making cupcakes and can see the great potential in cupcakes and their deliciousness. You realize that you need an online presence. You look around and come across a great looking product called DotNetNuke. You realize that it is what you have been looking for all along so you go ahead and download a free copy, install it on your machine and start setting up your website.
After its all setup you realize that it might not be a great idea to serve your site right out of your laptop. $20 a month later and you have yourself a brand spanking new host and a really cool 5 word domain name (since all the short ones are taken). Next step is moving your already setup site to the cloud. You backup your database, your site folder, move everything over. Everything goes as planned.
Now, the moment of truth. You try to access the site using your new domain name. DotNetNuke can’t recognize your domain name as an alias so it will try to redirect you to the first alias of your default portal which most likely is http://localhost/CupCakes which could bring up the local instance of your site. This will end in one of the following cases,
- 1. You will be redirected to the localhost instance of your site and if you don’t pay attention the sudden change in the address bar (You typed in http://www.cupcake.com but are now back to http://localhost/CupCakes) could lead you to believe that you are working on the remote site but are actually working on your local site. Very confusing.
- 2. The localhost site doesn’t exist for any number of reasons; it could be because you are accessing it from a different machine than the one that has your local setup, or even worse, the site exists but its broken, since your stopped your SQL instance or changed web.config. Now you are in full panic mode since your think that your newly created public site is showing a SQL timeout to all cupcake enthusiasts. Very scary.
If you pay attention you will realize that both of these scenarios have something in common, they are either very confusing or very scary.
Well, I’m here to tell you that DotNetNuke 5.6.0 is here to save your cupcake business. Starting with DotNetNuke 5.6.0 anytime a single tenant DotNetNuke site (site with a single portal) is accessed we will check whether or not the alias used is a known alias; If it is not we will silently register the alias. Your site will be presented to you no matter how you access it, if IIS can map it so will DotNetNuke.
You might be asking why even bother registering the alias. Well, that is a great question. Let say you access your site using localhost, 127.0.0.1 and also www.mydomain.com. They all resolve fine since you only have a single portal. Few months later you realize that you need a second portal. You add the portal and the previous rule no longer applies since you are a multi-tenant site now. If we hadn’t registered those alias automatically your site would be rendered inaccessible.
Lookout for the 5.6.0 beta so you can try this feature.