DotNetNuke and MySQL

A question that I see a lot of is, "Can DotNetNuke run on top of MySQL?" The short answer: while It is possible, it is a terrible idea. The same answer is also true for Oracle. But that doesn't mean you can't write DotNetNuke modules that consume data from MySQL, Oracle, or any external data source.

The Long Answer

While DNN does provide a data abstraction layer so that it can, in theory, be run on top of any modern DBMS, the reality is DNN is a very large and complicated system that relies heavily on SQL Server specific Stored Procedures. The SQL used for DotNetNuke is chock full of Stored Procedures. The Stored Procedures improve the performance and security of the system.

A few intrepid souls have attempted to create and maintain MySQL providers but, with the availability of cheap hosting and free versions of SQL Server, there simply isn't enough need for that in order to make it worthwhile and those providers are long out of date.

Even if someone does manage get the latest version of DNN's core running against MySQL, it's still a bad idea because you would lose the key thing that makes DNN special, Modules. You would need to ensure that every module you ever want to use has a MySQL provider and that that provider would continue to be updated throughout the life of the module. Or, you would have to create a MySQL provider for every module that you want to use. The cost of doing this would far exceed the cost of using a hosting company that would provide you a shared SQL Server on which you can run DNN.

DotNetNuke: Which modules are being used (and which aren't)

Sometimes, you need (or want) to know which of the modules that are installed on your DNN site are being used, which aren't, and where a module is being used. This can be useful if you want to uninstall unused modules for performance improvements or if you're planning on upgrading your site and you need to know what modules you'll need to test or upgrade. Here's some sql that will help you answer these questions...

DotNetNuke Corporation raises funding through venture capital

The for profit wing of DotNetNuke, the DotNetNuke Corporation, announced an infusion of funding today from a couple venture captical firms. As someone who's livelihood is intricately tied to DNN, I've got mixed feelings about this news. While I fully appreciate that the new funding should help take DotNetNuke to the next level, both from a features and functionality as well as a marketing and penetration perspective, it also worries me that priorities may shift, revenue may trump the "common good", and everything may get more profit minded and expensive. So, we'll just have to wait and see...

DotNetNuke: Enable Human Friendly Urls

 DotNetNuke 4.8 added Human Friendly urls, but unlike Friendly URLs, it can only be enabled through the web.config. To enable human friendly urls, replace:

<add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" />

with:

<add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="HumanFriendly" />

UPDATE: In DNN 7.x, DNN incorporated the URL Master functionality for much improved URLs. To enable this, you should now use "advanced" rather than human friendly.
<add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="advanced" />

NOTE: Keep in mind though that no 301 Redirects for existing URLs are created so if you implement this for a site that has been around for awhile, you should make sure to manually create 301 Redirects or set up Canonical URLs for all existing pages to make sure to not dillute your link juice.

CSS columns break down when things get complex

I'm so tired of people discounting HTML Tables. I'm a huge fan of CSS, I'm fully aware that it is possible to do columns using CSS, but in order to do so, you have to use a variety of hacks, and those hacks change based on a variety of circumstances.

With DNN, because we have skinning, we already have the needed separation between content and presentation. Tables are the best way to handle columns. They are rendered consistently across browsers, are clean, and easy to read and use, and provide capabilities that are very hard to get without Javascript hacks in CSS.

I've spent countless hours trying to work around problems with my CSS based columns due to one need or another. I've researched many approaches to the best way of handling them. None of the solutions I've seen have proven to be nearly as clean and easy as just using tables.

If you continue to feel compelled to build tableless designs, go for it, perhaps you'll have better luck than I, but when you have a complex need and you can't find a solution that works consistently in all browsers, I give you permission to just go ahead and use a Table.