Research: What is exported from a WordPress blog?

What gets saved when you export a WordPress blog?  I know the format of the export file is XML and that all posts, pages, categories and authors are exported.  See:

http://support.wordpress.com/moving-a-blog/

Not sure if files, sidebar settings, themes or roles can be exported….  There are tools that exist to migrate WordPress blog to other platforms, but not all or perhaps any of them will migrate files…

WordPress to Drupal

There are two main modules for migrating WordPress content to Drupal, see:

http://drupal.org/project/wp2drupal

http://drupal.org/project/wordpress_import/

WP2Drupal interacts directly with the database, whereas WordPress_Import uses the WXR export file.  It is not clear whether these migration modules also migrate WordPress files.  There is Drupal code out there for migrating files on a remote server to Drupal, see:
http://bensangeorge.com/2009/06/drupal-bits-migrating-remote-files-in-drupal/

It also looks like Drupal is working on a migration framework, see:
http://drupal.org/project/migrate

2 thoughts on “Research: What is exported from a WordPress blog?

  1. Adam Franco

    As long as we are running a blogging platform, we should help users migrate content from an old blogging platform to a replacement blogging platform. However, I don’t want to get into the habit of promising to migrate content between all of our platforms. For example, as long as we continue to run WordPress as our main blogging platform, I do not think we should invest in the development time to support migrating blogs into Drupal (or into MediaWiki for that matter).

    The problem is one of exploding combinations.

    For example, assuming that we run one each of a blog, CMS, LMS, and Wiki at a time and migrate to new versions of each every few years, we have one migration step to do at a time. This is sometimes painful, sometimes easy, but is a built-in cost of migrating a system. As well, these migration tools only need to work for the period of migration, not maintained indefinitely.
    Linear Migrations Diagram

    If we start trying to migrate content between systems or recommend/promise such a thing, then we quickly get ourselves into a situation where we must maintain many migration tools over a long period of time.
    Cross-Migrations Diagram
    This would be an enormous support and development cost that I imagine would vastly outweigh the benefit to our users.

    Were a policy of providing cross-migrations between one or more tracks of applications to be recommended, I think this would require funding and institutional buy-in to support it. If tools happen to exist to migrate between two tracks of platforms, I don’t have a problem installing those tools, but we should not be spending all of our development time writing such tools if there is not a clear institutional benefit.

    – Adam

    Reply
  2. Alex Chapin

    You’re right, we shouldn’t promise to migrate content from any one platform to any other platform, the exploding combinations would indeed likely exhaust our resources.

    Still surely there’s a middle ground between completely linear migrations and cross-migrations. While migrating content between wikis and blogs does not seem very useful, migration from Segue or WordPress to Drupal might be….

    While WordPress is a blogging tool, many people are using it in ways that you would be hard pressed to call a blog. For example see James Morrison’s site on International Political Economy.

    Most of the sites created in Segue are not course sites, but sites for resources, depts, areas, e-portfolios, blogs. Some of these could be migrated to an LMS, but many of them might be better re-created in Drupal or WordPress.

    With these ideas in mind, Consider:
    CT Migration Proposal Diagram

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>