The Drupal 6 to 8 Upgrade Challenge - Part 3
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 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
Issue/s
https://www.drupal.org/node/2369401
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.
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: https://www.drupal.org/node/2372785#comment-9328703
Issue/s
https://www.drupal.org/node/2372785
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
Issue/s
https://www.drupal.org/node/2372837 https://www.drupal.org/node/2232477
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
Issue/s
https://www.drupal.org/node/2397339
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 node.page.promote already exists. (drupal/core/lib/Drupal/Core/Entity/EntityStorageBase.php:391)
Solution
Unsure
Issue/s
Expand FieldConfig/BaseFieldOverride with methods https://www.drupal.org/node/2030637
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
Issue/s
https://www.drupal.org/node/2393531
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';
Issue/s
https://www.drupal.org/node/2226455
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.
Issue/s
https://www.drupal.org/node/2394615 https://www.drupal.org/node/2394567
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.
Migration
d6_node d6_node_revision
Problem
Node authors weren’t being set
Solution
Patch: https://www.drupal.org/node/2376141#comment-9453157
Issue/s
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
Group
Migrations
Site comments
+
Blocks
- 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.
+
Fields
- 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.
+
Comments
- 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.
x
Files
- 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.
o
Menus
- d6_menu
- d6_menu_settings
- d6_menu_links
Hierarchical menu links were problematic. Single level menus migrated successfully.
+
Nodes
- 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
o
Taxonomies
- 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.
x
Uploads
- d6_upload
- d6_upload_entity_display
- d6_upload_entity_form_display
- d6_upload_field
- d6_upload_field_instance
Uploads didn’t migrate.
o
Users
- 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.
+
Miscellaneous
- 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
Images: