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

Related Post

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail

Bear