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.

In my position as the release manager for DotNetNuke, I end up installing DotNetNuke numerous times every week.  While I have a set of PowerShell scripts which makes this process relatively painless there were still some areas that I felt needed improvement.  In the past I have created all of my sites as applications in a virtual directory under the default site in IIS 7.5 (Windows 7).  This usually results in some URL for my site that looks like this: http://localhost/myDNNsite.

Have you ever been given a technical challenge that just seemed to interesting to pass up? This past weekend I was asked the question about extending the blog module to add an author biography to the footer of the blog post.  The gist of the question was how could we do this without causing problems on upgrade.  Since I always like a good challenge, I thought this would be a good opportunity to also show how a little creativity will allow you to solve many of the challenges that you face in DotNetNuke.

I have felt for a while that the DotNetNuke blog module was quite capable, but needed a few helper modules to give it a boost.  This is a perfect showcase on how to extend a module without actually changing the module or any of it’s data.  I also thought this would be a good opportunity to learn a few new techniques so I included the use of the new jQuery Templates which were added in jQuery 1.4.3, but which are also available as a separate download.

Over the last couple of years, I have been doing more and more work with JavaScript.  Whether it is work on web pages with jQuery or work in mobile applications with Appcelerator Titanium, I often find myself needing to transfer data to and from the server as JSON.  In DotNetNuke I frequently found myself constantly converting my .Net objects to and from JSON and it seemed to be a waste of time to constantly figure out what framework I should use to handle the JSON serialization/deserialization tasks. 

I have tried the JavaScriptSerializer,  the DataContractJsonSerializer  and even JSON.Net but I always keep coming back to the JavaScriptSerializer because it is the simplest solution that doesn’t impose any 3rd party dependencies.  The problem with all of these solutions is that I am constantly having to remember how to use them.  The API, even for the JavaScriptSerializer, still requires several lines of code whenever I want to use it.  I wanted something that was drop-dead simple, yet still powerful enough to handle 95% of my serialization/deserialization needs (for the really tough stuff I can still use one off code with an appropriate serializer)

One of the issues that every DotNetNuke skin designer faces is how to design skins for multiple browsers.  Often, getting a skin to work in Firefox, Chrome, Safari and Opera is pretty straightforward and doesn’t require much tweaking.  Unfortunately, the same cannot be said of Internet Explorer.  Making your skin work with IE6, 7 and 8 along with all the other browsers can be a bit of a nightmare.

I previously addressed this issue in DotNetNuke Tips and Tricks #3: Conditional StyleSheets.  In that post, I created a skin object that allows you to conditionally add a stylesheet to the skin based on a condition defined by the designer.  This skin object was subsequently added to the core framework and is currently being used by many designers.  In fact, Artisteer uses it in all the DotNetNuke skins that their software generates.

Recently, I found a method that I like better than using conditional stylesheets.  One of the downsides to conditional stylesheets is that you end up causing stylesheet bloat.  Conditional stylesheets add round trips to the server which we should be trying to minimize.  Conditional stylesheets also require you to maintain multiple stylesheets which can be a little painful.  If you make a change in your main stylesheet, you will need to find the corresponding section in your IE specific stylesheets and potentially make changes to them as well.  From a maintenance and development perspective, this is far from optimal.

Very early in the life of DotNetNuke, modules were fairly limited in their functionality.  Modules could have multiple behaviors attached to them by the framework which were displayed as a list of link buttons.  Very quickly this UI became very cumbersome as we continued to add more and more behaviors to the standard list of behaviors. This UI greatly limited the amount of actions that could be attached to a module and at the time the list of behaviors was fairly static. 

One of the first enhancements that I worked on for my own modules was the ability to create a menu that was attached to the module.   This menu was intended to be customizable by the module developer and the framework and would remove the space limitations that plagued the early framework.  When I showed Shaun the menus he instantly saw the potential and we incorporated them into the framework.

The module action menus were originally designed to be extremely flexible.  I wanted to be able to create links that could perform client-side actions as well as trigger events on the server side, depending on the needs of the module developer.  Many module developers have taken advantage of the server side functionality over the years, but I have not seen many modules which have taken advantage of the client-side functionality.  When I first created the menus, I documented the API using XML Comments, which were not being used anywhere else in the framework.  Until recently the project was not even publishing the API documentation, so these comments went largely unnoticed by the developer community.  I am happy to say that with 5.5 that has changed and the API documentation for the core framework is now available with the rest of the Community Edition download packages.

As long-time DotNetNuke users well know, DotNetNuke contains an extensive API that makes the platform extremely powerful and flexible.  Over time the core APIs have continued to expand as new features were added and existing features were enhanced.  One of the core APIs which has been part of DotNetNuke since 4.6 was released three years ago today is the XML Merge API.

The XML Merge API was developed to enable developers to define changes that need to occur to any xml based file within the website.  It is primarily used by the core framework to make updates to web.config but has utility beyond just updating web.config.  Web.config management was a huge problem in early versions of DotNetNuke.  Managing and applying the web.config changes every time you upgraded DotNetNuke was a time-consuming and error-prone process.  The XML Merge API was developed in part to address this need.

When I first created the API, I needed a way to merge dozens of custom URL rewriter rules into the siteurls.config for the AspDotNetStorefront module.  These rules could change with new versions of the ASPDNSF module and so I also needed to support the ability to apply these changes in a version specific manner.  My first version was included as part of the ASPDNSF module, but due to a contractual arrangement, I was able to make this API available in DotNetNuke as well.

This article is cross-posted from my company blog.

Do you use Windows Live Writer and the DotNetNuke Blog module?  I do, and I just discovered a great new WLW feature which is going to greatly simplify the steps I have to perform for every blog post.

I have been using Windows Live Writer (WLW) for a few years now.  I really love WLW for writing my blog.  In fact I loved it so much that it was one of the reasons I had shifted my personal blog to BlogEngine.net.  At the time, the DotNetNuke Blog module did not support a posting API which could be used with WLW.  You don’t know real pain until you have tried to write a blog post with nothing but a web based rich text editor.  Once you lose one or two posts because of a session timeout or your post gets mangled because of the way the editor handles script blocks or xml blocks, you will quickly swear off all blogging with an RTE.

Once I started using BlogEngine, I came to really appreciate some of its features.  It really tries to leverage the capabilities of WLW to make the blogging experience as pain free as possible.  One feature that I use quite a bit is the ability to split my blog into a summary along with the full post just by including the “[more]” tag in my post.  Everything before the tag will be used when displaying the blog summaries.  The entire content will be displayed when viewing a specific blog post.  This is great, although it does limit your ability to craft a great summary that differs from the opening of your blog post.

Unfortunately, the DotNetNuke Blog module does not support the “more” tag.  If you don’t provide a summary when creating a post for the Blog module, then it will try to create a summary using the first 1000 or so characters.  This rarely works with my blog posts and even when it works it is generally not optimal.  Because I usually include an image at the top of my posts, the auto-summary feature usually just chokes and I am forced to hand enter a summary for my blog on DotNetNuke.com.  This is definitely a problem.  My blog posts often include coding examples.  When I edit a blog post just so I can hand craft the summary, it also has the side effect of opening the main blog content in the RTE which then reformats my code blocks when I go to save the summary.  Hello mangled code samples.