Will Strohl has an opinion about everything. I used to read his blog regularly. Then he came to California. And started acting weird. Like playing foosball and stuff and not meeting up and spoiling the parties and all! What? No meet-up yet? Hey, so I’ll write exact opposite of what he writes, with my own opinionated opinion. Like it or not, here are top ten reasons not to ever use the portals to install an additional website on a DNN installation.
1. Different sites need different skins.
Yes I know what those guys at DNNCorp are gonna say about this. Hey, they may be right but I have my own reasons. There’s the admin way of trying to skin the life out of a portal and there’s the host way of skinning the already dead skin. To put a long story short, most skins should be installed from the admin->Extensions menu but while logged in as host (eh, why the admin part then?) Make a mistake and that mistake is permanent. After that, even if you upgrade/install as an admin, watch all your hard work melt away in a second! Besides, a single skin cannot be customized independently for different portals anyway. And, who would’ve thought skins should be installed and available (non-premium) on all the portals. After all, I can’t find a skin on SC that is allowed on multiple portals and is still affordable and flexible enough.
2. Your bin directory is going to bloat up.
Unless of course you’re running a DNN portal just for a few months/days, count on your bin directory bloating up. Why is this important? When your application restarts, the time taken by IIS to recompile all the stuff is directly proportional to the bloat stuff you have in your bin directory. Yeah, even stuff that shouldn’t be there or is there irrespective of the extension matters. Different sites, in all probability will use different modules but all of them are going to reside in one bin directory. If no one visits your site it doesn’t matter but if you have anything close to a visitor a second or higher hitting up while your application pool is waiting to startup, you better hope your bin directory is trimmed to the hilt or you’d get a 500 before a 200.
3. Your bin directory is common.
Hey, we all know shit happens. But one badly packed module can wreak havoc on your entire site just because your bin directory is common.
Example number 1:
I can’t count the number of modules I have purchased on SC that have their own self-compiled version of Cookcomputing.XmlRpcV2.dll as part of their module. Guess what installing that module does? It will crash the whole site, coz everyone is looking for the signed, version 22.214.171.124 DLL and this one irritable module insists on installing 0.0.0. Sure, your intention was just to add one module and the success or failure of that one module should have been limited to just the one module only. Unfortunately not. One module screws up, your whole installation is done and out.
Example number 2:
Dependencies of different modules are different. Its just bad enough that modules can’t agree on a common AjaxControlToolkit coz there isn’t a good, stable enough, bug-free version. Then there are these different modules who insist on forcing different versions of AjaxControlToolkit. Heh, so much for backward compatibility, consider yourself lucky if you didn’t find anything broken so far.
4. Make an upgrade, lose a change
Its not like DNN works with a master repository of controls from where to pick up new stuff from. There is only one repository for all things admin and and it is shared across all portals. If you made a change, its going to be wiped out when you upgrade. The hard part? If you have too many portals, its difficult to find a problem with that one portal which makes use of that change. I’m not talking about web.config Heck, if I as an admin like the FCKEditor, everybody else should too. If not, your account is disabled. But, unless there is an isolated way of say customizing the login control or any of those admin things for each of the portal separately, its just going to be too much work one frickin’ day!
5. DNN and most DNN Modules are Portal Blind.
Even if they carry the portalid in their table everywhere. Stuff that is meant for one portal is accessible from another (Even I do this, coz everybody else does it, f*ck why should I try to be the only saint in town?). Both in core DNN modules as well as in third party modules. Even if it is not embarrassing enough to see content of say portal A in portal B by just switching a few values in the URL and the domain name, there’s something far more sinister! Your directories underneath are also accessible by just changing the /portalid/ while keeping the domain name same. Yeah, I’ve heard one DNN guy tell me in capital letters “No injection attacks are possible in his module ever” – I almost did write this line “You have no idea how XSS works do you?” Of course, I realized the futility of my effort and I never said a thing. But for those of you who care about security and vulnerability or host sensitive stuff on your site, you need a single DNN installation for such stuff.
6. Username & Email addresses are common across all portals.
It doesn’t matter which portal, if an email address is taken on one portal, it cannot be used in another one. Heck! I’d like me to be subodh everywhere, not subodh1,subodh2!! Does it really matter? Aside from being a small inconvenience, that is. Yes it does. People hate remembering passwords. It doesn’t matter if you have just a few users. It really does become an administration nightmare when you’re trying to juggle even 100 users.
7. You can’t migrate a portal to a full DNN installation
Not easily that is. You can of course do the painful part but there is nothing in the DNN infrastructure itself that can help you in transforming from being under say, portal 8 to portal 0. Neither will the third-party modules. Neither will the skins or containers or the directories or the settings. You’re stuck with that portal structure for the life of the portal. The only option is to redo from scratch. Why would you need to ? Some portals really do become popular you know. Others die off and you may want to consolidate!
8. You’re severely limited by the common install.
Think about it. You cannot have a separate robots.txt If google asks you for the verification file, you cannot but help put all of them in the single directory. You cannot have a static file that is not shared across all sites. You cannot have exclusions! You cannot experiment on one site coz the debug flag on web.config is common. You cannot have separate apppools and if you do attach a debugger to w3wp, you’re going to get hit for every single request! Meh! so much for a quickie peace of mind.
9. Languages aren’t really a big deal … yet
Yes, I know DNN has done a lot of work done in this area but I have to say, a lot more still needs to be done. I guess there are work-around-s but I have my peeves about not enough independence between portals to choose their own language behavior/settings/resources without having anything to do with the main portal. I guess some folks don’t realize all characters cannot fit into the same space. Nor are the same characters always used even in the same dialect. Any Indian language?
10. ASPNET Login
yes, I’ll revisit the same issue again. With a twist. So you already know, other than the host account, you cannot have users span across multiple portals. You also cannot have the same user sign in to subdomain.portalA.com and www.portalA.com Combine that problem with multiple portals and you mix up two huge problems into one. You can have people change their passwords on one subdomain and complain to you that they never changed it one the other domain. Yeah, you know there is only one password irrespective of the domain. But take off the portal part and think of the above problem with a different domain!
I my opinion, it take very little time to create a fresh new DNN installation and its just not worth my time to struggle with nuances of shared stuff. But then again, this is my opinion and I’m known for fun-stuff like that! I could probably go on and on. But then I must let Will Strohl write up his next story ;-)
This post is supposed to be funny. Ok, granted I lack the funny bone in me but the intent is not to criticize anyone, just to poke fun. Just because I may have talked about something lacking in DNN doesn't mean its competitors do any better. DNN is still my choice of CMS and will probably remain so for a foreseeable future. This article may contain content inappropriate for your age, culture or country. Children under age 18 or those suffering from delusional mindset are barred from reading this post. By reading this blog post, you certify that you are above 18, are not offended by off the hand remarks and know how to take criticism in a constructive and literary way. This article is in no way meant to endorse or otherwise to criticize any service, company or corporation. Names appear just to cite examples and to make a provocative, hopefully hilarious read, not to represent any facts. The information contained in this article may be entirely animated and any references to actual facts, actions, names or figures is purely coincidental and unintentional. And don't be copying anything from here unless you cite proper reference and link back.