DotNetNuke is a great platform.  Over the years we have added a ton of features.  In many ways DotNetNuke is like a pile of Legos.  A lot of users get too focused on looking at one single feature and trying to force that feature to do everything they want.  The key to getting the most out of DotNetNuke is understanding how to use the many different features together to create something that is greater than the sum of the parts.

I am pleased to announce that DotNetNuke 5.6.1 is officially released.  This release resolves a number of outstanding issues with the 5.6.0 version and adds a few new significant enhancements including:

• Razor Scripts – 5.6.1 includes the new RazorHost module which allows you to use Razor scripts in your DotNetNuke installation.  For an example of what can be accomplished, checkout the recent entries in the Razor Hackathon.
• Child Portal Aliases – In the past you were forced to designate a portal as either a child portal or parent portal at the time the portal was created.  In 5.6.1, you will be able to add Child Portal Aliases at any time, to any existing portal.
• Improved Portal Alias Handling – In the past, it was possible to create multiple Portal Aliases for your site.  This has always caused potential SEO issues.  In 5.6.1 we have taken portal aliases one step further.  You will now be able to designate a single portal alias as the default alias.  The administrator can specify special handling for the portal aliases including the ability to use the default portal alias as the base domain for the “canonical url”.  Alternatively, the administrator can choose to use a 301 redirect so that all portal aliases will be redirected to the default portal alias.

During the 5.6.1 development cycle our security team received a few reports of security issues that affected previous versions of the platform.  Based on these reports we did further testing on the platform and identified additional areas that we felt warranted additional hardening as a preventative measure.  Because of the number and seriousness of the issues identified, and the additional hardening work done to the platform, we recommend that everyone upgrade to the 5.6.1 version to ensure your sites remain secure.

In Occam’s Razor and DotNetNuke, I showed you how to create a Razor script that you can run using the DotNetNuke Razor Host module.  This is great for simple scripts.  One of the downsides of scripts is that Scripts don’t have packaging and installation support.  If you want to re-use the script, or allow others to re-use the script, then you will have to provide manual installation steps for the scripts.

For more complex solutions or those which I want to re-deploy on another site, I will want to package my script as a DotNetNuke module.  Future versions of the Razor Host module will automate this for me, but for now I’ll need to do this by hand.  It’s not really all that difficult, and in this post I’ll show you how to accomplish this for your scripts.

In my first post, a user asked me how hard it would be to add a role selector, so in addition to packaging up my script as a module, I’ll also add this feature.  One of the main purposes of modules is to re-use functionality on multiple sites.  This often requires some configuration of the script to make it usable for many different sites which may be configured differently.  For example, in my original script, I was listing out the users in the “CoreTeam” role, however, other sites may want to list users in a different role.

Occam’s Razor is an often referenced heuristic that basically states that the simplest explanation is more likely to be the correct one.  This principle has many corollaries in computer science as we often strive to find the simplest solution to a problem in order to keep the complexity of our applications under control.  The new ASP.Net Razor view engine embraces this philosophy and certainly shows that even simple solutions can be very powerful.  Charles Nurse has a recent series of blog posts which discuss how you can even use Razor within DotNetNuke, with the focus being on lowering the barrier for creating DotNetNuke modules.

In keeping with this focus on simplicity, On December 6th, the Seattle DotNetNuke User Group (SEADUG) will be hosting the DotNetNuke Razor Hackathon.  Like previous Hackathons, we’ll be live streaming the kick-off event on DotNetNuke.com.