Version 4.1.2 of Efficion's Articles module is now available. This release includes a variety of fixes, improvements, and new features.

View the complete list of changes   

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 answer is a bit complicated. I believe there is a MySQL provider out there for it. But, it is a terrible idea to try to run DNN on MySQL. STOP TRYING!

DNN does provide an abstraction layer so that it can be run against multiple databases. And, I believe there is a MySQL provider provided by someone at cost. But, even if you can get the core running against MySQL, it's still a bad idea...

Reason #1: Loss of modules - You would lose the key thing that makes DNN special, Modules. I'm sure some of the core modules are included in the MySQL provider, but, the core modules are just the beginning of DotNetNuke. Y ou 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.

Reason #2: Performance -The SQL used for DotNetNuke is chock full of Stored Procedures. The Stored Procedures improve the performance and security of the system.

To be continued....   

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.