As of 2013-01-27, this is a problem because of many bugs both inside the wordpress_migrate Drupal module and the Drupal Commons 7.x-3.0 distro (which is not yet released, but making good progress). So, expect this guide to be out of date in a matter of days, then try to go along this while omitting the workaround steps (so then include tag and category migrations, and omit the patching).
Step by step guide:
- Empty WordPress trash. Before starting the import process, empty your trashbin in the WordPress blog. Else, already trashed posts and their comments are also exported in the WXR file, and will create confusing errors because of showing up as "Unimported" for blog entrys in "Content -> Migrate" statistics in the Drupal admin backend, and also trashed comments causing error messages "No node ID provided for comment" when trying to import comments in spite of the fact that the post was not imported.
- Export as WXR. Export a WXR file from your WordPress blog, using the "Tools -> Export" function.
- Install wordpress_migrate. Install wordpress_migrate for your Drupal Commons 7 installation. For that, execute in the document root directory of your site:
drush dl wordpress_migrate
drush pm-enable wordpress_migrate
- Clear cache. Clear the Drupal cache (this is the sign for the migrate framework to register the new migration classes):
drush cc all
- Fix comment migration. There is a bug report with a submitted but not yet accepted fix that prohibits importing comments, resulting in an error message like "Unknown data property field_target_comments. in EntityStructureWrapper->getPropertyInfo() (line 339 of commons-7.x-3.0-beta1/profiles/commons/modules/contrib/entity/includes/entity.wrapper.inc)." To prevent it, install the fix yourself:
drush cc all;
And if you attempted an unusccessful migration already, go to "Content -> Migration" in the Drupal admin backend and do a "Rollback" and then a "Reset" for the comments migration, before attempting a new one by executing the "Import" action there again.
- Start migration. Log into the Drupal admin backend and navigate to "Content -> WordPress migration -> Import". Here, select the following settings (also see their official documentation), then click "Import":
- Your WXR file as source.
- "Wordpress categorie: Do not import", "Wordpress tags: Do not import". (If your target content type like (here) "Page" has any vocabulary fields, the "Do not import" option is not available. Choosing one of the vocabularies will then make the import fail with an error message like "MigrateException: No migration found with machine name ExampleTag in MigrationBase::getInstance() (line 444 of […]/sites/all/modules/migrate/includes/base.inc).”. Or the same with “ExampleCategory”. So delete the vocabulary field before via “Structure -> Content types -> [your content type] -> manage fields").
- "Text: Full HTML", "Comments: Full HTML". [source]
- "Import pages to: Page" and "Import posts to: Page". [source] (Importing posts to "Post" would result in error messages like "Invalid argument supplied for foreach() File […]/commons_radioactivity.module, line 140". In contrast to pages, posts in Drupal Social Commons can belong to groups. So if you want to make posts, not pages, bulk-convert the pages to posts later with the node_convert module.)
- Create page aliases to match the original WordPress addresses.
- Register migration classes, if necessary. If no importing is possible at all, it may be because on your system the
drush cc alldid not properly trigger the migration class registration [issue report]. Then instead, call
drush migrate-auto-register[source]. This is however buggy in itself: try to access the "Content -> Migration" tab in the Drupal admin backend. It might fail with this error message: "MigrateException: Failure to sort migration list – most likely due to circular dependencies involving OgMigrateContent,
OgMigrateUser,OgUiMigrateAddField,OgUiSetRoles in migrate_migrations() ". This is because the drush command erroneously registered these "Og*" names as migration classes. Undo that by deleting the rows from database table migrate_status where column machine_name starts with one of these Og* names. [source1, source2].
- Ignore dependencies, if needed. Now your import should run, but it might not succeed. Because, no attachments or comments are imported if even one post fails to be imported. Error messages in this case are like:
Skipped ExampleAttachment due to unfulfilled dependencies: ExampleBlogEntry
Skipped ExampleComment due to unfulfilled dependencies: ExampleBlogEntry
In that case go to "Content -> Migrate" in the Drupal admin backend, select the migrations that have not run, check "Options -> Ingnore dependencies" on the bottom, choose "Import", click "Execute". This will import all comments and attachments for those posts that were properly imported.
- Import pingbacks too, if you want. At this time, the migration statistics in "Content -> Migrate" in the Drupal admin backend should show that everything was imported ok, except that there can be a non-zero number for unimported comments. These are most probably pingback comments. You can check that by looking into the database table migration_map_[migrationname]comment: find some source IDs that are not listed in column sourceid1 but appear in your WXR file as comment ids between <wp:comment_id>…</wp:comment_id>. If these are all pingback comments, indicated by <wp:comment_type>pingback</wp:comment_type> in the WXR file, you know the cause and probably want to ignore these. If you want to import pingbacks, too, you have to modify the WXR file by replacing all <wp:comment_type>pingback</wp:comment_type> with <wp:comment_type></wp:comment_type> (yes, that's correct: delete the value within this tag).