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 this new release schedule, we knew that it was going to take a little time before we could get into the groove with the new release cycle.  By February we had 3 monthly releases under our belts and things looked to be going pretty well, so much so that I blogged about it.

We are now 8 months into the release schedule and following some issues with a few of our recent releases we’ve had a lot of feedback from customers and community members regarding the release schedule. Some users have indicated that monthly releases just didn’t give them time to properly test and upgrade their sites before a new release was coming out and they had to start the cycle all over again.  Other users worried that committing to monthly releases was hurting the quality of our releases.  Conversely, some users liked the frequent releases because it meant they could get bug fixes quicker.  Some users also liked the predictability of the release schedule.

After a lot of discussions with community members, with the core team members, with customers and with partners we have decided to modify our release schedule to address many of these concerns.  Starting with the 5.5 release we are moving to maintenance releases every two months and reducing our major releases to 2 or 3 a year depending on the complexity of the features included with each release.  We will still be targeting specific release dates so that we can scope each release and set proper code-freeze dates, but we will adopt a more quality driven approach to the final release date.  If we need an extra week or two on a release to make sure we get it right then we will extend the release date to make sure we meet both our own quality standards as well as yours. 

We believe that these changes to the release schedule will allow us to still provide a level of predictability in our releases while also addressing the pacing and quality issues raised by many of you.  We appreciate the feedback that has been provided on this and many other issues and are always willing to listen to your concerns.  As I stated in a recent blog post, Open Source works best when you get involved.  Your feedback does make a difference.

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.

More...

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 ago, the DotNetNuke team has been busy cleaning up bugs and validating the user scenarios for the new Content Localization feature.   During this time more than a 160 bugs and enhancements have been implemented.  Many of these changes have been as the result of feedback we received from the earlier alpha and beta releases.  In addition to all of the work on Content Localization we have fixed a number of longstanding bugs and made major strides on improving performance.  We are hoping to be able to wrap up testing soon so that we can get a final release out to the community this summer.

Content Localization required many foundational changes to DotNetNuke so it is important that we get as much feedback as possible.  If you have an existing DotNetNuke website, try to perform an upgrade on a backup copy of your site.  If you are a module developer, run your module through some installation and upgrade scenarios.  If you are skin designer, make sure that your skins install and work correctly.  If you are new to DotNetNuke, give the beta a trial run and let us know what you think. 

Once you have done your testing then let us know your results – good or bad.  You can post any issues you find on our issue tracker.  You can also discuss the betas on the Open Core Testing forums.  Let us know what you liked, what you didn’t like or what problems you are having.  Open Source works best when the you get involved.

Overall, 5.5 is shaping up to be one of our most significant releases in the last 2 years and your help would be greatly appreciated in making sure this release is as solid as possible.

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.

More...

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 first introduced in DotNetNuke, we only tackled the localization of static strings.  This support for the localization of static strings was sufficient to address the needs of many international users, however it was not adequate for addressing multi-lingual sites.

We realized from the beginning that content localization was a tough issue to address, and one which could be solved in numerous ways.  Every time we looked at tackling content localization, the effort always seemed to be a bigger than we had the resources to be able to tackle.  We wanted to make sure that whatever solution we put in place would meet the needs for a large portion of our community.

After many meetings with members of our Internationalization team, international community members and customers, and after many months of development, we are finally ready to release a DotNetNuke version which supports content localization.  I will leave it to others on our development team to go into the details of the implementation as we approach the final release of 5.5.  You can see an earlier version of code in the two videos that Scott previously posted.

Today, I am pleased to announce that an Alpha version of DotNetNuke 5.5 is available for download.  We are still in the middle of addressing some outstanding bugs from previous releases along with any bugs we are finding in the new 5.5 specific code.  We anticipate being able to release a beta version next week, but need your help in identifying any major outstanding issues with the current alpha release.

Because this is an Alpha release, we will not be supporting a seamless upgrade to the final 5.5 release.  This code should not be deployed in a production environment since we haven’t completed performance testing and tuning and we know that significant bugs still exist in this version of the code.

You can download the code from the Beta Release page on DotNetNuke.com.  Please post any questions or comments on the release to the Open Core Testing forum.

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, nothing) again.
• Fixed issue with Indirect Reference to DotNetNuke Library errors.

Security Fixes

• None

Updated Modules/Providers

The following modules and providers have been updated in the 5.4.4 packages.  Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

• Media Module 03.03.00

Providers

• None

NOTE:  As with any release, we recommend you perform a complete file and database backup before performing any upgrade on a production website and that you first conduct a trial upgrade on a staging version of the site.  Following these guidelines will ensure that you are able to recover should any unforeseen problems arise during the upgrade process.

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.

More...

This morning I updated the source code for the Silverlight Pages module that I am building as part of the DotNetNuke Hackathon.  Based on some feedback from Michael Washington, I did a little refactoring to separate out my XAML display markup into a separate view.  This makes the code just a little bit cleaner and allows me to develop the view in Blend (of course that is a whole new thing to learn which will have to wait for later).  For now I will continue to hack away in XAML, learning a bit more each day and shaking off some of the cobwebs from what I had learned 2 years ago.

More...

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 with the security team to identify potential security issues and to help test the subsequent security fixes. As an Open Source project, the DotNetNuke platform and the community benefit tremendously from this collaborative relationship that allows us to discover security issue in a timely manner and quickly work to resolve them.  Finally, I want to thank those community members who provided bug fixes for this months release.  Their efforts help to create a better product for all of us.  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 where page level and TabPath were not properly updated for descendents
• Implemented LinkClick functionality in Telerik editor.
• Fixed issue with displaying a module on all pages.
• Fixed issue with page management not working correctly.
• Fixed issue where messaging was using incorrect logic to notify users.
• Fixed issue with PurgeExpiredItems when the portal's home folder may not have been mapped correctly.
• Fixed issue when hitting Enter while in the Tag edit text box.
• Fixed issue where bulk updates did not properly repair existing modules.
• Fixed a bunch of minor HTML formatting issues.
• Fixed issue with sending Event Viewer exception messages when using Secure SMTP.
• Fixed issue with module caching being ignored for non-browser user agents.
• Improved performance by only loading HTML Module menu when user is allowed to see it.
• Fixed issue where the DNNCountryEditControl does not return a value in the PropertyEditor
• Fixed issue with using external URL Rewriters causing error in initWidgets.js
• Fixed the issue with the ToolsFile property of the Telerik Editor to set the appropriate property on the underlying RadEditor.
• protection was added to ensure that a hacker who had a valid login to a site could not use viewstate details to perform a cross-site request forgery to public functions.
• alter log files extension so their existance or contents cannot be useful to potential hackers
• an additional filter was added to the existing core blacklist filter to catch an invalid tag that could lead to a cross-site scripting issue
• at present profile properties automatically strip dangerous XSS characters from data. In addition they support regular expressions to allow sites to configure the allowable characters. We've added an additonal html encoding to ensure dangerous html cannot be passed
• due to a logical error in the profile property provider, it's possible for member only profile properties to be displayed to non-members. Code was added to protect against misconfiguration revealing sensitive data.
• added additional encoding to sitelog to follow security best practices.
• Improved security by HTML Encoding taxonomy tags.

Security Fixes

• Logfiles contents after exception may lead to information leakage (Bulletin 37)
• Cross-site request forgery possible against other users of a site (Bulletin 38)
• Update inputfilter for invalid tag that could allow XSS attack (Bulletin 39)
• Mail function can result in unauthorized email access (Bulletin 40)
• Fix issue where member only profile properties could be exposed publically under certain conditions (Bulletin 41)
• Profile properties not htmlencoding data (Bulletin 42)

Updated Modules/Providers

The following modules and providers have been updated in the 5.4.3 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

• none

Providers

• none