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.

DotNetNuke recently moved to an Open Repository that is hosted on CodePlex.  As Phil Beadle recently noted, the synchronization process is now fully operational and is running nightly to ensure that the CodePlex repository mirrors our internal version control system.  Of course, having access to the source code and understanding how to use the source code to get to a working build is two different things.  The source code package that we deliver with each release is slightly modified from our own internal repository in order to minimize confusion for the community.  Over the years the core team has become accustomed to these steps, but for new people, getting DotNetNuke up and running from source code can be a bit daunting.  Hopefully I can help dispel the mystery and make it a little easier to understand why DotNetNuke source code is packaged in this manner.

NOTE:  For the remainder of this post I will assume that you are familiar with DotNetNuke and that your system is already configured.  The source code version of is not intended for people who are just getting started with DotNetNuke.  If you fall into this category then I would recommend starting with one of the install packages to better acquaint yourself with DotNetNuke.  If you use the install version with the Web Platform Installer, then it will ensure you have all the necessary pre-requisites installed.  For more information on installing DotNetNuke you should review the Installation Instructions or watch the Installation Webinar which are available on the downloads page.

I don’t know if any else is like me, but occasionally I will run across something on a website and think that if only I could make some little tweaks to the site, that I might be able to make it more suited to how I think.  Maybe it is just a bit of CSS that might clean things up a bit, or maybe if I could just re-arrange things on the page I would have an easier time finding that awesome feature that always seems to get tucked away in a hidden corner of the page, never to be seen again.

I was on the DotNetNuke forums this morning and noticed that Chris Paterra had added a new “Quick Reply” feature.  This is a simple textarea and submit button that was added to the bottom of the forums page.  The nice thing about the quick reply is that I don’t always need fancy html or the ability to pin the post or any of the other features that are on the regular reply page.  Using the new Quick Reply, I can easily post a response without any visible postbacks.  This is a much nicer Web 2.0 experience and something that I am sure many users will love.

In late 2007, Nik Kalyani created what I think is one of the coolest new DotNetNuke features to arrive in quit a while – DotNetNuke Widgets.  Nik recently started work on a multi-part blog series on Widgets.  As he explains, DotNetNuke Widgets are a powerful client-side counterpart to the server based extension model exemplified by DotNetNuke Modules.  Where a module generally consists of code that is executed on the server, a widget primarily consists of JavaScript to be executed in the browser.  This is not to say that a module can’t include rich client functionality or that widgets can’t include server-side code:  indeed both options are certainly possible.   With widgets the focus is on building functionality that is easily added through custom object tags.  You can emit these tags from a Module, in a Skin or directly in an HTML module.  Anywhere you can add HTML to the page output, is a place you can add a widget.

With any new technology there is always the question of why someone would use it.  Why would someone not just add custom JavaScript or use an existing widget framework (there certainly are a lot to choose from)?  I have used a number of widgets and scripts on my pages and in general I don’t find that they are particularly geared for use by many of the non-technical users who ultimately edit and maintain DotNetNuke websites.  Most widgets and scripts require a certain level of technical knowledge by the end user, and in many cases, they impose some dependency on a third party website.  DotNetNuke Widgets attempt to resolve these issues and many others.  Since widgets are first class citizens in the DotNetNuke extensibility model, they can be packaged, versioned and installed just like any other DotNetNuke extension.  This eliminates any dependency on a third party website since many widgets are fully self-contained.  Also, because the widget is created on the page with a simple Object tag, they are much easier for a non-programmer to understand and add to the page (there is still some room for improvement which I hope to address in 2010).

There are many times when doing DotNetNuke development that your module needs to send emails.  You often have emails that need to go out to several different addresses i.e. an email to the user, one to the system administrator and maybe one to a fulfillment partner.  You frequently have different emails that get sent based on specific configuration settings or that change based on the role of the user.

When developing for DotNetNuke I often create a custom installation devoted to the module under development.  In the past I have not always had an easy method for configuring the SMTP server so that I could trap all the emails being sent out from the system.  I would try to set all the emails to one of my many email addresses and set my SMTP settings to use one of my production email servers.  The problem with my previous approach is that I often missed emails.  Unless all the emails are directed to my personal email accounts, I had no way to trap the emails on my dev box to make sure they were correct.  My previous method also did not make it easy to follow the entire email workflow.

Over the past 6 years I have watched as DotNetNuke matured into a well-rounded platform that is capable of meeting the needs of a wide variety of individuals and organizations.  One of the keys to the platform’s success is that it continues to leverage technology to make it easy to build sites the way you want. 

A user recently asked me how they could re-use the content from one page on another page in their site.  A couple of years ago I would have suggested that they make a “copy” of the module using the built-in capabilities.  This works well when you are trying to duplicate the entire content of the module, however, there are times when you just want a portion of the content.  In the past the answer would have been to split up the content on the original page – which might require changing your skin and may not be possible when using 3rd party modules.

The optimal solution would not require me to make any changes to the original page, but would instead allow me just to grab specific content and display it on a new page.  Thanks goodness we added jQuery support in 4.9 and 5.0.  This problem is really easy to solve with some simple html and a jQuery one-liner.

DotNetNuke has a lot of great features that come built-in, but there are often situations where the default implementation is not what the customer wants for their website.  This was a big limitation of early versions of DotNetNuke – changing basic functionality often required the user to customize the core DotNetNuke code. 

In DotNetNuke 2.0 all of that began to change with the introduction of Providers in the framework.  This is also where we began focusing on a rich extensibility model that would allow users to install skins, skin objects, and modules as separate packaged extensions.  Over time, the framework has evolved to include different extension types, and in DotNetNuke 5.0 we moved to a unified extension model that treats all extension types in a similar manner during the install and uninstall process.

One of the extension types that was added in the last couple of years was the Authentication Provider.  Unlike most other providers, an authentication provider is not configured in the web.config and actually looks and behaves more like a module than an actual provider. 

During the last several months I have been doing more and more jQuery development and have found a few key tricks that have improved my code and made my development experience much more enjoyable.

1.  Inject the jQuery library reference in the head section.

jQuery does not know about the DNNMenu and the ClientAPI.  It will step all over them if given half a chance.  Of course, DNNMenu and the ClientAPI are aware of possible conflicts with popular JavaScript libraries and will take steps to avoid any conflicts IF the jQuery library is already loaded.  The ClientAPI is loaded at the top of the ASP.Net page form so loading jQuery in the header ensures it is loaded before the ClientAPI. 

If you are building a module that injects a jQuery library reference, add it in the page header and you will be safe.  If you just want to include a jQuery script on a page then you can edit the Page Settings/Advanced Settings to add the script reference to the Page Header Tags.

For the last year and half I have increasingly turned to one module as my goto solution when building out new capabilities.  For me the Reports Module is proving itself to be the Swiss Army knife of the DotNetNuke module world.  With some of the features coming up in future releases of the Reports module this will become even more evident to anyone who takes the time to learn how to use the module.

So why do I feel so strongly about the reports module? It is mainly because of the architecture that Andrew Nurse put in place to allow you to create custom data sources and custom visualizers.  This architecture makes it easy to get data from almost anywhere and then to have complete control over how it is displayed. 

For most people the built in DotNetNuke Data Source, and XSLT Visualizer can handle most of your needs.  You can query any data in DotNetNuke and then use XSLT to display that data.  If you have not used XSLT before, you are missing out on a very powerful tool.  Whether it is displaying a blogroll, the MarketPlace Monitor or even building an entire eCommerce site, XSLT gives you a lot of capability to take XML data and transform it into as simple or complex a page as you can imagine.

[more]

Right now there are three core modules with extensive XSLT capability built in: Forms and Lists, XML, and Reports.  Forms and Lists is a great module, but it forces you to store data in the tables it defines.  XML also has great XSLT functionality, but it only handles XML that is stored in a file or that is retrieved from a URL.  If I want to report on Data, no matter where it is stored, my only option is the Reports module.  The Reports module includes a custom data source that allows you to read UDT data, and it wouldn’t be hard to write a custom data source to read an XML file.

Even though I love the Reports module, the Forms and Lists, and the XML modules both have some features that are not currently supported by the XSLT engine in the Reports module.  They all have their place in your DotNetNuke arsenal.

So if your need is just to display some data on the page, and you want something more than a simple table, then the Reports module is the tool for you.  In the rest of this post I’ll walk through a recent requirement I had for our company intranet.

One common requirement in many intranets is that it should be easy for employees to find out basic contact and organizational information on other employees.  DotNetNuke includes much of this information in the default user profile.  For my purposes I wanted to display the following pieces of employee information:

Name Photo Job Title Department Manager Phone Numbers (Work, Cell, Fax) IM Email Location (Region, Country and Time Zone) With my data elements identified, I can use the built in User Accounts screen to access the Manage Profile Properties page.  From here I can add any profile elements I want to capture.  The default set of profile elements cover most of my requirements, and it is easy enough to add any fields which are missing. Now employees can edit their own profiles and we’ll use the reports module to display those profiles. 



To configure the reports module, you will need to be logged in with a Host account.  The reason for this requirement is that the SQL query we are building could potentially access any data in the database.  In a multi-portal environment you wouldn’t want one admin access data for another portal to which they didn’t have access.  Since hosts have unlimited access to all data in the system, they are needed for defining the data source. Once the data source is defined then any user with edit permissions will be able to configure the visualizer.

Go to the module settings page and navigate down to the Data Source Settings section.  For our example, I can use the DotNetNuke Data Source which uses the default dataprovider defined in the web.config.  Then I enter my query.  Finally, I will use the Show Xml Source link to display the resulting XML from my data source query.  I will save this xml to a separate file so that I can test my XSLT during development.



Notice in my query that I just select all of the data from a custom view.  You will not have this view on your DotNetNuke installation.  One limitation I found very early with the Reports module is that it stores all of its configuration data in the ModuleSettings and TabModuleSettings tables.  This limits the amount of text I can use for the query.  I know from experience that querying profile data can get very complex and will easily exceed the size limitation of the settings tables.  As a result I almost always create a custom view or stored procedure for my query.  Because each piece of profile data is stored in a separate row of the UserProfile table, we have to do a join between the User table and UserProfile table for each property we want to include.  As you can see from the query below this quickly becomes quite long, although most of the logic is just repeated over and over.

SELECT ...

DotNetNuke 4.9.1 and DotNetNuke 5.0 included a new feature called the DotNetNuke Dashboard which is available from the Host menu.  The Dashboard provides access to numerous stats and settings from a single location which simplifies finding the information which is often needed when troubleshooting problems.

In addition to displaying critical data, the Dashboard allows the host user to export the data so that it can be easily provided to tech support if desired.  Having offered SLA support for the past year, DotNetNuke Corp staff often had to do much of this data collection using manual processes.  In speaking with many module vendors, we found that they were experiencing the same support issues.  The dashboard should greatly simplify this process.

DotNetNuke 3.0 added a lot of new capabilities.  One of the little documented features was the ability to control how DotNetNuke is installed.  Over the last 4 years the installation capabilities have been expanded.  One of the features which was added was the ability to control the Host Settings during the installation process.

During the OpenForce Conference, I heard from several designers that the DNNMenu had problems with Search Engine Optimization (SEO) because it rendered menu items that used JavaScript for navigation.  While I assured them that this was not the case and that the menu rendered a down-level version for search bots, I thought I would perform further testing and document the exact behavior.  In the process, I found that while the DNNMenu performed as expected, ASP.Net did not.

To observe the behavior of the menu, I used Firefox 3 with the User Agent Switcher plug-in.  This plug-in allows you to simulate any user agent string you wish.  For testing purposes you can find a complete list of user agent strings at useragentstring.com.

DotNetNuke has long supported building modules as separate projects in Visual Studio.  With the release of Visual Studio 2005, Microsoft added a new compilation mode for web projects called Web Site Projects.  This required module developers to figure out how to work in the new paradigm since our previous module development methodologies would no longer work.  Anyone who was around for that transition knows how painful it was to relearn how to create modules.  The old methods no longer worked and the WSP model did not provide many of the same benefits as the compilation model in VS 2003.  Microsoft listened to the complaints of the DotNetNuke community and many other web developers who still wanted the old compilation model.  Their solution: Web Application Projects (WAP). 

WAP brought back the more traditional development style that DNN developers were used to.  Unfortunately there were some new kinks as well.  I have long advocated keeping my module projects separate from the DotNetNuke installation.  I create and destroy DNN installs quite a bit and don’t want to inadvertently delete some of my code during my frequent site purges.  Keeping my modules in a separate project directory allows me to delete websites without harming my modules.

While catching up on blogs this morning I ran across a little PowerShell gem on Walking Dependencies in Powershell.  Chris outlines a problem that has popped up a few times in DotNetNuke.  Usually it revolves around CountryListBox or DotNetNuke.WebUtility.  Finding the offending assembly is always trial and error.  Chris’s solution should help resolve that issue.  I found a few minor bugs in Chris’s script which I have fixed.  The reflection call is a static method and is missing a “]::” and the Convert-Path is unneeded if you call ReflectionOnlyLoadFrom with $_.FullName (this will become important in a minute).  [more]

...

Over the last several years web developers have moved more and more code to the browser in an effort to improve the overall user experience.  This code is usually in the form of JavaScript libraries which provide advanced functionality and improved performance.  With the widespread adoption of AJAX developers are pushing our JavaScript skills to the limits.  Even with this increased reliance on JavaScript running in the browser, there is still a need for server side application code.  While the split in application logic has brought some improvements in our user experience, it has brought its own set of challenges as well.  Having application code in two locations often requires us to pass values from the server side to our client-side JavaScript...

Anyone who has spent much time working with Cascading Style Sheets (CSS) has discovered that each browser has slightly different support for the various CSS versions.  To further complicate CSS usage, each browser has a different set of bugs and/or understanding of what a particular standard requires.  Internet Explorer is definitely the worst offender and the furthest from fully and faithfully supporting CSS 2.1.  While support has been steadily improving between versions, it is still not on par with other modern browsers.

Typically, designers use a number of different hacks to target CSS at specific browsers in order to work around the inconsistencies.  The process generally starts with a skin...

Over the last 5 years I have literally installed DotNetNuke hundreds of times on my local development machines.  During this time installation has gotten easier, but it still takes a few minutes and is still subject to mistakes being made.  Also, because there are several steps involved, I often take shortcuts.  This is ok when I am just throwing up development instances, but it is counterproductive when I am trying to do actual testing of a beta or release candidate.

Last fall I started building a series of PowerShell scripts for simplifying the process.  Although there are installers available for DotNetNuke, they...

Over and over I see DotNetNuke modules whose settings pages are created using the utilitarian look of the default DotNetNuke settings.  I personally don’t care for this appearance since the layout relies very heavily on the use of tables.  I really wanted to style my settings page along the lines discussed in the recent Sitepoint article on Fancy Form Design Using CSS.  Unfortunately, if you setup your module to use the standard settings page, then you do not have control over the stylesheets.  Unlike the standard page, your module.css is not injected...