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.

More...

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.

More...

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).

More...

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.

More...

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.

More...

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. 

More...

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.

More...

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...

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.

More...

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.

More...