Blog

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the release of Drupal 8 by upgrading their own sites and addressing the issues they find along the way. This series chronicles the journey from Drupal 6 to Drupal 8. Part 2: Preparing to Migrate.

Part 1: Readiness Assessment | Part 2: Preparing to Migrate

Part 3: Migrating D6 to D8

I first tried running this migration back in November at BADCamp, where I was able to work with Migrate architect and Tag1 Senior Performance Engineer, Károly “ChX” Négyesi. As a result of our work, there are a few patches I’m using to solve issues I’m still encountering. Before running the migration, I pulled the latest commits to 8.0.x. Everything I describe below took place with Drupal core at commit 3359738e0fe, which contains all the commits through December 24. I re-created a migration manifest as described in Part 2: Preparing to Migrate. I briefly reviewed known issues with the D6 > D8 migration path and followed along with Migrate’s main documentation which provides guidance for running migrations, including the drush command:

drush migrate-manifest <manifest-name> 
--legacy-db-url=mysql://<username>:<password>@<host>:<portno>/<db_name>

Issues

Of the 82 migrations I attempted, the following 8 reported issues.

Files

Files and user pictures failed to copy to the new site and files are not attached to the node they where they had originally been uploaded. Because we’d been using the Inline module which allows users to display uploaded files and images inline and it has no 8.x version, I’ll disable the migration and use core’s wysiwyg to replace images.

Blocks

The block migration produced PHP Fatal error: Call to a member function uuid() on a non-object. This is a straight-up bug. I worked with chx, who showed me how to use PHPStorm and xdebug to track down the issue, and we made a patch back at BADCamp, but it still needs work before it’s ready for core. In the meantime, it solved the issue for me, so I used it.

Menu Links

This migration was problematic and the patches referenced below didn’t solve the problem. For this simple site, the best recourse was to rebuild the menu system by hand, but this presents a serious issue for any site with complex menus.

Book Module

I hadn’t bothered removing migrations that were irrelevant. For example, I didn’t have any book content and the module was uninstalled on both sites. Even so, it was still in the manifest, and I hit the following error:

Node Setting Promote

The promotion options on the nodes have values, but the labels, Promote and Sticky, as well as their descriptions are not displayed.

Vocabulary Migration Errors

I hit errors with respect to the “forum” vocabulary. We’re not using Forums, so I uninstalled it from the D6 site. This removed the error, but nodes were still not associated with their terms.

The Moment of Truth

Once I’d resolved (or avoided) all the fatal errors and the migration ran cleanly, I visited my new site. On first glance it was a little disconcerting. I’d already run into many of these issues when I ran the migration at BADCamp, and they were still happening. More disconcerting, however, was the discovery that I can’t add new content nor edit any content.

Front Page Not Loading

The first view of the site looked broken, and rebuilding the cache with drush didn’t help either. Still, a lot of things happened with the migration, so I figured I’d try logging in: The login page looked proper, and I went straight back to the home page. Even without even logging in, the theme looked normal. That’s easy enough to cope with. I added this to the Known issues.

Couldn’t Edit Nodes

I couldn’t edit the nodes that had been migrated. I initially lost some time on this because “Recent log messages” referenced reported “Missing filter plugin: filter_null.” which turned out to be irrelevant, but made me suspect the migration. When I verified that the problem occurred with core and not just migrations, I finally checked my Apache error logs, which revealed what I needed to know - I had a local configuration issue:

Aliases Not Working

I’d encountered this problem at BADCamp and it was still happening: none of the content was loading by URL alias. I looked at the values in the url_alias table, and saw no langcode was set.

MariaDB [tag1six]> select * from url_alias limit 10;
+-----+------------------+------------------------------------------------------------+----------+
| pid | source           | alias                                                      | langcode |
+-----+------------------+------------------------------------------------------------+----------+
|   1 | node/9           | blog/jeremy/Achieving_Optimal_MySQL_Performance_for_Drupal |          |
|   2 | tagadelic        | tags                                                       |          |
|   3 | node/12          | performance_checklist                                      |          |
|   4 | node/16          | Improving_Page_Load_Times                                  |          |
|   5 | taxonomy/term/11 | Dries_Buytaert                                             |          |
|   6 | taxonomy/term/7  | Drupal                                                     |          |
|   7 | taxonomy/term/3  | performance                                                |          |
|   8 | taxonomy/term/10 | scalability                                                |          |
|   9 | taxonomy/term/9  | Tag1_Consulting                                            |          |
|  10 | taxonomy/term/14 | ab                                                         |          |
+-----+------------------+------------------------------------------------------------+----------+

I set the value in the database with update url_alias set langcode ='en' and nodes loaded by their alias.

Couldn't Edit Users

Trying to edit users resulted in the errors below., and until all the profile fields were removed, users couldn't be edited at all.

Node Authors not Migrated

During the BADCamp migration, I saw that node authors weren’t being set. I experimented with putting the user migrations before the node migrations, which worked, but a more proper approach is in under development and a patch available at https://www.drupal.org/node/2376141.

This concludes what was reasonably possible with Migrate this week. I think it bears repeating that Migrate is NOT a requirement for a Drupal 8 release candidate, nor for Drupal 8 itself. With more than 85 critical core issues, it’s likely that Migrate won’t be ready for site builders for quite some time. Developers, however, can pitch in!

Overview