Home » DotNetNuke - Module Development » DotNetNuke Modules – Making Content Portable

DotNetNuke Modules – Making Content Portable

office-02 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, you’ll appreciate the implementation of this interface since the number one issue most organizations have is getting data from a staging area to a production area.  Occasionally we’d like to get the content from production back to test or even into development.  Many times we deal with this issue by just copying the database and the web application files from one area to another.

That works.  But what if you want to move your content from one module on a page to another installation rather than the entire application?

That’s what IPortable does for us, as well as allowing us to move the entire site from one installation to another without having to move any files or the database.

Setting up IPortable is very similar to setting up ISearchable.  You’ll want to specify your controller class in the module definitions and you’ll want to make sure the controller class inherits from ISearchable.

Next, you’ll need to add the following two methods to your controller class:

public string ExportModule(int ModuleID)
    return "";

public void ImportModule(int ModuleID, string Content,
    string Version, int UserId)

From here, the details are module-specific.  But in general, what you want to do is to store the information for how to recreate this module into a string.  The recommendation is that you store it into an XML string since this will be the easiest to parse.

You’ll want to store any settings information as well as all of the records that would be needed to recreate this module using the ModuleID as the identifier for the module.

Once you’ve done that, you’ll then be able to use the ImportModule method to parse the Content parameter which will be in exactly the same format.

You will notice that the ImportModule also contains a Version parameter.  You’ll want to check this since the version information of the module that created the Content string will be specified here.  If there was a format change between modules, you’ll want to account for that here.

The UserId parameter probably won’t be needed.  But it is there so that you can use it if you do have some use for it.  For example, if you need to attach user information to your records, you’ll need this ID.

Once you have coded these two methods, you can then use the Action menus to export and import this data to a file on the server.  You can use the File Manager to download the file so that you can use it on another server and the File Manager on the new server to upload it and then use the Import action to get it loaded into your module.

As I mentioned at the beginning, this functionality is not just limited to one module at a time.  You also need to implement this functionality so that you can export your entire portal and import it using the portal export/import wizards.  This allows the administrator to move his site from one server to another easily.


Other post in DotNetNuke - Module Development

Like this Article? Subscribe to get every article sent to your email.

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 […]
  • 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 […]
  • DotNetNuke – Modules – Portal Specific ModulesDotNetNuke – Modules – Portal Specific Modules Many of you won't care too much about creating Portal Specific Modules because you'll be creating modules for an environment that only has one portal. However, if you are creating a […]
  • 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 […]
  • DotNetNuke Modules – Where Stuff Shows UpDotNetNuke Modules – Where Stuff Shows Up We continue our series on creating DotNetNuke modules today by showing you where the various components of the module we created last week show up in DotNetNuke.Remember, last […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.