It is my privilege to announce that the next version of DotNetNuke will be officially released as version 3.0.
The upcoming release simply contains too many significant enhancements to be considered a "point release". In addition to many small fixes and enhancements, look for all of these major features:
* Membership/Roles/Profile - integration of the Microsoft Whidbey ( ASP.NET 2.0 ) Membership/Roles/Profile provider API ( Microsoft graciously supplied us with a version of this provider which runs on ASP.NET 1.1 ). Integration of this provider allows us to conform to a common membership model which enables us to "play nicely" with other ASP.NET applications who adopt this API. It also puts us in the enviable position of being able to migrate to Whidbey with minimal effort in this area.
* Static Localization - all user interfaces have been modified so that their static resources are abstracted into resource files. The architecture conforms to the data storage format and page processing techniques in ASP.NET 2.0. This has been a monumental effort but it also results in some incredible benefits. All of the administration for DotNetNuke can now be easily localized into other cultures - exposing DotNetNuke to a vast international community. Initially we will be delivering English and German resources but, as always, we will be supplying expert tools to empower users to create and distribute resource packs for other cultures as well.
* Field & Module Level User Help - all admin user interfaces now have localized field level help text as well as localized module level help text. This usability improvement helps transform DotNetNuke from a developer-oriented application to a an end-user content management system.
* Simplified/Organized Administration UI - admin user interfaces have been reorganized to group common fields into collapsible sections to simplify the end user experience, yet still provide access to advanced functionality.
* Common Tasks - the Control Panel metaphor has been improved to include more of the common administration options at your fingertips. In accordance with our focus on extensibility, we have also added the ability for developers to create custom Control Panels which can be positioned anywhere within the admin interface.
* WYSIWYG - a new ClientAPI has been added which contains client side support for dragging and dropping modules for the Administrator as well as client side Min/Max of module content.
* File Management - DotNetNuke will finally support subfolders within each portal's upload directory. This includes replacement File Manager, File Uploader, and File Picker controls. This feature has been a long time coming and will enable you to effectively organize your content files.
* Portal Search - implementation of an Optional Interface model which allows module developers to publish summarized content to a central data store for portal-wide searching. Modules simply need to implement a single Search method in their controller class. Again, this solution is completely extensible - it is provider based to allow third parties to build custom Indexing engines which can easily be plugged in using common provider techniques.
* Friendly URLs - improvements to the URL specification within DotNetNuke to encode parameters as part of a "friendly" URL structure. This enables search engine spiders and robots to effectively index your DotNetNuke site for maximum exposure.
* Tabs - tabs can now point to an external URL, a local file, or even another tab within the portal. There is also the ability to schedule tab publication using Start and End schedule dates.
* Modules - modules now have the ability to specify a header and/or footer block which can be used to decorate module content. There is also the ability to schedule module publication using Start and End schedule dates.
* Banners - improvements to the banner advertising system to allow for better organization, Text ads ( similar to Google Adsense ), horizontal display, etc..
* And much... much... more...
The version 3.0 designation also relates to module compatibility
As part of our ongoing commitment to the community, we always try to preserve binary compatibility between version upgrades to ensure a smooth transition for end users and developers. In the past we have been largely successful in this philosophy - generally at the expense of more complicated core development and testing as well as the inclusion of code bloat to support deprecated legacy functionality.
Unfortunately, the implementation of the Microsoft Whidbey ( ASP.NET 2.0 ) Membership/Roles/Profile provider API has introduced at least one unavoidable "breaking change" in the 3.0 version.
Under the new Membership system, Context.User.Identity.Name now contains the UserName value - whereas DotNetNuke has always expected this to contain a UserID. Modules which have included direct references to Context.User.Identity.Name will no longer function correctly. This includes most third party modules, as it is best practice to store some audit information in your modules related to the user who last updated a database record. The code change is minimal ( there is now a shared UserInfo object which provides access to all user profile data within your modules ) - but it is still a code change - which means that 2.x modules will no longer function in 3.0.
Rest assured that we investigated various ways to deal with this problem but any alternative just looked like an ugly workaround. The future direction of ASP.NET would seem to indicate that Context.User.Identity.Name is expected to be a username and any deviation we make now will surely haunt us in the long run. So a decision was made to allow this "breaking change" which necessitated a new application version number for clarity.
Once we got past the philosophical impact of this "breaking change", we began to look at a number of other critical changes which we had been withholding for many months ( in favour of preserving binary compatibility ). The timing seemed opportune, so we decided to take advantage of this release to introduce a few other breaking changes for the long term benefit of the application. The concept is that making all of these changes in one breaking release, will help to avoid the prospect of other breaking changes any time in the near future.
For module developers and others interested in the details of any specific breaking change, we will conduct those discussions in the
Core Framework forum. Several items have been specifically posted already... and others will follow. The changes required to adapt to these breaking changes in your modules will be minimal ( mainly just a recompile of your code ) but at the same time we will be providing some suggestions on best practices to follow when creating/upgrading your custom modules for 3.0 ( ie. the new Search functionality, Localization, etc... ).