DotNetNuke: Staging Content Using Roles

The problem:

Currently DNN only lets us stage content using the Text/HTML module and only if you have the pro or enterprise version of DotNetNuke. There are three issues with this:

  1. We can only stage HTML content. Other modules need to resort to some other method.
  2. We can’t see what the full site is going to look like when all of the staging content goes live.
  3. There is no easy way to stage navigation changes.

In a typical development environment changes to code and content are typically made to a staging area. The client is able to review the changes in this area and when the changes are finally approved, the content can be pushed to production.

Again, DNN has limitations. While I have been able to figure out how to do an “all or nothing” push from stage to production without over-writing user content or membership information, doing partial pushes to production have been problematic at best.


The proposed solution:

By utilizing roles we can control who sees what content on a page or even which pages they see. While more extensive systems may use more roles to control who sees what content, the four main roles that are used in most DNN systems are:

  • Administrator
  • All Users
  • Registered Users
  • Unauthenticated Users

By adding parallel staging users, we can stage content for these four user types. In addition, we can create users who are only allowed to change content that is in staging and protect the content that is in production from any inadvertent changes. The four additional roles we need to make this work are:

  • stageAdministrator
  • stageAllUsers
  • stageRegistered
  • stageUnauthenticated

We will then create three users and associate the proper roles to them (in addition to the standard roles that DNN assigns):

  • stageAdmin
  • stageAdministrator
  • stageRegistered
    • stageAllUsers
    • stageRegistered
  • stageUnregistered
    • stageAllUsers
    • stageUnregistered

    You will notice that the stageAdmin user is only assigned the stageAdministrator role. This is because all of the pages and modules the stageAdmin user should be able to edit will have the roles assigned to this user explicitly. If you also assign the other roles to this user, you will not get the results you will expect.

    Setting up module permissions so this all works:

    For a system already in production, the roles will be assigned as you are already accustomed to with two minor exception. If you have any pages or modules that are assigned to display for the “unauthorized” role, you will also need to assign the page or module to the “stageUnauthorized” role so that it will display for both production and stage users when it is not a page or module that is being edited. Similarly, you will need to set any modules set to display for authorized users to not display for stageUnauthorized users, since they are registered users by default.

    Moving from stage to production:

    So, for now, let’s assume that you have been working on stuff that is in a staging role and it is ready to go to production. Here is what you will need to do.

    First, change the end date on the module or page that is being replace to the last day it should display. For example, if this should go live at midnight tonight, set the end date to today’s date. Then, on the module or page that is going live, set its start date to the date is should go live. Again, if the module or page should go live tomorrow, set it to tomorrow’s date. Next set the permissions on the new module or page to the same permissions as the module or page it is replacing.

    Let’s take a look at an example:

    Related Post

    • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it wrong, which...
    • DotNetNuke Modules – Benefits of ArchitectureDotNetNuke Modules – Benefits of Architecture Now that we have something running, it's time to take a look at the various parts of the DotNetNuke framework.  But before we do, we need the all-important question, "Why do we care?" From a...
    • DotNetNuke Modules – Making Content PortableDotNetNuke Modules – Making Content Portable The last main feature of module development that we need to discuss is the implementation of IPortable. If you've ever worked with other content management systems in a corporate environment, y...
    • DotNetNuke Modules – DNN Controls – LabelDotNetNuke Modules – DNN Controls – Label The DotNetNuke framework has several built-in controls that you should use instead of the controls you would typically use in an ASP.NET application. Before we can go much further, we need to revie...
    • DotNetNuke Modules – Exceptions the DNN WayDotNetNuke Modules – Exceptions the DNN Way Everyone knows (or should know) that handling exceptions is  a fundamental feature of the .NET environment.  And most of the time if we don't handle the exception ourselves the .NET environment wi...