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.   

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

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