As part of building a robust Social platform, we have added a number of enhancements to Registration.

Registration, Login and Profile Settings

DotNetNuke is a very powerful and flexible platform.  The challenge that this brings is that it is often difficult to know where to make configuration changes.  User/Registration settings is one such area.  In this Beta we have tried to address this by moving the Registration settings to the Admin/Site Settings page.  Admins are familiar with going to this page to make configuration changes.

This blog has been cross-posted from my personal blog.

In the first post in this series I pointed out that DotNetNuke places few requirements on module developers, and this is often daunting to new developers – “where do I start?” being a common refrain.

So where do you start? 

Before we actually start to build our first module lets look at what constitutes a module.  In the default DotNetNuke skin/template that is used when installing DotNetNuke there are a number of examples of Text/HTML modules. 

As an example Figure 1 shows 3 such modules on the Home Page.

This blog has been cross-posted from my personal blog.

DotNetNuke has a rich eco-system of Modules, both Open Source and Commercial.  In many ways this is our biggest strength as a CMS platform.  No matter what you want to do with your site – there is often a module that already does it.

DotNetNuke 6.2.0 CTP 1 introduces a number of Profile updates - many of which update the Visibility options.

Admin-Only Properties - while this has always been available through the Visible property, this has been made clearer in the Help text for the property.

A Profile Property whose Visible property is false cannot be viewed in the Profile page by the user (but is visible to Administrators when they edit the user's profile, and is available to Module Developers through the API).

DotNetNuke 6.2.0 removes the maximum roles limitation of previous versions.

Many developers are aware that, prior to version 6.2.0, a semi-colon delimited list of roles was saved in the user's cookie.

As the cookie has a fixed size, this effectively limits the number of roles to which a user could belong to about 50 (the actual limit depends on the names used for the roles – shorter role names would increase the maximum limit slightly).

DotNetNuke 6.2.0 introduces changes to how the Tab (Page) Hierarchy is managed.

Due to the limitations of earlier versions of SQL Server, which we were required to support prior to DNN 5.4, the business layer had to manage the handling of the page hierarchy. Whenever a page (tab) was created or moved in the hierarchy, there was a lot of calculation to calculate the effect on other pages and update them accordingly.

In a large site like this one - if a page with a large number of descendants is updated then every descendant is updated so that its "Level" and "TabPath" can be updated in the database.

Welcome to a new series of blogs/articles on Patterns and Practices for development using DotNetNuke. 

In this series I will be asking members of the Engineering Team  at DotNetNuke Corporation and Community Members to contribute articles describing Patterns and Best Practices for DotNetNuke development.

n an earlier article in this series on the new WebMatrix suite of technologies from Microsoft, I described how we are supporting the use of Razor scripts in DotNetNuke, by providing a “Razor Host” module. 

Having created this cool new Razor script, how do you go about distributing it? 

WebMatrix is Microsoft’s new suite of technologies designed to make creating websites easier.  There are four major components to the new WebMatrix “Web Stack”

1. IIS Developer Express – a new free lightweight web-server, based on IIS 7, that runs on all versions of Windows and does not require Administrator level permissions
2. SQL Server Compact Edition – a lightweight file based database that is simple to set up and free to download.
3. ASP.NET “Razor” – a new  view-engine option for ASP.NET that can be used to easily embed C# or VB code within an HTML page. This is “bin” deployable and free.
4. WebMatrix Tool – a free lightweight developer IDE that integrates all the components.

Have you ever tried to write Unit Tests for multiple implementations of an Interface or Abstract Base Class.  I encountered this problem over the weekend in a personal project and after some poking around I realized that MbUnit supports this ability using the Factory attribute.

In DotNetNuke we make extensive use of the Provider Pattern, so as we develop tests for the core we will encounter this scenario.  In this post in my irregular series on Testing I describe how you can write a single Test Fixture that elegantly handles the testing of any number of concrete implementations.

Earlier today Scott Guthrie announced a new “Web Stack” called WebMatrix.  WebMatrix is both the name of the complete stack (Web Server, Database and View Engine) as well as the name of the new lightweight development tool that you can use to create, edit and publish websites.

In a previous article in this series of blog posts, I described the different Test Doubles that can be used when unit testing your application.

My favourite type of Test Double is a Mock.  Mocks are usually dynamically created by a mocking framework. Mock objects are preprogrammed with expectations which form a specification of the calls they are expected to receive.

In a previous article in this series of blog posts, I introduced Moq (Mock-you) – the mocking framework we are using in DotNetNuke to generate Mock objects for testing.

In DotNetNuke version 5.3, we introduced the concept of a centralized Content store, together with the ability to apply Taxonomies (categories) to the content.  We have extended this in DNN 5.4 by completing the MetaData API as well as adding Folksonomy (user tags).