The Drupal 6 to 8 Upgrade Challenge - Part 3

Melissa Anderson

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> 


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


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.

Migration d6_file
Severity Serious
Error failed to open stream: No such file or directory EntityFile.php:70
Solution Disable file migration in the manifest


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.

Migration d6_blocks
Severity Fatal
Error Call to a member function uuid() on a non-object in core/modules/migrate_drupal/src/Plugin/migrate/process/d6/BlockPluginId.php on line 87
Solution Patch:

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.

Migration d6_menu_links
Severity Serious
Error PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'menu_name' cannot be null' in core/lib/Drupal/Core/Database/Statement.php:61
Solution Removed the migration from the manifest

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:

Migration d6_book
Severity Trivial
Error exception 'Drupal\Component\Plugin\Exception\PluginNotFoundException' with message 'The "book" plugin does not exist.'
Solution Removed the migration from the manifest

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.

Migration d6_node_setting_promote
Severity Normal
Error base_field_override entity with ID already exists. (drupal/core/lib/Drupal/Core/Entity/EntityStorageBase.php:391)
Solution Unsure
Issue/s Expand FieldConfig/BaseFieldOverride with methods

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.

Migration d6_vocabulary_field_instance
d6_vocabulary_entity_display d6_vocabulary_entity_form_display
Severity Serious
Error Vocabularies and terms are migrated but are not applied to the nodes Missing bundle entity, entity type <em class="placeholder">node_type</em>, entity id <em class="placeholder">forum</em>. (core/lib/Drupal/Core/Entity/EntityDisplayBase.php:166)
Solution Relink

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:

Migration N/A - Local configuration issue unrelated to migrate
Problem Adding or editing nodes led to a white screen.
Error PHP Fatal error: Maximum function nesting level of '100' reached, aborting! in /var/www/eight/drupal-beta4/core/vendor/twig/twig/lib/Twig/Node.php on line 141
Solution In php5/apache2/php.ini, I set the xdebug.max_nesting_level = 500

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.

Migration d6_url_alias
Problem Nodes wouldn’t load by URL alias
Solution Apply patch before migrating or fix in the database after migrating: update url_alias set langcode = 'en';

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.

Migration - d6_user_profile_entity_display
- d6_user_profile_entity_form_display
- d6_user_profile_field
- d6_user_profile_field_instance
Problem Editing the user resulted in the following: Recoverable fatal error: Argument 5 passed to Drupal\Core\Field\WidgetBase::__construct() must be of the type array, null given, called in /var/www/tag1/eight/drupal/core/lib/Drupal/Core/Field/WidgetPluginManager.php on line 130 and defined in Drupal\Core\Field\WidgetBase->__construct() (line 55 of ore/lib/Drupal/Core/Field/WidgetBase.php). Notice: Undefined index: third_party_settings in Drupal\Core\Field\WidgetPluginManager->createInstance() (line 130 of core/lib/Drupal/Core/Field/WidgetPluginManager.php).
Solution None yet. There is work in progress on profile fields. I opted not to migrate the user profiles since we’ll be doing extensive work on them anyway.

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

Migration d6_node d6_node_revision
Problem Node authors weren’t being set
Solution Patch:

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!





Site comments



- d6_block
- d6_block_content_body_field
- d6_block_content_type
- d6_custom_block

Blocks need to be placed within the theme, but migrate fine.



- d6_cck_field_revision
- d6_cck_field_values
- d6_field
- d6_field_formatter_settings
- d6_field_instance
- d6_field_instance_widget_settings

No visible problems.



- d6_comment
- d6_comment_entity_display
- d6_comment_entity_form_display
- d6_comment_entity_form_display_subject
- d6_comment_field
- d6_comment_field_instance
- d6_comment_type

These migrated seamlessly.



- d6_file
- d6_file_settings

Files are a work-in-progress. See


Input Filters

- d6_filter_format

These migrated fine, but I preferred to update to the filter formats provided with Drupal 8.



- d6_menu
- d6_menu_settings
- d6_menu_links

Hierarchical menu links were problematic. Single level menus migrated successfully.



- d6_node
- d6_node_revision
- d6_node_setting_promote
- d6_node_setting_status
- d6_node_setting_sticky
- d6_node_settings
- d6_node_type

Nodes migrated successfully with the small exception of the labels for Promote to Front Page and Sticky.


System Settings

- d6_syslog_settings
- d6_system_cron
- d6_system_file
- d6_system_filter
- d6_system_image
- d6_system_image_gd
- d6_system_logging
- d6_system_maintenance
- d6_system_performance
- d6_system_rss
- d6_system_site




- d6_taxonomy_settings
- d6_taxonomy_term
- d6_taxonomy_vocabulary
- d6_term_node
- d6_term_node_revision
- d6_vocabulary_entity_display
- d6_vocabulary_entity_form_display
- d6_vocabulary_field
- d6_vocabulary_field_instance

Vocabularies and terms migrated. Freetag terms weren’t associated with their nodes.



- d6_upload
- d6_upload_entity_display
- d6_upload_entity_form_display
- d6_upload_field
- d6_upload_field_instance

Uploads didn’t migrate.



- d6_user
- d6_user_contact_settings
- d6_user_mail
- d6_user_picture_entity_display
- d6_user_picture_entity_form_display
- d6_user_picture_field
- d6_user_picture_field_instance
- d6_user_picture_file
- d6_user_profile_entity_display
- d6_user_profile_entity_form_display
- d6_user_profile_field
- d6_user_profile_field_instance
- d6_user_role
- d6_user_settings
- d6_profile_values

User profile fields and pictures didn’t migrate properly, but users did.



- d6_action_settings
- d6_date_formats
- d6_dblog_settings
- d6_locale_settings
- d6_search_page
- d6_search_settings
- d6_simpletest_settings
- d6_statistics_settings
- d6_text_settings
- d6_update_settings
- d6_url_alias
- d6_view_modes

These either migrated successfully or weren’t significant values on the site


Not run

#- d6_aggregator_feed
#- d6_aggregator_item
#- d6_aggregator_settings
#- d6_book
#- d6_book_settings
#- d6_forum_settings
#- d6_contact_category
#- d6_contact_settings

There was no need to run these