warning: Creating default object from empty value in /mnt/www/html/mryan1/docroot/modules/taxonomy/taxonomy.pages.inc on line 33.

Upgrading to Drupal 8 using Drush

So, perhaps you've been reading Upgrading to Drupal 8 using the UI and thinking "hey, what about us cool kids who use Drush for everything?". Or, maybe you just know drush is better than a UI for running long processes like migrations. Well, this blog post is for you... We do have drush commands for running and rolling back upgrades, currently in the migrate_upgrade module (but which should land in Drush itself by Drupal's 8.1 release at the latest).

Upgrading to Drupal 8 using the UI

Now that the second Drupal 8 release candidate (RC2) is available (with a significant fix for those upgrading from Drupal 6), it's time to start planning for your upgrade from Drupal 6 or Drupal 7. As I previously wrote, the migration system is "experimental" in 8.0, and at this time (mid-October 2015) the tools for upgrading are in a contributed module, Drupal Upgrade. The plan is that the upgrade path will be fully supported in core for Drupal 8.1 - to reach that goal, however, we need the path to be tested on a wide variety of sites in the meantime. So, we encourage everyone with a Drupal 6 or Drupal 7 site to start testing the upgrade path today - you don't want Drupal 8.1 to come out and only then discover your site has some quirk that's not fully accounted for. Even better, you might fight the upgrade path works just fine for your site and you can upgrade in the Drupal 8.0 timeframe!

The current documentation for performing your upgrade from Drupal 6 or 7 to Drupal 8 is on drupal.org - I'll walk through the process as it exists today, but should you be referring to this blog post after October 2015, be sure to review the official documentation for any changes.

This post explains running the upgrade process through the Drupal 8 web interface - if you'd prefer to use Drush, please see Upgrading to Drupal 8 using Drush.

Update on migration in Drupal 8

It's been a breathless past several weeks in Migrateland - with the core committers as a whole focused on trimming the criticals list for Drupal 8 to zero, Angie "webchick" Byron has given quality time to help the Migrate team get unblocked, triggering a flurry of activity. All along I've meant to post a status update, but things have been moving so fast it's been "well, after this next commit..." Let's review where we stand at the moment, as of September 18, 2015.

Upgrade path

From the initial decision to replace the traditional update-in-place (update.php) approach to major version upgrades with a migration-based (import into a fresh site) approach, it was made clear that the initial Drupal 8 release would not be blocked on the upgrade path. If the upgrade path was not "ready", Drupal 8.0.0 would release without it and be available for building new sites only. The plan was as Drupal 8 approached RC status the decision would be made over migration support in 8.0.0. That decision has been reached and published. By all means go ahead and read the official policy as well, but tl;dr: the migrate API and the Drupal 6 upgrade path (and possibly the Drupal 7 upgrade path as well) should be part of the Drupal 8.0.0 release, but marked as "Experimental".

Update on migration in Drupal 7

A quick update on where the migration-related modules I maintain on Drupal 7 (migrate, migrate_d2d, and wordpress_migrate) stand now, to help set people's expectations of the level of support they can expect in the issue queues. There are two main points:

  1. I am now officially working full-time on migration in Drupal 8, for the time being (I'll have a blog post with details on that work shortly).
  2. I feel that the Drupal 7 migration modules are pretty much functionally complete.

Migration contribution catch-up plan

Well, what with an increase in client work and a move halfway across the country (Somerville Mass to Murphysboro Illinois), I'm afraid I've fallen further behind on the issue queues for migrate, migrate_d2d, and wordpress_migrate. It's been a bit of struggle to triage the queues, so to somewhat automate the which-issue-to-work-on-next process, I'm reducing it to an algorithm (each step of which will be applied to migrate, migrate_d2d, and wordpress_migrate in that order).

  1. Bug reports with patches (needs review, rtbc), oldest to newest
  2. Other bug reports, oldest to newest
  3. Other issues with patches (needs review, rtbc), oldest to newest
  4. Triage of support requests to make sure no bugs are lurking there

At that point, I plan on cutting release candidates for all three modules. Hopefully at that point I'll be able to start doing a better job of responding to new issues as they come in. Hard to say when I'll have a chance to review and respond to older support and feature requests, though, it'll depend on my workload (but of course I'm not the only one in the community capable of helping out with support requests - hint hint).

Thank you.

Edit: Let's keep track of where I am... I'll also note that not all issues will necessarily get committed/closed, there will be some triage as I go along and not everything will make the cut for Migrate 2.6 and the corresponding migrate_d2d/wordpress_migrate releases.

  1. Bug reports with patches, migrate
Syndicate content