A Direct Migration of WordPress to Drupal 8
Migrations from WordPress to Drupal are required when customers are standardizing on Drupal to ease institutional IT staffing requirements, or they just want the many additional customization capabilities built into Drupal. Here is how to migrate your WordPress data directly into Drupal 8 using the Migrate API.
Here is one workflow to get started quickly …
1. Setup your D8 site (drupal-8-0-5) locally. This blog post assumes your WP site is already setup on your local environment.
2. Get the required contributed module dependencies (using Drush Version: 8.0.0)
dave$ drush dl migrate_manifest, migrate_tools, migrate_plus, migrate_update
3. Grab the Migrate Wordpress module code base
dave$ git clone https://github.com/amitgoyal/d8_migrate_wordpress.git
4. So now, I like to go thru the Drupal UI to enable the required (7) modules
- CORE (EXPERIMENTAL)
- Contributed Modules
5. We need to make a quick edit to assure correct 'file management' when running this combination of modules, so from the Finder (Mac), rename the module directory "d8_migrate_wordpress" to just "migrate_wordpress". This is the one module we downloaded above using the git command.
6. Then this one Drush command migrates the content
dave$ drush migrate-manifest modules/migrate_wordpress/manifest_wordpress.yml --legacy-db-url=mysql://root:root@127.0.0.1/bitnami_wordpress
(The hardest part about this whole workflow is getting the components of this one Drush command correct. If you get it right the first time, you rock!!! Keep at it if you don't, you will get it eventually, and then you are still awesome!!!)
7. This returns
Running wp_vocabulary [ok]
Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done [status]
with 'wp_vocabulary'
Running wp_terms [ok]
Invalid argument supplied for foreach() Migration.php:276 [warning]
Processed 55 items (55 created, 0 updated, 0 failed, 0 ignored) - [status]
done with 'wp_terms'
Running wp_users [ok]
Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done [status]
with 'wp_users'
Running wp_posts
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' [error]
{{{ ==>>> THEN LOTS OF FEEDBACK HERE!!! <<<== }}}
Processed 68 items (47 created, 0 updated, 21 failed, 0 ignored) - [status]
done with 'wp_posts'
Running wp_comments [ok]
Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done [status]
with 'wp_comments'
Right now Drush dl drupal-8 gets me the “latest” release of 8.0 which is 8.0.5 … but when it switches to 8.1 (in two weeks) migrate in core will obsolete some the current migration contrib modules that we added in. Also, the Drush Migrate commands are likely to be moved out of contrib and put right into Drush itself, so that will require a fresh update of Drush.
If you get lots of error messages on your import as shown in Line #17 above, this is normal, and simply means it is time to start debugging. A good place to start is by looking at your Source (WordPress) database and comparing that to your Target (Drupal 8) database.
Open up your WP database via the bitnami manager-osx app by clicking “Open phpMyAdmin”.
Based on my output, I want to look at the wp_post tables. With a quick sort on the content there, I can see that there were a lot of wp_posts that had no content (NULL) and a few that were things like test pictures, references only to calendars, or other such things that I could have deleted in WordPress before the migration. There is no sense in bringing in excess junk that is not needed and won't be used in the new Drupal 8 site.
Likewise, on the Drupal 8 side, I can easily open up phpMyAdmin from Acquia_dev_desktop app. There I can see Drupal did indeed populate the nodes from the wp_posts that actually had meaningful content. So there is a level of inherent intelligence built into the Drupal 8 import process!
When we loaded and enabled the many migration modules, we packed in a lot of powerful drush commands that can help dissect the migration process in great detail.
For instance we can look at MIGRATE STATUS
dave$ drush ms
dave$ drush ms
Group: default Status Total Imported Unprocessed Last imported
wp_vocabulary Idle N/A 3 N/A 2016-03-28 22:02:28
wp_terms Idle N/A 55 N/A 2016-03-28 22:02:29
wp_users Idle N/A 2 N/A 2016-03-28 22:02:28
wp_posts Idle N/A 47 N/A 2016-03-28 22:02:30
wp_comments Idle N/A 2 N/A 2016-03-28 22:02:31
Or, we can just undo the migration wih MIGRATE ROLLBACK
dave$ drush mr --all
Rolled back 2 items - done with 'wp_comments' [status]
array_flip(): Can only flip STRING and INTEGER values! [warning]
EntityStorageBase.php:232
array_flip(): Can only flip STRING and INTEGER values! [warning]
EntityStorageBase.php:232
Rolled back 47 items - done with 'wp_posts' [status]
Rolled back 2 items - done with 'wp_users' [status]
Rolled back 55 items - done with 'wp_terms' [status]
Rolled back 3 items - done with 'wp_vocabulary' [status]
'Rolling back' the migration removes the WordPress content that was just migrated in. This is very handy because it allows you to double check what you just did, or you can rollback and try migrations one table at a time.
Run the drush migrate-manifest command (from #6 above) again to capture the WordPress content again. This time you'll notice that Drupal just skipped the malformed the content (such as "[NULL]" in the wp_post tables).
dave$ drush migrate-manifest modules/migrate_wordpress/manifest_wordpress.yml --legacy-db-url=mysql://root:root@127.0.0.1/bitnami_wordpress
Running wp_users [ok]
Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done with [status]
'wp_users'
Running wp_vocabulary [ok]
Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with [status]
'wp_vocabulary'
Running wp_terms [ok]
Invalid argument supplied for foreach() Migration.php:276 [warning]
Processed 55 items (55 created, 0 updated, 0 failed, 0 ignored) - done with [status]
'wp_terms'
Running wp_posts [ok]
Processed 47 items (47 created, 0 updated, 0 failed, 0 ignored) - done with [status]
'wp_posts'
Running wp_comments [ok]
Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done with [status]
'wp_comments'
And then looking at the migration status one last time ...
dave$ drush ms
Group: default Status Total Imported Unprocessed Last imported
wp_vocabulary Idle N/A 3 N/A 2016-03-29 03:24:59
wp_terms Idle N/A 55 N/A 2016-03-29 03:24:59
wp_users Idle N/A 2 N/A 2016-03-29 03:24:58
wp_posts Idle N/A 47 N/A 2016-03-29 03:25:00
wp_comments Idle N/A 2 N/A 2016-03-29 03:25:00
... we can see a clean import of the different types of content migrated in from WordPress.
To sum things up...
In this blog we covered another workflow that lets you grab all your WordPress content and migrate it into Drupal 8 very quickly. Once your Source and Target sites are setup on you local workstation, its just one drush command that brings it all in. This happens so quickly that we showed you how to Rollback everything just as quick so you can run it again to double check your work.
There are many additional migration commands that lets you do analysis, audits, registries, mappings, messages, wipes and more. A wide set of options can be applied to the commands as well. These allow you to be very specific about exactly what content you are targeting to import into exactly the right place into Drupal 8.
Drupal migrations are a very broad topic when considering the number of sites out there with content locked up in proprietary CMS or underutilized in less versatile CMS than Drupal 8. Hopefully, this workflow will help you out NOW when considering rolling over your WordPress sites into Drupal 8.
(Special shout of thanks to amitgoyal for his work on the d8_migrate_wordpress module.)
- Log in to post comments
Function1, Inc. Copyright 2024. All Rights Reserved