Known issues when upgrading from Drupal 6 or 7 to Drupal 8

Last updated on
15 December 2017

The following is a list of various items that may require special attention when migrating from:

Drupal 6 to 8

Aggregator Categories

Drupal 8 no longer has the concept of aggregator categories and therefore they're not migrated to Drupal 8.

Allowed protocols

Drupal 8 now stores the protocols in the "filter_protocols" container parameter, so in case you had changed the variable "filter_allowed_protocols", enter it into your services.yml file.

Date formats

Only the default, short, medium and long formats are migrated. All other formats default to the fallback format and need to be reconfigured after migration. (#2820490: FormatDate process plugin)

Fields missing on the edit form or the view page

One other thing that may be a point of confusion is when you run a migration that seems to be successful but afterward you don't see your fields on the edit form. Go to the Content Types administration page and check the Manage Form Display tab for each content type. The fields added by the upgrade may be hidden on the edit form. If so, drag them up to be visible. Similarly, if they don't appear in the node view, the fields added by Migrate may have gotten hidden on the Manage Display tab and you may need to make them visible there. In migrating custom fields on an entity, the the Migrate Plus module could help.

Homepage loads and theme is broken

When running migrations, sometimes the page is white and only loads a few items. Basically, it looks like a broken theme. Visiting /user and returning to the home page normally resolves it.

Menu UI

The menu_primary_links_source and menu_secondary_links_source variables are not migrated, because they do not have counterparts in Drupal 8.

Modules and themes

Before starting the migration, new modules and themes should be enabled, as well as the admin theme (if there is one) set.

Node content types

Default configuration in Drupal 6 has Story and Page content types. Drupal 8 default content types are called Article and Basic Page (which has a machine name 'page' just like in Drupal 6).

  • Migration will map Drupal 6 Page to Drupal 8 Page content type because the machine names of these content types match.
  • Migration will create the Story content type to Drupal 8. You might want to delete the Drupal 8 Article content type if you don't need it. For further details, please refer to #2236289: Migrating "story" nodes from D6 creates new content type in D8.

Node translations

In Drupal 6, node translations were stored in different nodes while in Drupal 8 they are now combined with their source language nodes. The migration system will do the merging of the node translations, but that means that some links might now point to nodes that do not exist anymore. See #2746527: [META] Handle data related to Drupal 6 and 7 node translations with different IDs for further details.

Note that revisions of translated nodes are not yet migrated. See #2746541: Migrate D6 and D7 node revision translations to D8 for further details.

Profile categories

Fields grouped by the Profile module in Drupal 6 will not be grouped in Drupal 8.

Profile field (list selection)

The "allowed values" setting of the resulting field in Drupal 8 will be a combination of all selected user values and the current allowed values in Drupal 6 and not just the allowed values in Drupal 6.

Statistics

The access log settings and non-i18n statistics data is migrated. Consolidation of i18n statistics data is not yet migrated. See #2930101: i18n / statistics - node counter not updated for translations.

Text/Input formats

Filter formats not recognized by Drupal 8 will be migrated as filter_null, a filter that simply returns an empty string. This means that any Input format using a unknown filter format won't display fields' content, although the content is in the database. It may be confusing. See #2618332: Better handle replacement of missing filters with filter_null and #2630578: Formats duplicated in D6 upgrade for ways to improve this.

Filter formats not recognized by Drupal 8 include the infamous PHP code filter, and any other filter provided by a contrib module that is not available in your Drupal 8 installation.

The PHP filter is not supported in Drupal 8 core -- it's very bad practice, but you can use the PHP module for that if you really must.

To repair this situation, you have several alternatives:

  • Check if the modules providing the filters have a Drupal 8 version and install them
  • Edit and save the affected input formats. This will remove the reference to format_null, and the contents will start showing. Note that since the original filter doesn't exist, contents are not being filtered and unreplaced tokens may be shown, or even the site can be exposed to any security issue
  • Edit the contents and change to another input format. This suffers the same problems as the previous point

Time Zones and Dates

Drupal 6 uses a time zone offset to compute local time. Drupal 7 and Drupal 8 use a time zone name. Unfortunately, the php function timezone_name_from_abbr() which converts the offset to time zone names will produce different time zone names depending upon whether or not daylight savings time is turned on or not on your server. For example, the time offset of 3600 converts to Europe/Paris if daylight saving time is off and Europe/London if the daylight saving time in on. The migration is set to ignore daylight saving time. Depending on your server configuration, the Drupal 8 time zone setting might be incorrect after migration. (#2353679: D6->D8 Migration missing variable: date_default_timezone)

In time zones which use Daylight Saving Time a date could be interpreted differently by Drupal 8 compared with Drupal 6. For example, if the time is around midnight, the date could be seen as a different day. This causes problems especially if date tokens are used to build paths (e.g. URL aliases, file field paths). Two possible solutions are shown in #2926421: Handle dates incosistencies between D6 and D8.

URL Aliases

When migrating URL aliases for a language that is not enabled on the new Drupal 8 site, none of the aliases will work until you enable the language on the new Drupal 8 website.

Views

Views are not yet migrated, you will need to create the views in Drupal 8 manually. For further details, please refer to #2500547: Upgrade path for Views from Drupal 6 and 7

Who's online block

The User activity settings are not migrated. This needs to be manually edited in the relevant View under filters / access. (#2169327: Migrate the User Activity block setting).

Drupal 7 to 8

Blocked IPs

The id column from Drupal 7's ban_ip table is not migrated.

Comment types

Drupal 7 allows the comments to have different fields on different content types. Typically the comments have Author, Subject and Comment body fields. Because the different D7 comments can have different fields, the migrations will create separate D8 comment types for each content type:

  • Content type Foo will have a comment type comment_node_foo
  • Content type Bar will have a comment type comment_node_bar

The only exception to this is Forum comments. When D8 Forum module is enabled, comment type comment_forum is automatically created. The D7 Forum comments are migrated to this comment type.

Important note: Drupal 8 Standard installation profile and Article content type

If your Drupal 8 site was installed using the Standard installation profile you will have a content type called Article.

  • This content type will come with a comment field called comment.
  • The migration system can not assume that the D8 site was installed using the Standard installation profile. Therefore a comment type comment_node_article will be created and comments of the D7 Article content type will be migrated to this comment type.

As a result, your Article content type will now have two comment fields:

  • comment which came from D8 Standard installation profile and is not used
  • comment_node_article which the migration system created

You most probably don't want to have two comment fields on the Article content type so you need to manually delete the comment comment field from Article (admin/structure/types/manage/article/fields). After you've done this, you may also want to delete the comment comment type (admin/structure/comment) if you're not using the comment comment type anywhere else.

It is recommended that the unnecessary comment field is removed from the Article content type before running the migrations because Drupal 8 core currently has a bug related to comment field deletion, see #2906470: Orphan comments and entries in comment_entity_statistics after comment field instance has been deleted.

Menu UI

The menu_primary_links_source and menu_secondary_links_source variables not migrated, because they do not have counterparts in Drupal 8.

Node translations

In Drupal 7, node translations were stored in different nodes while in Drupal 8 they are now combined with their source language nodes. The migration system will do the merging of the node translations, but that means that some links might now point to nodes that do not exist anymore. See #2746527: [META] Handle data related to Drupal 6 and 7 node translations with different IDs for further details.

Note that revisions of translated nodes are not yet migrated. See #2746541: Migrate D6 and D7 node revision translations to D8 for further details.

PHP Code

Filter formats not recognized by Drupal 8 will be migrated as filter_null, a filter that simply returns an empty string. This means that any Input format using a unknown filter format won't display fields' content, although the content is in the database. It may be confusing. See #2618332: Better handle replacement of missing filters with filter_null and #2630578: Formats duplicated in D6 upgrade for ways to improve this.

Filter formats not recognized by Drupal 8 include the infamous PHP code filter, and any other filter provided by a contrib module that is not available in your Drupal 8 installation.

The PHP filter is not supported in Drupal 8 core -- it's very bad practice, but you can use the PHP module for that if you really must.

To repair this situation, you have several alternatives:

  • Check if the modules providing the filters have a Drupal 8 version and install them
  • Edit and save the affected input formats. This will remove the reference to format_null, and the contents will start showing. Note that since the original filter doesn't exist, contents are not being filtered and unreplaced tokens may be shown, or even the site can be exposed to any security issue
  • Edit the contents and change to another input format. This suffers the same problems as the previous point

Plain Text Fields #

Conflicting text processing settings in Drupal 7

In Drupal 7, the text processing settings are defined on Field instance settings. In other words, the same field can be used on two (or more) content types and the text processing settings can be Plain text on one content type and Filtered text on another.

Drupal 8 has separate field storage types Text (plain) and Text (formatted). There's also Text (plain, long) and Text (formatted, long). The important part here is that this selection is done on field storage level. In other words, the plain / formatted selection can't be changed per content type. 

The migration system makes no assumptions. If the migration system detects conflicting text processing settings, these fields are skipped with a log message. The site builder has two options:

1. The text processing settings can be altered on a Drupal 7 site so that all content types that use the text field have the same text processing setting.

  • Pay attention when selecting which way to harmonize the processing settings to avoid possible cross site scripting (XSS) security issues. 
  • If your field was set to Plain text in Drupal 7 and untrusted users were able to post content to this field, it is possible that the fields contain malicious input. This was not leading to an XSS on your Drupal 7 site because the field was set to Plain text and thus the malicious input was not executed. If you now change the field now to Filtered text, make sure that the Text format is not Full HTML or similar which would allow the malicious input.

2. If you need to have two different formatting settings in Drupal 8, you need to develop a custom migration which splits the Drupal 7 fields into two separate Drupal 8 fields. More information on customizing the migrations when upgrading to Drupal 8.

Text with summary + plain text formatting setting in Drupal 7

Drupal 7 has a field type Long text and summary. The corresponding field type in Drupal 8 is Text (formatted, long, with summary). In Drupal 7 it is possible to configure on field instance settings that the text processing is Plain text. The Text (formatted, long, with summary) fields are always formatted text in Drupal 8.

The migration system makes no assumptions. If the migration system detects a Long text and summary field with Plain text formatting settings, the field is skipped with a log message. The site builder has the same two options as above:

1. Change the field formatting setting from Plain text to Filtered text in Drupal 7.

  • The same remark described above about cross site scripting applies. 

2. Create a custom migration path and build your own logic how you want to migrate the fields to Drupal 8. More information on customizing the migrations when upgrading to Drupal 8.

Statistics

The access log settings and non-i18n statistics data is migrated. Consolidation of i18n statistics data is not yet migrated. See #2930101: i18n / statistics - node counter not updated for translations.

Views

Views are not yet migrated, you will need to create the views in Drupal 8 manually. For further details, please refer to #2500547: Upgrade path for Views from Drupal 6 and 7

Potential ID Conflicts (Drupal 6 or 7 to Drupal 8)

The problem

As described on the preparing an upgrade page, the Drupal 8 site should be completely empty when the upgrade process is performed. The migration process preserves the IDs of the source site when importing them into a Drupal 8 site. If content has been created on the Drupal 8 site before the upgrade (e.g. node with nid 1), it is likely that the IDs will conflict. 

Work is currently ongoing to enable automatic detection of potential ID conflicts and warn the user, see #2876085: Before upgrading, audit for potential ID conflicts. At the moment site administrators should carefully consider potential conflicts by themselves. If ID conflicts are not treated with care, content or other entity items such as taxonomy terms and files can be overwritten causing data loss. It is also possible that the referencing entities are damaged, for example content can be associated with incorrect taxonomy term.

Scenarios that might lead to ID conflicts

  • The Drupal 8 destination site had already been in use at the time of the upgrade and content had already been created.
  • The initial migration was completed. After the initial migration content or other entities were created in both the source and the destination sites. When the updated / newly created content was migrated from the source site, the IDs may conflict with the content that was created in Drupal 8 site.
  • The Drupal 8 destination was at a clean state, but a contributed or custom modules might have added data for their own use when they were enabled in Drupal 8. For example, the Drupal 8 core Forum module creates a taxonomy term for its General Discussion category and that will normally get ID #1 in a fresh install. If the source data contains taxonomy term with ID 1, it will overwrite the name of the forum's General Discussion category.
  • The source might have data that do not come with an ID, but the destination requires them to have an ID. For example, Drupal 6 handles user pictures as unmanaged files without an ID but Drupal 8 destination requires them to have an ID. Managed file fields with IDs will be created during the migration and these may conflict with files that are yet to be migrated.
  • Possible ID conflicts with translations are not automatically detected.
    • If you are executing a complete upgrade at once and you are performing the upgrade to an empty Drupal 8 site, everything should be OK.
    • If you are executing a partial migration after an initial upgrade AND you have added translations on your Drupal 8 site before migrating the updated / newly created content, the second migration may overwrite the translation made on Drupal 8 site. 

Solutions

Custom migration for the conflicting items

It is possible to customize the migration for the problematic content so that new IDs are created for the problematic items. Note that this will affect their internal path and possibly their public URLs. Special care should be taken to correct any references to the changed entities.

Manipulate auto-increment values

When the Drupal 8 destination does not have any conflicting data but the migration process may generate conflicts, it is possible to manipulate the AUTO_INCREMENT value on the Drupal 8 database tables so that the IDs of the created entities do not fall within the range of other migrated entities. The migration of user pictures described above is an example of this.

Accept that data may be overwritten

It is always possible to go ahead with performing the migration. This is probably not the desired solution in many cases as it may lead to data loss.