One of the under-utilized features in the DotNetNuke module development API is the ability to utilize DotNetNuke's built in Permissions architecture within your own custom modules.

Rather than having to write your own code to display a grid of available roles and special permissions, it's fairly easy to add your permissions to the existing permissions grid that usually just displays "View" and "Edit".

I found a nice article that gives a very good overview on how to do this
Extending DotNetNuke Module Permissions for Custom Modules   

As I build out the settings for DotNetNuke modules, I only like to display settings that are relevant to the other selections the user has made. The best way to do this is with Javascript so users don't have to wait for a postback everytime they change a relevant control.

In trying to put these things in place, I often find the code often doesn't work quite the way I expect (or at least used to expect) it to. The issue usually has to do with the way asp.net renders controls. I usually find I have to dig into the source view a bit to see exactly how asp.net rendered something and then fiddle a bit to get everything working right.

Here, I'll describe, one particular case where I had two checkboxes linked. The 2nd checkbox should only be displayed when the first checkbox is checked...   Read More...

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.

When I first started trying to install DNN on a local Vista installation I had various strange errors that I eventually determined to be due to the fact that I was running my IIS7 App Pool in Integrated Pipeline mode instead of Classic (IIS 6). And so, from that I learned DNN can't run in Integrated Pipeline more.

Today, I discovered that DotNetNuke can run in integrated pipeline mode as long as you're running DNN version 4.8 or greater. Charles Nurse discusses this in this blog.   

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...   Read More...

 There's an interesting article on a fairly simple way to improve the sitemap that DotNetNuke generates for you. It doesn't require any core modifications but does set page priority up in a way that makes a lot of sense while also not requiring much work.

DotNetNuke Sitemap Improvement by Equana Solutions   

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...   Read More...

eTailer from Emerald Solutions is a fairly new entry in the DNN e-commerce world. While there is a great deal of promise in the product, my brief attempt at using it seems to indicate it's not ready yet...

Purchasing, downloading, and installing it went smoothly. eTailer adds a reasonable 5 modules to your DNN install (much better than the 23+ modules Catalook adds). Initially getting things setup and going seemed quite intuitive.  I created a new page and added the "eTailer Store Front module". It had a nice obvious link that allowed me to Add/Modify Products. And so I was off and running, or so I thought...

UPDATE: The developer recently notified he was going to step away from DNN development for 6 months. To me, this means you need to stay clear of this product as there's no guaratee it will continue to be improved or supported.   Read More...

 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" />

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.   

We need to start upgrading our skins from the older RAD Menu to the newer RAD Ajax Menu. This article will go through the steps involved.

Telerik Migration Guide