Earlier this summer Will Strohl announced the DotNetNuke Super Fan Contest for 2012. I love our community and how passionate they are about DotNetNuke.  I was really excited last year to see some of the great Super Fan entries.  This year I wanted to participate even if I couldn’t “officially” enter.

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.

One of the worst experiences you can have with your website is to end up with a bad hosting provider where servers seem to drop offline for no apparent reason, or you have convoluted configuration options in the hosting control panel which complicates application installation, or you are left with poor technical support which takes forever to resolve your issues. These experiences don’t just happen with new or small hosters. Sometimes even great hosting companies can falter and provide substandard service. Hopefully they recover in time to satisfy the customer, but there are times where even the best follow up after a bad customer service experience is not enough and the customer feels like they need to find a new host.

KnockoutJS is taking the ASP.Net world by storm. DotNetNuke 6.2 will include several core features which rely heavily on KnockoutJS. In Part 1 and Part 2 of my Introduction to KnockoutJS series I discussed some of the basics of bindings which are at the heart of KnockoutJS. Later this week, I’ll continue my series on KnockoutJS. In the meantime I wanted to highlight a great learning opportunity for those who are interested in learning how to use KnockoutJS with DotNetNuke. Given its usage in DotNetNuke 6.2 it should come as no surprise that KnockoutJS will be prominently featured at the Charlotte Day of DotNetNuke on June 2nd.

Every week it seems more and more people are asking me how they can run DotNetNuke on Windows Azure. Last year David Rodriguez released the DotNetNuke Azure Accelerator which aims to simplify the process of installing DotNetNuke on Windows Azure. It was a great alternative to manually deploying DotNetNuke but it required the user to know how to use the Windows Azure Management Portal for setting up their Azure account. The original version of the accelerator also included the DotNetNuke installation package within the download. This meant that the accelerator was closely tied to the DotNetNuke version and had to be updated with every DotNetNuke release.

This year’s DotNetNuke World conference is just around the corner and we are once again looking for speakers. DotNetNuke World will be October 10th through the 12th in lovely Orlando, Florida. Registration will be opening soon, and like last year we will be offering great early bird pricing. This year’s event is shaping up to be twice as large as last year. More speakers, more sessions, and more attendees.

Much like past years, we are accepting session submissions that focus on Development, Design, Administration and Business. We have expanded the number of rooms this year so that we could accommodate more sessions with a broader appeal to business decision makers and end users. This year’s conference will focus on the “Social Revolution” but other topics are equally welcome.

The DotNetNuke community is composed of individuals and organizations that serve a wide range of needs for DotNetNuke users. Whether it is the skin designer, module developer or web hoster, every part of the DotNetNuke ecosystem helps make it easy for our users to take full advantage of the DotNetNuke platform to run their website. In this series of posts I’ll be focusing on the hosters in our community and looking at some capabilities that make each of them unique.

I recently came across a new hoster who has taken a unique approach to providing hosting services. Traditionally, if you were a web hosting company, you would purchase a bunch of servers and provision them in a data center. As virtualization technology matured, hosters began to shift their high end accounts from dedicated servers to virtual servers. With the advent of cloud services like Amazon EC2, some hosters are completely doing away with the capital costs of owning their own servers.

The DotNetNuke community is composed of individuals and organizations that serve a wide range of needs for DotNetNuke users. Whether it is the skin designer, module developer or web hoster, every part of the DotNetNuke ecosystem helps make it easy for our users to take full advantage of the DotNetNuke platform to run their website. In this series of posts I’ll be focusing on the hosters in our community and looking at some capabilities that make each of them unique.

PowerDNN has made quite a name for themselves in our community and like any good business they look for ways to solve customer problems. To simplify management of customer accounts, PowerDNN developed the PowerDNN Control Suite. In addition to using the tool internally, PowerDNN makes the Control Suite available to their Enterprise cloud customers.

If you have downloaded and installed DotNetNuke 6.1 you have probably noticed that the core modules are “missing” from the DotNetNuke packages. This is a large change from every previous version of DotNetNuke. Ever since Shaun first released DotNetNuke in 2002, we have included a number of modules in the core platform. How these modules have been packaged has changed over the years, but customers have become accustomed to seeing them.

In DotNetNuke 6.0 we provided a great new capability that integrates the DotNetNuke Forge and DotNetNuke Store (SnowCovered) into the core platform. This feature means that every module in the Forge can be quickly discovered and installed into the platform in just a couple of clicks. If you haven’t tried this feature, I definitely recommend you give it a try. It is definitely one of the great new features in the DotNetNuke 6 platform.

DotNetNuke has undergone many changes over the last 8 years in the way the product is developed and managed. Having been part of the main engineering and product teams from the early days of the Open Source project I have had a number of roles on the team. Last year I moved from being focused on application development as part of the Engineering team to being more focused on product management. A big part of my role on the product management team was handling release management.

I am pleased to announce that DotNetNuke 6.0.2 is officially released. This maintenance release further solidifies DotNetNuke 6.0 and resolves a few outstanding issues which were not addressed in the 6.0.1 release. Like with the 6.0.1 release, our goal was to continue providing quick resolution of outstanding issues to ensure that customers could upgrade to the 6.x platform with little difficulty.

I am pleased to announce that DotNetNuke 6.0.1 is officially released. This maintenance release was focused on resolving a number of issues that were found in the 6.0.0 release. Given the extensive set of changes in DotNetNuke 6.0 we recognized the need to quickly identify and resolve issues discovered by our customers as they tried the new release in production environments. This maintenance release further improves what many customers have already told us was a pretty stable release.

Late last year, I began work on getting DotNetNuke to run on Windows Azure. After a few months of research and numerous dead-ends, I finally had a fully working prototype. During this same period, David Rodríguez, was also doing some work with DotNetNuke and Azure as well.

After working through a few dead-ends of his own, David found the Azure Accelerator project from Slalom Consulting and decided to use this as a base for developing a DotNetNuke version.

I am pleased to announce the launch of DotNetNuke 6.  This release marks a significant milestone in the history of DotNetNuke platform.  Keep reading to find out all that DotNetNuke 6 has to offer both seasoned users and those just seeing the platform for the first time.

After 8 months of effort the finish line is in sight. With almost 3000 code checkins touching more than 2000 individual files, this release has been monumental in it’s scope compared to most DotNetNuke releases. Not since the days of DotNetNuke 2.0 and 3.0 have we accomplished so much in a single release. In spite of the sheer number of changes we have made, DotNetNuke 6 is one of the most stable platform versions in quite a while. That is not just my opinion but the opinion of the vast majority of people participating in our beta testing.

The clock is winding down on the DotNetNuke 6 release. All of the features have been integrated and we are now focused exclusively on polishing the app before we ship later this month. At this point we have identified all of the issues we plan to resolve for the initial launch and are working through final phases of the testing process. In order to assist people in planning for a smooth upgrade process for 6.0 we are providing a second beta release so that people can retest upgrades and installations which may have had serious issues with Beta 1. If you find an issue we ask that you enter it in the bug tracker so that we can evaluate whether it a showstopping issue or whether it is something that could be held for our first 6.x maintenance release which we expect to be about a month after the DotNetNuke 6.0 launch.

I am pleased to announce that DotNetNuke 5.6.3 is officially released. This release resolves a number of security issues with previous versions and resolves a few outstanding issues from 5.6.2 including:

• Updated Telerik Version – 5.6.3 includes the Q1 2011 SP2 version of Telerik ASP.Net AJAX controls. This version of Telerik includes support for the final version of IE9 along with dozens of bug fixes.
• Improved Security – This release includes 6 different security enhancements and fixes.

Over the last 6 weeks, the DotNetNuke team has been hard at work preparing for our first Beta release of DotNetNuke 6. The DotNetNuke 6 Beta does not include a lot of new functionality but does include significant refinements of the features we had previously highlighted during our CTPs. Even as we were putting the finishing touches on the beta release, the team has been actively out promoting the upcoming launch and demoing DotNetNuke 6 at every opportunity. We have used these opportunities to get feedback from the community and have incorporated some of the suggestions into this release.

For the past 4 years I had the task of working with the speaker selection committee to solicit speakers for the annual DotNetNuke conference. This is a challenging task as we must filter through almost two hundred submissions to find the handful of sessions that will be presented at the conference. With few exceptions the submissions are excellent and we would be lucky to have any of the speakers presenting at the conference. This year was no different. Not only did we get submissions from speakers who have spoken at past conferences, but we also received a number of entries from new speakers as well. In total, we had 177 sessions that we had to whittle down to 27.

DotNetNuke 6 has been a release experience unlike any in the history of DotNetNuke. We have had more packaged releases, more visibility into the code, more discussions with the community and a greater iterative approach to development than at any point in our past.

The community has been able to follow along with us as we progressed from the early UI concepts to a much more polished and refined look. If you were really adventurous, you could watch this transition on almost a daily basis as we kept up a steady stream of code updates on CodePlex. Because we intentionally moved to a longer release cycle, we have been able to go through many iterations, getting community feedback all along the way. With each release our community has told us what they liked, and what they didn’t. After each CTP we have been able to incorporate some of the feedback to help arrive at a much better product. As a result we have been able to progress to what we think is a much more contemporary look, even while taking into account the needs and desires of the overall community. This is just not something that was possible when we were operating under shorter release cycles.

Today marks a major milestone as I once again move my personal blog back to the DotNetNuke Blog.  Four years ago I switched to BlogEngine.Net. There were a number of reasons for doing that, but in the ensuing four years, my reasons for moving off of DotNetNuke as a blogging platform have been mostly resolved.  Where there are still deficiencies in the platform, I am able to contribute to filling those holes and in fact I have been actively working with the blog team for the last year doing just that.

So as of today, you will see me running DotNetNuke for all of my primary blogging needs.  I’ll still have some mini-blogs over on Posterous but those are mostly just a replacement for using Twitpic.

...

The History of Menus When DotNetNuke was first launched back in 2002, website navigation was just beginning to undergo a major shift.  At the time most sites still used a relatively static navigation structure with very little interactivity beyond a few simple hover animations and hyperlinks.  In fact, the original navigation structure for DotNetNuke was only a single level deep.  Over the course of the following 3 years...

Today marks another milestone in the upcoming Hadron release of DotNetNuke.   For the first time ever, DotNetNuke is offering a Community Technology Preview that will allow you to begin testing the latest version long before we have completed all the features.  As I discussed last week, the CTP is not intended to be production ready software but is an opportunity for the community to get a chance to start kicking the tires.  The CTP is an important milestone as it will allow us to gather feedback from the community much earlier in the release cycle and thereby allow us more time to incorporate that feedback into the final release.

"What's in a name? That which we call a rose by any other name would smell as sweet." Romeo and Juliet (II, ii, 1-2)

Sometimes a name is everything.  It can convey meaning and emotion.  In the world of software, a name can convey the stability or instability of a release.  The name, or label, that we apply to a release is our way of communicating to you some important information about our product.

Next week, for the first time since DotNetNuke was created, we will be releasing a Community Technology Preview (CTP).  This CTP will be for the upcoming DotNetNuke 6.0 release.  Later this spring we will release another CTP, a Beta or two and a Release Candidate (RC).

Each of these terms (CTP, Beta, RC) represents a specific milestone in our release process and it is important to understand the distinction to know what you can expect in each release.  Most developers in the Microsoft ecosystem will understand the terminology, but this post is intended to be a refresher so that as we discuss these releases in our community everyone will know what we are talking about.  Our definitions may be slightly different than the way it is used by other companies and that is ok, as long as we are consistent in our usage.

Over the past year the DotNetNuke team has been working hard to improve the pace of our releases and to provide the community with the opportunity to participate in beta testing in order to provide feedback prior to a release.  As of this morning DotNetNuke 5.6.2 beta packages are now available for download from our Beta Downloads page.  We have made a number of fixes to the platform and incorporated a couple dozen performance enhancements.  5.6.2 further stabilizes the 5.6 platform and should be a solid foundation for your DotNetNuke site.  Please keep in mind that this is just a beta and is not intended for production use.  Upgrades to the final 5.6.2 release are not supported.  We still have a few additional issues that we expect to be resolved prior to our Mid-March release but welcome any feedback.

Blog 4.1.0

This past weekend a new DotNetNuke Blog release candidate was posted on CodePlex.  This version of the blog addressed several longstanding issues with the Blog module and should be the final Release Candidate prior to the official release.  In 4.1.0 we really focused on fixing some of the biggest problems with 4.0 and doing some security hardening based on feedback from our security team.  In addition we added support for custom JS and CSS and temporarily removed support for Twitter (we’ll be bringing back an improved Twitter option in the next release).

One of the features that I was really excited about including in this release was the ability to support code formatting in the blog module.  There are many different methods that I have used over the last several years to format code in my blog posts.  The common denominator in every case is that it generally required me to add some custom JavaScript and CSS in the blog post so that it could be displayed properly.  In addition to code formatting, we also wanted to support the ability of administrators to include their own CSS to override defaults.

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.

The beta release of DotNetNuke 5.6.1 is now available for download on CodePlex.  In the past we have not made public beta’s available for the maintenance releases because there wasn’t much time between when we started QA and when we actually released.  Given the recent change in our maintenance release to every 2 months, and the extra time afforded by the winter holidays, we have decided to release a beta for 5.6.1 so that people have a chance to test what we’ll be releasing in January. 

At this point, the code is pretty stable and we have a very small list of outstanding regression issues we are working on for this release.  You can see the list of outstanding issues on the DotNetNuke Roadmap for 5.6.1.  If you find an issue, please log it into Gemini and we’ll take it from there.  It is unlikely that any bugs found at this point will make it into 5.6.1, but it will give us a good head-start on identifying issues to be fixed for 5.6.2.

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. 

I am happy to announce the release of DotNetNuke 5.6.  In 5.6 we spent a lot of time enhancing existing features addressing bugs and including a few minor features.  One of the goals during 2011 will be to not only add great new features, but to also add some depth to existing features.  The 5.6.0 release is a good first step in that direction.  The DotNetNuke Community Edition 5.6 includes new features such as:

• Improved Search: 5.6.0 includes an enhanced indexing capability which allows the standard core search feature to index page names, tag attributes and other metadata for improved search results
• Performance Enhancements: Optimizations to the database architecture and handling of web analytics tracking codes which will result in faster performance for all Editions of the product
• Configuration Manager:  A new configuration manager provides DotNetNuke administrators with greater access and control over their website configuration files without requiring the user to have direct file access.

DotNetNuke Professional and Enterprise users also have some significant new enhancements as well including:

• Site Search: Exclusive to the Professional and Enterprise Editions, the new Site Search engine allows site users to quickly locate files and pages in the site. The search engine includes rich query syntax with support for Boolean searches, phrase searches, relevance searches, wild cards, fuzzy searches, and groupings. Based on Lucene, the system includes a true web spider that is capable of indexing any site, whether it is built on DotNetNuke or not.
• Enhanced Analytics Support: The DotNetNuke Professional and Enterprise Editions include Enhanced Analytics Support, which allows users to take full advantage of Google Analytics. The system has been upgraded to the latest integration best practices from Google and now enables tracking of sub-domains as a single entity as well as the use of up to five segmentation rules per page.
• Content Approval Workflow Enhancements: The Professional and Enterprise Editions now allow managers to configure approvals in a top-down hierarchy at the site, page, and module level. In addition, content locking improves efficiency and reduces the chance of workflow conflicts. Approvals ensure that users throughout the organization that are impacted by a content change can review updates before they are published. The business rules engine enables workflows with an unlimited number of states and reviewers.

Earlier this Week a public version of the DotNetNuke 5.6 Beta was made available on CodePlex.  For information on how you can help with this release and to get access to the current version please visit our Beta Release page on DotNetNuke.com.  In this release we have spent quite a bit of time cleaning up some lingering...

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Myths and Misconceptions

Over the past several years designers have expressed a number of frustrations about the DotNetNuke skinning engine.  Often these frustrations may be based on some particular difficulty they are having and therefore there is a kernel of truth to the issue.  What I frequently find when digging into these challenges is that there is a misunderstanding by the designer which leads to the frustration or the design is constrained by limitations in HTML and CSS.  Fundamentally, we need to do a better job of providing documentation to the design community which helps them to better address their points of frustration.  Below I present some of the common myths about DotNetNuke skinning.

I am happy to announce the release of DotNetNuke 5.5.1.  This release includes many bug fixes for the most critical issues identified in DotNetNuke 5.5.0 which we released last month.  As a result of the recent ASP.Net Padding Oracle Vulnerability, which was discussed by Shaun Walker and Cathal Connolly in their recent blogs, we have added additional checks and upgrade enhancements in this release to ensure that DotNetNuke sites running the latest version are using the recommended CustomErrors configuration.  

As we have noted in many of our recent releases, we continue to increase our Quality Assurance efforts with each release.  Given the critical nature of the ASP.Net vulnerability, we paid extra attention to more than 40 different upgrade scenarios to increase the stability and reliability of the upgrade process, and to ensure that once upgraded your site would be protected.  As always, even for those unfortunate few who have issues upgrading, the community stands ready to assist you with any problems you may encounter.  We highly recommend that everyone upgrade to the DotNetNuke 5.5.1 release as soon as possible.  For those who are unable to upgrade their sites we anticipate having a standalone module which we will make available later this week which provides the same benefits against the padding oracle vunlnerability as the core enhancements made in 5.5.1.

Have you ever installed a piece of software but weren’t sure where to go from there? Have you struggled to find that feature that you know is there, but you’re not quite sure how to turn it on?  Have you occasionally had problems just getting some complex piece of software installed?  These are challenges faced by the average user of almost every piece of software ever created.  Few software applications are so straight forward and simple that no documentation is required.  As software becomes more and more complex, the documentation and training requirements increase as well.  You need documentation and training that caters to the beginner as well as the expert.

I have heard many DotNetNuke users recite these same challenges.  Like every content management system or application framework I have ever encountered, DotNetNuke is a complex system, so it is not unusual that some new users will find it challenging to get started.  It is also not unusual that many experienced DotNetNuke users and developers will find new features and capabilities that they never knew existed.  The biggest hurdle for many users is the perception that DotNetNuke is not well documented or that the only place to find information is in the forums.

Over the last 8 years, the DotNetNuke team, and the DotNetNuke community has created a wealth of documentation, videos and books covering all aspects of DotNetNuke.  As an Open Source project, DotNetNuke has relied heavily on community members not just for coding and design skills, but also for providing much of the documentation that is available for the platform.  Unfortunately, we have not always done a very great job of making that information easy to find for users.  Some of the information is available on DotNetNuke.com, but often you may need to venture out to other websites to get information provided by the broader DotNetNuke community.

My purpose with this post is to provide a good starting point for anyone who is new to DotNetNuke, and even for many long-time DotNetNuke users, administrators, designers and developers.  This list is far from exhaustive, but will provide a very solid foundation that should answer a lot of questions.  I have used everyone of these resources and know that they are all provide high quality material that is fairly up to date.  If you have been using DotNetNuke for any period of time, I am sure you have your own list of resources that you find valuable.  Feel free to leave a comment and tell me what documentation and training resources you have found helpful.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Packaging

History

One of the great strengths of the DotNetNuke platform over the past 6 years has been the rapid growth of the ecosystem for modules and skins.  Very early in the project’s history we realized that in order to promote redistribution of extensions, we needed a standard method to package modules.  At the time, one of the community members contributed their code for reading a standard xml file located inside a zip file containing all of the module files.  Using this contribution as the foundation, I created the core module installation feature for DotNetNuke.  The xml file that controlled the installation process came to be known as the module manifest. 

The purpose of the manifest file was to identify key files within the package and designate where they should be installed.  This manifest also contained some additional metadata that was necessary for creating the needed entries in the different module tables within DotNetNuke.

Over time, Charles and myself continued to extend the module manifest and the packaging standard so that we could handle more and more installation scenarios. Even with these additions, the manifest and packaging standard was still basically the same as what I had originally built in 2004.

When Skinning was introduced with DotNetNuke 2.0 it used a different packaging standard.  Instead of relying on a manifest, it used a convention based approach and depended on having files follow a specific naming standard.  This worked well, but it had a number of limitations.  Like the module packaging standard, this remained largely unchanged until fairly recently.

This article is cross-posted from my DotNetNuke blog.

On August 18th we kicked off the Mobile DotNetNuke Hackathon at the St. Louis DotNetNuke User Group. ...

This article is cross-posted from my company blog.



Last...

Last night we held the kick-off for the third in our DotNetNuke Hackathon series of events.  Now that the user group meeting is over and the UStream event is through, we can focus on building some really exciting mobile applications for the actual Hackathon.  The following schedule lays out the timeline for the remainder of this event:

We left plenty of time so that anyone who wants to participate has enough time to come up to speed on mobile app development and still get an awesome app built by the August 27th deadline.  I know that we already have participants talking about all of the great mobile apps they are working on and plan to submit for the contest.  With an iPad and some Android phones up for grabs I am certain we’ll have some really amazing entries, and like all of our community contests, the code for all of these applications will be available in the DotNetNuke Forge.  Even if you don’t win, you are certain to learn a new skill that will come in handy as mobile devices become more ingrained in our day to day lives and mobile application development takes a more prominent place in the software development world.

I am happy to announce the release of DotNetNuke 5.5.  Since we first released Localization support in DotNetNuke 3.0, we have known that the story was not complete.  With DotNetNuke 5.5, I am pleased to say we now have full localization support.  This was one of the main features that we laid out in our DotNetNuke 5.x vision at OpenForce 2007 and was the last major feature missing from our original roadmap for the 5.x platform. 

Content localization in DotNetNuke 5.5 will allow you to easily manage your web pages in a primary language and then utilize translators to keep the content synchronized in multiple secondary languages.  Whether you are maintaining your site in a single language or dozens of languages, the content localization system will help guide your content editors and translators through the process.  Although content localization required extensive changes to the core platform, we have been able to add this new feature while still improving overall system performance.  In addition, with the hundreds of other changes, enhancements and bug fixes, people are already saying that they are finally ready to migrate off the 4.x platform.

DotNetNuke 5.5 also marks another milestone: earlier today we announced the immediate availability of DotNetNuke Enterprise.  DotNetNuke Enterprise adds Content Staging to an already impressive list of features available in the DotNetNuke Professional platform.  As we have done with DotNetNuke Professional since we originally launched it 16 months ago, we will continue to expand and strengthen the features of the DotNetNuke Enterprise platform over the coming months to ensure our customers are receiving a great return on their investment.

Last year at OpenForce Connections in Las Vegas, Shaun Walker announced an updated release policy.  The goal in 2010 was to move to a monthly maintenance release schedule along with Quarterly major releases.  Prior to this policy announcement, releases were quite sporadic which made it difficult for our internal planning purposes, and also made it difficult for our users to schedule their own upgrade testing and deployment.  When we first committed to...

Ever since an updated version of Telerik assembly was shipped with DotNetNuke 5.4, people have continued to report that the Telerik assembly is missing from the \bin folder in the upgrade package.  Given the number of reports related to this issue, it is clear that there is a lack of available documentation for how DotNetNuke is packaged.  Some of these problems will be helped by the new wiki project that is being worked on by the Core Reference team.  The wiki will provide a place where we can document application behavior.  Since the wiki is not quite ready to open for public use, I’ll try to document what is going on with respect to Telerik in this post.

During the 5.3 release we originally intended to include an updated version of the Telerik controls. Our goal is to include new Telerik assemblies with each major release.  Since 5.3 was the first major release following the introduction of Telerik controls in 5.2 we had hoped to make the shift.  When we first created the 5.3 package, we found that attempting to upgrade from any of the 5.2.x packages resulted in a yellow screen when you first start the upgrade.  As a result we pushed the Telerik upgrade to 5.4 so we could better study the problem and find an appropriate solution.

Last night we posted another beta of DotNetNuke 5.5 which you can access from the beta release page on DotNetNuke.com.  This is probably your last chance to provide feedback on the 5.5 release as we are nearing completion of the testing cycle.  You can have a direct impact on the quality of the 5.5 release if you act today.

Since the last beta release 2 weeks...

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Building Containers

DotNetNuke breaks up our “themes” into two different parts – skins and containers.  In part 1 and 2 of this series, I showed you how to make the page layout portion of a DotNetNuke Skin.  It can be a bit confusing to new users because the term skin is used to describe the entire “theme” and also to describe the page layout portion of a complete skin package.  Containers are a much easier term to understand and will be the focus of this post.

Background

A DotNetNuke website consists of a set of pages on which the user places and configures one or more modules.  In order to integrate the module into your website the framework wraps your module in a DotNetNuke Container.  Containers are designed to coordinate with the corresponding skin as one element in a unified design and are used as a frame around your individual bits of content. Containers provide the ability for designers to seamlessly integrate modules from many different developers into a single cohesive site design.  Since the designer has complete control over the appearance of the container, they can choose to visually frame content or to even have content blend in with the rest of the page elements such that there is no differentiation to a normal end user where one module ends and another module begins.  Containers can also include visual elements which allow the user to interact with the module.  At a minimum, most containers will include the Module Action Menu that administrators and editors use for configuring the module.

Your DotNetNuke site can be configured with a default container which can then be overridden by both individual pages and modules.  Even though a set of containers may be designed for use with a particular skin, you are free to mix and match any container with any skin and to use several different containers on a single page.  This flexibility is one of the great strengths of the DotNetNuke Skinning engine as it allows a small set of skins and containers to provide for many different layouts and designs for a given site.

This article is cross-posted from my blog on DotNetNuke.com.

Ever since the localization framework was first introduced in DotNetNuke 3.0, it has always been our intention to go back and complete the localization story for DotNetNuke.  When localization was...

I am pleased to announce the release of DotNetNuke 5.4.4.  This maintenance release resolve’s two significant breaking changes that slipped through in 5.4.3 and resulted in us pulling the 5.4.3 release. Below are the highlights from this months release. As usual, you can see a full list of changes in the changelog.

Major Highlights Fixed issue with ExecuteSql method overloads to be able to handle ExecuteSQL(string,...

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Understanding the Basics

In the first part of this series we’ll be covering the basics of DotNetNuke Skinning.  My intent is to demystify some of the terms that we use and to relate them to our simple design.  Once you understand the basic elements that make up a DotNetNuke skin, then the rest of the skinning process becomes very easy.

A Little Background

One of the original goals we had when the DotNetNuke skinning engine was first created in 2003 was to make skinning accessible to both developers and designers.  This fundamental requirement has driven many of the changes over the years and continues to shape how we think about skinning in DotNetNuke.  From the very outset we thought that it was important that skin developers should be able to use whatever tool they were comfortable with and that they should not require any knowledge of programming in order to create cutting edge designs.  We also thought it was important that we put as few restrictions as possible into the skinning engine which would provide skinners with complete freedom in their designs.

The DotNetNuke skinning engine supports 2 different types of skins:  HTML Skins and ASCX Skins.  HTML Skins are the most basic form of skin and allow designers to use whatever HTML editor they desire.  When HTML skins are installed in DotNetNuke they are automatically converted to ASCX skins in the background.  During the conversion, the only part of the HTML skin that is retained is the innerHtml of the body tag.  Anything in the HTML Header will be discarded.

The DotNetNuke skinning engine recognizes a “Skin” as having two distinct entities: skins and containers.  These elements can be packaged and installed as a single package or as two distinct packages.  We’ll discuss containers later in this series and for now will focus on just the main skin package.  All of the concepts translate directly from skins to containers with a few minor differences.  If you understand how to create a skin, then creating the associated containers is easy.

I am pleased to announce the release of DotNetNuke 5.4.3.  This month’s maintenance release focused on resolving major issues with page management and with the Telerik HTML Editor Provider.  The page management fixes should resolve all major outstanding issues in this area.  The HTML Editor Provider fixes addressed some of the larger issues with the provider, although we recognize there are still several fixes and enhancements that remain for this particular item which we hope to address in the upcoming 5.5 release.  The 5.4.3 release also includes a number of security fixes.  As always our community continues to work...

Isaac Asimov was once quoted as saying “The only constant is change”.  That has certainly been true of my time with the DotNetNuke project. Over the last seven years of working on the DotNetNuke project and working at DotNetNuke Corporation I have held a number of different roles within the organization.  I have defined and coded major product features, built and managed the DotNetNuke Marketplace, managed the release process, managed both OpenForce Conferences, oversaw the QA function, and created and managed the DotNetNuke Professional support team.  During this time there have been a lot of things for which I am proud to have...

Over the last 18 months I have been working on a series of DotNetNuke extensions aimed at providing Twitter support in DotNetNuke.  The effort started with Monitter4DNN which is a DotNetNuke Module for displaying an auto-updating list of tweets based on some search criteria.  The search terms are completely configurable by the module administrator.  This module was subsequently renamed to SocialScapes which is more indicative of the long-term vision for the project.

SocialScapes is envisioned as a social framework with a supporting suite of modules, widgets and mobile applications.  Ultimately the goal is to incorporate data and services from multiple social networks, with the core platform running on DotNetNuke.  The administrator should be able to configure the platform through a set of plugins to interact with one or more social platforms. 

I am pleased to announce the release of DotNetNuke 5.4.2.  5.4.2 is a monthly stabilization release which addresses a couple dozen issues with the 5.4 release.  Because of the 5.4.1 release, the 5.4.2 release cycle was shortened which meant that a few high profile issues were not able to make the cutoff for this release.  We expect to address those issues in the 5.4.3 release due out in June.  This release also includes numerous code contributions and bug fixes submitted by the community.  We will be working closely with the community on the 5.4.3 release in order to further scale the number of issues we can get addressed in that release. As usual, you can see the full list of changes for this release on the changelog.

I am happy to announce the release of DotNetNuke 5.4.1 which corrects the major issues which slipped through the QA process for 5.4.  While we try to do a good job in testing our releases, our recent efforts for 5.3 and 5.4 have fallen short of the mark.  We are currently working with a small team of commercial module developers and the core team to put a better public beta testing process in place that will help augment our own internal testing.  Ultimately, community testing is the only testing that truly scales, and we have struggled with how to effectively use the community even while keeping to a tight release schedule.  While this is not as critical for our stabilization releases where we seem to have no difficulty achieving an acceptable level of quality, it is absolutely essential that we have community feedback and testing of our quarterly feature releases. As usual, you can see the full list of changes for this release on the changelog.

Last week, I discussed a new change in 5.4 where we have backported the RibbonBar from DotNetNuke Professional to the Community Edition.  Well that is not the only big change that is occurring with this release.  We are also backporting the Telerik Editor Provider!  This is another huge win for the community.

Over the course of the last 7 years we have primarily had 2 different HTML editors that we have shipped with DotNetNuke.  The first text editor we used was FreeTextBox.  It is a great little editor that served us well for the first couple of years of the project.  Unfortunately, FTB changed their license which caused us to re-evaluate the editor we should be using.

About 3 years ago we adopted FCKEditor as the default editor for DotNetNuke and it provided a lot of features that were not available in FreeTextBox.  The FCKEditor Provider has been developed and maintained by Mauricio Márquez and really made a lot of advances over the provider that was used with FreeTextBox.  Mauricio has done a great job on the FCKEditor Provider and has always been very responsive whenever we have had issues that needed to be addressed.  My only regret is that our internal release process was more difficult than it should have been which made Mauricio’s job more difficult. 

I am pleased to announce that once again we are backporting a feature from DotNetNuke Professional Edition to the Community Edition.  In DotNetNuke 5.3 PE we added a new control panel which leverages the Telerik TabStrip to provide increased functionality over the previous IconBar.  Some of the new control panel functionality makes common tasks even easier and provides more streamlined access to some administrative areas of the application.

I am happy to announce that the DotNetNuke 5.3.1 release is now available for download.  This release was focused on fixing 3 significant issues with the 5.3.0 release which caused us to remove the release from CodePlex and our DotNetNuke Support Network.  It is never easy to admit that significant issues slipped through testing and made it into a release package forcing you to take drastic actions.  The only thing we can do is to re-evaluate our processes and continue to find areas...

With any software product you will occasionally have a release that you wish you could take back.  Microsoft had Windows Vista, and Tuesday we had DotNetNuke 5.3.0.  We had a couple of significant bugs which slipped through the QA process and which resulted in a major impact to customers.  Rather than continue to compound the problem we have made the decision to pull the 5.3.0 packages from CodePlex and from DotNetNuke Support Network while we test a 5.3.1 release which we expect to release early next week.  5.3.1 is specifically going to address the following issues:

Email is not delivered to end users and instead a significant number of system emails are being sent to the administrator account instead.  This impacts the ability of users to register and to get password reminders and as such is a showstopping bug that will be fixed in 5.3.1. Synchronize and SynchronizeFolder in the...

I am happy to announce that the DotNetNuke 5.3.0 release is now available for download.  This release marks the fourth month in a row where we have hit our targeted release date.  That is a huge accomplishment for the project as the DotNetNuke Corporation engineering team is really starting to gel.  During this release cycle we also had a number of significant contributions by core team members. 

Over the past year, as our development methodology has undergone change and we have hired more members for the engineering team, the core team contributions have dropped off.  This was mainly because it is very hard to manage contributions when our own internal processes are not well defined.  Now that our DotNetNuke Corp. engineering team finally has some stable processes in place, it will be even easier for core team and community members to contribute to the project.  We recognize that sometimes you need to take a step back in order to re-evaluate and re-engineer your processes.  Having spent the last year doing just that, we are now in a much better position to work with the core team and the community to continue evolving the platform at a much more rapid pace to keep up with the ever changing web application landscape.  This is definitely a great time to be a part of DotNetNuke Corporation and the DotNetNuke Community.

The 5.3.0 development cycle has been unlike any in our 7+ year history.  In some respects this is good and in others – not so much.  As I explained in my Just Like Clockwork post, we are working hard to make monthly releases a habit and to have release schedules that are predictable.  DotNetNuke 5.3.0 marks the first major release we have attempted since splitting our engineering group into feature development and maintenance groups.  As always, doing anything for the first time can be challenging.

The maintenance group has gotten into a pretty good grove with our monthly releases, but adding an external group into the mix has added an additional level of complexity.  The maintenance group is able to make our changes in a single branch and quickly test, package and release our monthly stabilization releases.  Unfortunately, the feature dev group works in a separate branch which means code merges, integration testing, lots and lots of regression testing and in general a more complex testing and release process.  We certainly have learned quite a bit from this first cycle which we’ll apply to future major releases.

Over the past several months we have been making some significant changes in our release process.  We have made a commitment to monthly releases, opened up our code repository and in general have made a move to be more transparent.  During this same period we have also made some changes to our development processes to separate our feature development from our bug fixes.  The DotNetNuke 5.3.0 is our first quarterly feature release that is benefiting from this new development process. 

In addition to splitting out our feature development, we are also using a more formal Scrum methodology and have broken down our features into different code sprints.  This process allows us to deliver a set of features that can stand alone  and be tested independent from other features or enhancements which might be delivered in later sprints.  This flexibility also enables us to be a little more fluid with our quarterly releases which are often timed to coincide with major marketing events.  This Alpha release is a merge between the 5.2.3 codebase and DotNetNuke 5.3.0 Sprint 1 development branch and includes the following features:

Over the last several years DotNetNuke has maintained a policy of providing an upgrade path for users running previous versions of the platform.  Only in rare instances will we intentionally break a feature or an API or do something that would cause 3rd party extensions to break.  Customers have expressed to us over the years how important it is to maintain an upgrade path.  This concept is not unique to DotNetNuke.  Various projects and companies will take a different stance on the topic.  I was reminded of this recently with the Windows 7 launch where XP users were forced to make a tough decision – go through the hassle of installing a clean version of Windows 7 and then installing all of their old software and migrating their data (I hope grandpa had good backups), just stick with Windows XP, or move to a competitor.  Even Apple recognized the problem with the Windows 7 approach as evidenced by their Mac vs PC commercials.

Another month, another DotNetNuke release.  With each passing month the Quality team continues to get better at building DotNetNuke in a repeatable manner.  Our processes are becoming more and more automated and our QA and maintenance teams are starting to become comfortable with the processes.  It is a marked change from where we were just 12 months ago.  As a stabilization release, we focused this month on closing out the highest profile issues in the issue tracker.  We continued our efforts to solidify the installation experience and have expended additional effort in adding more error handling to the New Module wizard that was added in 5.2.  One major change in this release is that we are moving away from doing any significant enhancements during a stabilization release.  Occasionally we will have a minor change to existing functionality that is aimed at providing better feedback or otherwise resolving a usability issue.  Outside of these issues we will do our best to avoid introducing any new or changed behaviors which are more likely to introduce new defects into the product.  We do have one significant change in this release in the form of support for the PayPal sandbox which was implemented prior to our policy change.  You can see the highlights from this release below.  As usual, you can review the ChangeLog for complete details.

At OpenForce ‘09 we made a lot of announcements about changes to the DotNetNuke project.  One change that we announced was a commitment to provide more regular releases.  Over the past several years we have always focused on making releases when the software was “ready”.  This policy worked well when the project was staffed by volunteers as planning for fixed release dates is extremely difficult when you don’t know from week to week who would be able to work on the project, or how much time they would have available.

In software development, there are 3 major levers that you have available to manage a release given a fixed set of resources:  Time, Scope and Quality.  In general, we don’t feel that quality is a factor where you can cut corners.  This only leaves time and scope as levers you can use when preparing a release.  In the past we have worked on a somewhat fixed scope and fixed quality philosophy.  We tried to determine the features and bug fixes that would go into a release and keep testing until we felt that the software met the desired quality.  In 2010, we have shifted this approach and are now working to fixed release dates with a desired quality level and will adjust the scope as needed to ensure that we can meet our time and quality commitments.

In December the DotNetNuke project made a large upgrade to our issue tracker which had been stuck on an old version for the last couple of years.  We have been using Gemini from Countersoft for the last 6 years and it has served us well.  Unfortunately, earlier versions were having performance problems with the amount of issues we were tracking across all the module projects along with the Core framework.  Countersoft made a decision when moving from 2.x to 3.x to completely overhaul the security model.  If you ever had to use Gemini 2.x for a large project like ours you would have found that the task for migrating the old security settings was enormous.  We had over 40 projects each with security configuration affecting hundreds of users.  As a result of the shear amount of work involved, we avoided upgrades long past the time when an upgrade was warranted.

I am pleased to announce that DotNetNuke 5.2.2 has been released.  DotNetNuke 5.2.2 is a monthly stabilization release and includes a number of fixes aimed at improving the overall stability and performance of the platform.  Over the last year we have been undergoing a lot of changes behind the scenes in how we manage the DotNetNuke release process which I’ll be discussing in a separate post.  The result of all that effort is that our releases are becoming more predictable and with greater emphasis on testing.  This particular release reflects those process improvements.  As usual, the complete details for all of the changes can be found in the ChangeLog.

Major Highlights Fixed issue where tabname lookup's were case-sensitive and caused problems when loading controls. Fixed issue where Captcha control did not include a value for the Alt attribute. Fixed issue where...

I am pleased to announce that DotNetNuke 5.2.1 has been released.  DotNetNuke 5.2.1 is a monthly stabilization release and includes a number of fixes aimed at improving the overall stability and performance of the platform.  We continue to significantly enhance our testing effort with each release.  The 5.2.1 release benefited from an improved testing procedure that included several iterations of Load and Performance testing.  While we recognize that there is always room for improvement, we hope you’ll find that this release represents another significant step forward and further improves an already great product.   This release includes a number of fixes related to upgrade and installation scenarios.  Over the next couple of stabilization releases we will continue to focus on improving this critical part of the product.  As usual, the complete details for all of the changes can be found in the ChangeLog....

The last 7 years has been a very exciting time for the DotNetNuke team.  This period has been marked by constant change.  Sometimes the changes were positive and helped move the project forward, and other times the changes did not achieve the desired results and thus became a learning opportunity.  During this period we have had almost 80 core team members and project leads, had 5 major releases, hosted the project on 3 different open source websites, had 3 different project forums, and used 3 different source code management systems (hat tip to the reader who can name the websites and SCMs) .  We have also launched a company, created a commercial version of the project, and hosted conferences in North America and Europe.  All in all, it has been a pretty busy time, marked by lots of changes.  There have been 3 constants throughout the life of the project – Shaun Walker has always been the leader of the project, DotNetNuke has always been offered under a BSD open source license (we’ll conveniently ignore Shaun’s brief flirtation with a different license in 2003), and we have always operated a closed repository.  Today I am happy to announce that one of those is changing.

I am happy to announce that DotNetNuke 5.2.0 has been released.  This release comes after an extensive beta testing period and a corresponding effort by our internal testing team.  As one of our quarterly feature releases, 5.2.0 includes a number of new capabilities.  We have improved some of the module creation and packaging tools, improved our module caching support and added Page Output caching for our Professional customers.  These are just a few of the many changes and fixes in this release as indicated below. As usual, the complete details for all of the changes can be found in the ChangeLog.

Last year at OpenForce, DotNetNuke Corporation was on the verge of closing our first round of funding.  2006, 07 and 08 were challenging years as we struggled to find a business model that would support our company of 6 and allow us to grow.  Shaun, Scott, Nik and I formed DotNetNuke Corp. with the goal of building...

For the past 7 years, the DotNetNuke project has provided various packages for users to simplify different installation and upgrade scenarios.  Each package was built to address specific requests from the community.  We have recently begun receiving requests for symbol files (.pdb files) and xml comments.  As a result of these requests, starting with DotNetNuke 5.2.0, we will be releasing a new Symbols package with each release.

One of the benefits of Open Source development is that you have a lot of community members to kick the tires and make sure everything is working correctly before you finalize a release.  In the past DotNetNuke has limited our beta releases.  Usually it would start with a small internal team and move from there to a selected group of public beta testers.  We generally did not hold wide...

After we released DotNetNuke 5.1.3 last night, a community member discovered a packaging error in the release.  Specifically the DotNetNuke WebControls 02.02.00 package was not properly integrated.  This package was added in 5.1.2 and included some additional defensive coding to help harden the DotNetNuke Web Controls against potential security issues.  The latest web controls package does not fix any specific security vulnerabilities, but rather improves the baseline security posture of the platform and makes it more difficult for a hacker to find and exploit vulnerabilities.  As a result of the mispackaging we felt it was prudent to release a new version to address this issue and ensure that the community and our Professional customers had a version which included these enhancements.

Upgrading to 5.1.4 is not necessary, but it is recommended.  The changes included in 5.1.4 help keep you safe from future attacks and as such is the recommended...

With the month of September coming to a close it is time once again for another DotNetNuke Stabilization release. 

 

DotNetNuke 5.1.3 resolves almost 40 issues with the previous release and further stabilizes the 5.x codebase.  Given the stability of the recent 5.x releases it should not come as any surprise that the fixes in this release tend to be narrow edge cases or resolved problems where well known workarounds were available.  We also added a minor modification that improves the ability of administrators to email event logs to their support providers.  This will allow system integrators, hosters and consultants providing DotNetNuke customer support to get a better snapshot of errors that the user is experiencing without relying on the user to accurately cut and paste error messages. The changes outlined below were incorporated in these releases.  As usual, the complete details for all of the changes can be found in the ChangeLog.

...

...

Overview A little over 18 months ago we had the first meeting for the DotNetNuke User Group in the Cleveland Ohio area.  Unfortunately, that was our only meeting.  It was always my intention to help get the Cleveland area DotNetNuke User Group off the ground but as the months dragged on other events just always seemed to take precedence.  Since that first meeting I have had the opportunity to speak at several different .Net and DotNetNuke User Groups.  The more I saw the success of the Capital DotNetNuke User Group (CDUG), the Los Angeles DotNetNuke User Group,...

Over the last 5 years, DotNetNuke has been blessed a large number of books being written about the platform.  I was fortunate to be part of the team that co-authored a couple of the first books on the platform, and I continue to try reading every book that comes out on the platform.  Some books, like Professional DotNetNuke 5: Open Source Web Application Framework for ASP.NET cover multiple aspects of the DotNetNuke platform and is a great book for Administrators, Developers and Designers, but it necessarily can’t cover every topic in depth.  Other books, like DotNetNuke Module Programming, are narrowly targeted at Module developers.

DotNetNuke 5.1.1 is now available for download.  This version of DotNetNuke is a stabilization release and focused exclusively on fixing outstanding bugs which did not make the cutoff for DotNetNuke 5.1 or which were discovered after 5.1 was released.  As many people in the community are aware, DotNetNuke.com had some difficulty running DotNetNuke 5.1 under extremely heavy loads.  As a result of that experience the DotNetNuke engineering team was able to isolate several performance issues which did not show up in any of the prior testing.  Fixes for those issues were incorporated in this release along with the changes outlined below.  As usual, the complete...

After more than 18 months of development, months of testing, and many, many long nights troubleshooting performance issues I am proud to announce the release of DotNetNuke 5.1.0.  This release represents the future of the DotNetNuke platform and is now officially recommended for production use.  While many users have been successfully running DotNetNuke 5.0 and 5.0.1 in production for many months, we feel that this 5.x release is finally mature enough that we recommend it for use in production environments.  This release includes hundreds of bug fixes and dozens of enhancements and new features.  Below is a list of just a few of the highlights from the 5.1.0 release. ...

DotNetNuke 4.9.4 is a minor stabilization release for the 4.x codebase.  This release is targeted at resolving a major defect with the module caching code and also addresses two minor security issues.  We do not anticipate any further releases of the 4.x codebase.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights in this release Fixed a major module caching issue which resulted in empty content for webcrawlers Improved performance of FormatRemoveSQL method Security Fixes...

As many people already know, I spent the past week traveling to California and Canada to meet with the DNN Corp. management and engineering teams. This was an exciting trip for me as it was a chance to see us reach one more milestone in the growth of DotNetNuke and DNN Corp. For the last 6 years, DotNetNuke has been a virtual organization with core team members spread around the globe. This is the norm for most Open Source projects and while it poses some challenges, it is something you learn to deal with if you want to be involved. When Shaun, Scott, Nik and I formed DNN Corp in 2006, we continued operating in this fashion. We each had our own home offices along with Charles Nurse and Bill Walker. Starting in January DNN Corp began hiring additional employees. It is no longer possible for everyone to work from home or to work from temporary office spaces and we began the search for office space. As anyone who has been through the process can tell you, it can sometimes take a while to find suitable office space and get it built out and ready for employees. In April we finally moved into new offices in both San Mateo, California and Abbotsford, British Columbia. This trip was my first opportunity to visit the new offices and meet some of our new employees.

Once again the DotNetNuke community will be heading off to Las Vegas in November for the annual DotNetNuke OpenForce North America conference.  We are looking for a handful of people who want free hotel accommodations and conference admission.  All you have to do is get selected to be a speaker.  You know you have a lot of great insight and knowledge of DotNetNuke and would love to share it with the DotNetNuke community.  Well today is your last chance to turn in your speaker submissions for the North American conference.  Just go to the OpenForce homepage at http://www.openforce09.com...

DotNetNuke 5.0.1 represents the latest release for the 5.x codebase.  While we have made significant strides in dealing with the most significant issues discovered in the 5.0.0 release, it is still not at a level where we recommend this release for production use.  DotNetNuke 4.9.2 still represents our most stable and mature release and is recommended for most users.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights Added the ability to automatically update user roles without requiring the user to logout and log back in. Changed the user deletion code to use...

Now that the holidays are through and we have had a chance to assess and fix a number of issues reported in DotNetNuke 4.9.1 and 5.0.0, we are just about ready to release DNN 4.9.2 and 5.0.1.  To avoid some of the confusion with a dual release we are going to stagger the two releases.

DotNetNuke 4.9.2 will be released on Monday, February 16th.  DotNetNuke 5.0.1 will be released the following Monday, February 23rd.  Barring any major hidden show-stopping issues, DotNetNuke 4.9.2 will be the final 4.x release and all future development will focus on the 5.0 platform.

As usual we will post release...

Stuart Hilbert was recently asking how you could create tabs inside a module in DotNetNuke 4.9.1.  In this post I’ll outline the technique we use on the Dashboard panel and for a module I am working on for DotNetNuke Professional Edition.

When building tabs I like to separate the development into two separate components: the visuals and the behavior.  This separation allows me to easily change each aspect without requiring a substantive change to the other component.  If I need a vertical navigation structure, I can easily accommodate that without changing my code.

The DotNetNuke project, with the release of DNN 5.0 and DNN 4.9.1, officially moved our project downloads to CodePlex. There were some questions in the DotNetNuke Forums about this and when my response started growing, I thought I would blog about it instead.

To address some specific questions:

Q:  Was this an impulsive decision? 
A:  This is something that has been in planning for many months and was not something done out of impulse. 

Q:  How do I find all of the related projects on CodePlex?  All the downloads were available on the same page at SourceForge.
A:  If you look on the DotNetNuke page on CodePlex, all of the other official DNN projects are listed.  You can also click on the DotNetNuke tag in the tag cloud (visible on the CodePlex homepage) to see a complete list of all DotNetNuke related projects on CodePlex (there are currently 88 listed). 

Q:  Are all of the core projects on CodePlex?
A:  Yes.  Scott Willhite and Shaun Walker worked with the CodePlex team to move over all of the official DNN Projects.  Not only did they move the project downloads, but they also moved the project’s historical data as well.  In addition, since CodePlex is also the official Forge repository, all past and future projects created from the DotNetNuke Forge will also show up on CodePlex.  So now we will have all of our projects consolidated in one spot.  There will still be some community projects which choose to use other repositories, but over time, you will see CodePlex becoming the first place people look for Open Source DotNetNuke related projects.

Christmas Eve was very busy for the DotNetNuke Team as we did a double release of both DotNetNuke 4.9.1 and 5.0.0.  This was my first time handling a double release and it was a lot more work than I anticipated.  Not only did we do a double release, but we also changed where we are hosting our downloads.  That is a story for another blog post.  Unlike 4.9.1, DNN 5 was a massive change that involved hundreds of bug fixes, changes and enhancements.  A large number of the bug fixes and a few of the changes...

The DotNetNuke 4.9.1 package was released on  Christmas eve.  This is an special date in the history of DotNetNuke as the original release was also on Christmas eve.  4.9.1 is a minor stabilization release, although we did add a few small enhancements including the new dashboard which I will cover in depth in a separate blog.  Below is a list of the major items included in 4.9.1.  As always you can see a complete list with all the details of each fix/change in the ChangeLog.

By now most of you have probably heard the news that DotNetNuke Corporation has raised a round of capital from Sierra Ventures and August Capital.  This marks another major milestone in the history of DotNetNuke.  Nik Kalyani , one of my co-founders in DotNetNuke Corp., has a great blog post describing some of his journey to reach this milestone.  Like Nik, I have a similar story I would like to relate about how we reached this point in our company and our project’s history.

My experience with DotNetNuke goes back to February 2003, a little over a month after it was first released.  Over the next 6 months after it’s release I became increasingly involved with the DotNetNuke project.  By the summer of 2003 I had been invited to participate on the DotNetNuke core team which marked one of the first major milestones in the growth of the project.  Over the following year the project made rapid progress and we went through a core team re-organization which included the creation of a Board of Directors.

I have to say how much I appreciate the great job the new DotNetNuke Blog project team is doing.  For a long time, I blogged fairly regularly on DotNetNuke.com.  Ultimately, I decided to start writing my primary blog on my own site and only occasionally reposting to DotNetNuke.com.  When I moved to my own site, I also decided to switch blogging platforms.  I needed something which supported many of the modern blogging features.  For me the killer feature is Windows Live Writer (WLW) support. ...

During the last couple of months as we were finalizing details for DotNetNuke OpenForce, I have been working on a Silverlight module that would allow visitors to the OpenForce website to see a real-time feed of Twitter posts related to the conference.  In the past this would have been done by using HashTags.org.  The problem with HashTags is that it requires users to remember to use the ‘#’ prefix to their terms.  It also requires twitter users to follow the @hashtags user.  Both of these requirements limit the usefulness of the service.  What I really wanted was a way to monitor anyone...

As I posted a few weeks ago, we have added jQuery support to DotNetNuke 5.0.  This support makes it easy for developers to add jQuery to their modules and know that it will already be available on the server.  We have not yet decided on whether to also include jQuery UI support, but I suspect that it will also be made available once we figure out which specific UI features to support (the whole UI library is over 200K and definitely too much for most sites).

With jQuery we have tried to provide a mechanism that only loads the jQuery library when absolutely necessary.  If none of the modules or skin-objects on a page require jQuery, then it won’t be included in the page.  If your module wants to use jQuery then you must include a long, complicated...

Earlier today, DotNetNuke hit another milestone with the release of DotNetNuke 5.0.0 RC1.  RC1 is our first stable DotNetNuke 5.0.0 release and represents a feature complete version of the 5.0 platform.  From here on out we will be focused on fixing bugs and ensuring that any performance issues are resolved.  While it is true that DotNetNuke 5.0 represents a substantial change from 4.8.x, many of the updates in 5.0 were back ported to the recent 4.9 release.  Below is list of highlights for this release which were not included in 4.9.0.

Major Highlights Added jQuery support to the core platform.  jQuery will now be distributed as part of the DotNetNuke installation and will be available for use by module developers. Added support for...

For the last 4 years DotNetNuke has been adding more and more client-side functionality using JavaScript.  First we started with the ClientAPI which has added some great features to the platform.  When Microsoft created ASP.Net AJAX, we were quick to implement that as well since it solved several problems and didn’t require us to re-invent the wheel.  One of the key features in DotNetNuke 5.0 is the new Widget framework which simplifies the creation and distribution...

DotNetNuke 5.0 has changed the way that the page administrator edit mode works.  In previous versions of DotNetNuke, when you were in “edit” mode, the page would display the content inside of the various panes on the page.  This made it possible to see the panes when you were ready to place a new module on the page.  The downside to this behavior was that the pane borders and pane titles often caused problems with the skin.  For power users and administrators who were logged into the site, this was problematic since they would were often displayed a substandard rendering of the site.  [more]



With DNN 5.0, pane titles and borders are no longer shown in edit mode.  This allows administrators and power users to have a more pleasant experience.  The video below shows the new behavior and how it aids in module placement without the side-effect of breaking the visual appearance of the page.

The Camtasia Studio video content presented here requires JavaScript to be enabled and the latest version of the Macromedia Flash Player. If you are you using a browser with JavaScript disabled please enable it now. Otherwise, please update your version of the free Flash Player by downloading here.





...

Over the last four years DotNetNuke has experienced tremendous growth and adoption.  We have added more features to the core and grown the project teams to the point where there are now more than 45 people actively working on one DNN project or another.  At the same time we have also grown the programs around the project that help fund DotNetNuke and provide support to the community - programs like the Benefactor Program, the Review Program,...

The DotNetNuke OpenForce '07 Conferences are getting closer and we need your help.  Did he just say "conferences"?  Yes he did.  I am happy to confirm that we are working with the Software Developer Network to co-host the DotNetNuke OpenForce Europe '07 conference.  This conference will expand on the DotNetNuke track for the Software Developer Conference which began with last years SDC event.  We think that this extra conference will help serve those European developers who will not be able to attend the OpenForce '07 conference in Las Vegas.

In order to help make both of these events a success and to ensure that we will be able to continue hosting these events, we need you to help get the word out. Below are the badges Nik Kalyani created for the conferences. While you're adding the badges to your blogs and websites, checkout the OpenForce website....

It seems that I am seeing more and more discussion around what constitutes Open Source software and Open Source projects.  Not only do you have the Free Software group who follow the Richard Stallman philosophy and the Open Source group who fall more into the Eric Raymond camp, but lately though you have a number of people for whom...

This weekend, DotNetNuke 4.5.4 was released to benefactors for final release testing.  4.5.4 is primarily a stabilization release with just a few key enhancements and one new feature.

The final release date has not been announced pending the results of testing by the benefactors and core team.  As part of this release we have started implementing new processes to help improve the stability of each release.  We still have a lot of work to do, but this marks the first step in refining the process.

 

 

 

Component Issue Type Issue ID...

The official list of Speakers and Sessions have been posted on the DotNetNuke OpenForce '07 website.  We are really excited about the list of speakers for the conference.  We have a few additional special guests that we are still finalizing and we'll keep you posted once we have confirmed their attendance.

As we started putting the conference together, we thought that it would be a good idea to include the broader .Net Open Source community in the conference.  This first conference still primarily focuses on DotNetNuke, but assuming we are succesful with this first event,...

After posting for a couple of years on my DotNetNuke.com blog, I have decided that it was time to start hosting my blog on a dedicated site.  There are a couple of reasons for this decision.  I have felt a bit constrained on DotNetNuke.com. 

Like much of the online world, the blogosphere is a fast moving environment.  There are dozens of tools aimed at making blogging a much richer experience and that simplify the blogging process.  Social networking sites like Digg and DotNetKicks that are aimed at bloggers have been...