Problem/Motivation

In #2800605: Warn/inform users when the hosting environment has a too low limit of APCU cache we did not consider that ByteSizeMarkup::create returns a translated string representation of the size.

Steps to reproduce

1. Need to make sure that PHP compile with APCu support and APCu cache was enabled
2. If site has only English language, needs to add another language, Russian or example.
3. Needs to set non-English language to admin user and go to site Status Report

Proposed resolution

Force set English for ByteSizeMarkup::create function

Result

Before patch:

Image may be NSFW.
Clik here to view.

After patch:

Image may be NSFW.
Clik here to view.

Problem/Motivation

Drupal core provides an "underlying API" with field migration plugins to specify a D6 / D7 → D9 formatter and widget plugin ID mapping. The problem is that this feature is accessible only with a field migration plugin (and that is field type specific):

If a module has only formatters or widgets (but these are extending a field type which is not provided by the module), then for these modules, it is nearly impossible to tell Drupal's migration system that a specific Drupal 7 field formatter ID should be mapped to something else for Drupal 9.

For example, the Multiple Selects module would have a trivial migration path, but due to the issue described above, this is currently impossible to automate.

See #3188284: [PP-3] Migration support.

Proposed resolution

Create a new plugin ID mapper process plugin, move the related mapping logic into this plugin, and provide a hook for contribs to specify their plugin ID mapping.

Related 'logic':

• MigrateFieldInterface::alterFieldInstanceMigration()
• MigrateFieldInterface::getFieldFormatterType()
• MigrateFieldInterface::getFieldFormatterMap()
• MigrateFieldInterface::alterFieldWidgetMigration()
• MigrateFieldInterface::getFieldWidgetType()
• MigrateFieldInterface::getFieldWidgetMap()

Remaining tasks

• Add #3204212: Convert remaining widget and formatter type migrations to MigrateField plugins to core.
• Patch with the new plugin.
• Use the new plugin in field migrations: assert that the changes are BC-safe. (This depends on #3204212: Convert remaining widget and formatter type migrations to MigrateField plugins – but it works for me).
• Add additional test coverage.
• Document the new hooks (where?..).
• Create a change record.— see https://www.drupal.org/node/3208917

User interface changes

Post-migration, my D7 content type that was migrated will now have the enhanced UX (with the appropriate widgets) that I'm used to as a site owner:

Before

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

API changes

Two new hooks:

1. hook_field_migration_field_formatter_info()
2. hook_field_migration_field_widget_info()

Data model changes

Release notes snippet

Problem/Motivation

Identified while working on Bean Migrate:

The block config migration destination plugin EntityBlock forces every block config migrations to calculate the plugin and theme destination properties, because the destination ID is returned by a Storage::loadByProperties() call.

This is a big overhead for translation migrations, because:

• The plugin and the themeneed to be re-calculated due to the destination plugin's logic.
• The static map of the plugin property should be kept in sync, but for no reason, because:
• Right now, the block plugin ID uses a lookup– but this isn't used at all, due to the destination plugin.

Proposed resolution

For block config translation migrations (at least) it should be possible to specify only the destination block content ID and the actual property translation.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When I run
drush migrate:import upgrade_d7_field_instance --migrate-debug
upgrade_d7_field_instance yml is generated by migrate upgrade without any modification,
I have the following errors:

In DiscoveryTrait.php line 53:

  The "" plugin does not exist. Valid plugin IDs for Drupal\migrate\Plugin\Mi  
  gratePluginManager are: addressfield, block_plugin_id, block_region, block_  
  settings, block_theme, block_visibility, field_type, process_field, field_f  
  ormatter_settings_defaults, d6_field_instance_defaults, d6_field_instance_o  
  ption_translation, d6_field_field_settings, field_instance_widget_settings,  
   d6_field_option_translation, field_settings, d6_field_type_defaults, field  
  _bundle, d7_field_instance_defaults, d7_field_instance_option_translation,   
  d7_field_instance_settings, d7_field_option_translation, d7_field_settings,  
   d7_field_type_defaults, d7_field_permission_settings, d6_field_file, file_  
  uri, filter_id, filter_settings, filter_format_permission, geofield_d7d8, g  
  eofield_field_settings, geofield_latlon, geofield_wkt, google_analytics_vis  
  ibility_pages, google_analytics_visibility_roles, d6_imagecache_actions, in  
  line_entity_form_field_instance_settings, field_link, link_options, link_ur  
  i, d6_nodewords_entities, d7_metatag_entities, array_build, callback, conca  
  t, default_value, download, entity_exists, explode, extract, file_copy, fla  
  tten, format_date, get, log, machine_name, make_unique_entity_field, menu_l  
  ink_parent, migration_lookup, null_coalesce, route, skip_on_empty, skip_row  
  _if_not_set, static_map, sub_process, substr, urlencode, debug, node_comple  
  te_node_lookup, node_complete_node_revision_lookup, node_complete_node_tran  
  slation_lookup, array_pop, array_shift, default_entity_value, dom, dom_appl  
  y_styles, dom_migration_lookup, dom_remove, dom_select, dom_str_replace, en  
  tity_generate, entity_lookup, entity_value, file_blob, gate, merge, multipl  
  e_values, service, single_value, skip_on_value, str_replace, transliteratio  
  n, transpose, node_update_7008, path_set_translated, d6_url_alias_language,  
   d6_path_redirect, d7_path_redirect, d7_redirect_source_query, search_confi  
  guration_rankings, system_update_7000, timezone, forum_vocabulary, convert_  
  tokens, profile_field_settings, user_langcode, user_update_8002, d6_profile  
  _field_option_translation, user_update_7002, field_collection_field_instanc  
  e_settings, field_collection_field_settings, paragraphs_field_instance_sett  
  ings, paragraphs_field_settings, paragraphs_lookup, paragraphs_process_on_v  
  alue

Steps to reproduce

There can be various reasons like core or contrib module bugs or migration misconfigurations causing this error message.
The problem is, that the error message is useless as it contains no helpful information WHAT went wrong WHERE.

Proposed resolution

Add more details to the error message, so the message is helpful and allows finding the root cause of the error.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

When you run a migration using Migrate Upgrade, which leverages core's Migrate Drupal system, it runs the block migration before the menu migration, resulting in warnings that blocks from the menu system cannot be found, e.g.:

[warning] The "system_menu_block:secondary-menu" was not found

Steps to reproduce

• Use Migrate Upgrade to prepare a D7 migration to D8 or D9 where menu blocks were displayed in a region.
• Run the migration.

Proposed resolution

List the d7_menu migration as an optional dependency on d7_block.

Remaining tasks

• Confirm the problem.
• Provide a patch with the fix.
• Test coverage.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

TBD

Mapping field_formatters to migrate from D7 to D9

in Drupal 7 I've custom field_formatters. In Drupal 9 I've setup a custom module to define the corresponding formatters with the same names as the had before. Unfortunately I can't find any documentation to setup a migration yml-file to map the old formatters to the new once. Where can I find an example? Would appreciate a helpful hint.

Problem/Motivation

In d6_field_formatter_settings, there is the following check.

process:
  # We skip field types that don't exist because they weren't migrated by the
  # field migration.
  field_type_exists:
    -
      plugin: migration_lookup
      migration: d6_field
      source:
        - field_name
    -
      plugin: skip_on_empty
      method: row
    -
      plugin: extract
      index:
        - 1

This fails to properly skip the processing the row. If the migration_lookup does not finds a record for field_name, it returns an array containing two null values. Such array fails the skip_on_empty validation. A similar check is part of d6_field_instance and d6_field_instance_widget_settings. In both cases, the order of the skip_on_empty and extract plugins is inverted. That takes care of properly skipping the row when the migration_lookup does not return a migrated record.

d6_field_formatter_settings inverted the process plugins in #2560671: The Migration process plugin should not skip rows.

Steps to reproduce

On a D6 migration that skipped field storage, run the field formatter settings migration.

Proposed resolution

Invert the order of the skip_on_empty and extract plugins to be aligned with d6_field_instance and d6_field_instance_widget_settings.

Remaining tasks

Review patch.
Write tests.

User interface changes

None.

API changes

Not sure if the migration plugin is a public API.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

I want to migrate a Drupal 6 site to Drupal 9 with migrate_drupal module, but I get this error:

The website encountered an unexpected error. Please try again later.
TypeError: in_array(): Argument #2 ($haystack) must be of type array, string given in in_array() (line 106 of core/modules/node/src/Plugin/migrate/source/d7/NodeType.php).

Steps to reproduce

I fill the form in upgrade/credentials with this options:

• Drupal version: Drupal 6
• Database type: MariaDB
• DatabaseHost: mariadb (I work with wodby 4 drupal dockers so I use the service name)
• Databasename: Drupal6 (with capital letter)
• User: drupal
• password: drupal.
• document root: https://project_domain.es

Problem/Motivation

The block migration does not seem to support migrating content type visibility settings:

Image may be NSFW.
Clik here to view.

Any chance this can be supported?

Steps to reproduce

1. On a Drupal 7 site, configure a block to show up only on specific content types (see screenshot above)
2. Migrate the site to Drupal 10 by executing d7_block.yml

Expected result: the block is still configured to show up on specific content types in Drupal 10

Actual result: the visibility criteria are not migrated

Proposed resolution

Attached is a proposed patch that adds support for this.

Problem/Motivation

The Inline form error of a required, limited multiple file widget is rendered twice in some themes (Olivero, Stark, Umami but notably, not in Claro):

1. in the HTML5 details content that wraps the actual managed_file widget, and
2. next to the file input.

Steps to reproduce

1. With an enabled file and inline_form_errors module, create a limited, multiple file field for a fieldable entity (block, term, node, contact form...) and set it mandatory.
2. Use the default file upload widget that is provided by the file module.
3. Visit the entity form, leave the new file field empty, and hit save.

Image may be NSFW.
Clik here to view.Image may be NSFW.
Clik here to view.

Proposed resolution

Remaining tasks

User interface changes

Problem/Motivation

The d7_field_instance migration does not have a mechanism to skip migrating field instances for fields whose storage was not migrated by d7_field. Both d7_field_instance_widget_settings and d7_field_formatter_settings have this check at the start of their process section.

process:
  # We skip field types that don't exist because they weren't migrated by the
  # field migration.
  field_type_exists:
    -
      plugin: migration_lookup
      migration: d7_field
      source:
        - field_name
        - entity_type
    -
      plugin: extract
      index:
        - 0
    -
      plugin: skip_on_empty
      method: row

A similar check is present is also present for Drupal 6 migrations including d6_field_instance, d6_field_formatter_settings, and d6_field_instance_widget_settings to not migrate fields that were not migrated by d6_field.

D6 check was added in #2121299: Migrate in Core: Drupal 6 to Drupal 8. D7 related code was added in #2416765: Migrate Drupal 7 Field/Instance/View mode settings.

Having this check in d7_field_instance would be useful to avoid errors that are thrown for attempting to migrate the field instance configuration of a field that does not exist.

Steps to reproduce

1. In a Drupal 7 site, have a url field attached to the article content type.
2. In a Drupal 10 site, with no contrib modules installed, run an automated upgrade provided by `migrate_drupal` and `migrate_drupal_ui` modules.
3. See the recent log messages report where there are errors about trying to migrate the instance of a field type url which does not exist.

For the record, the migrate_url2link module provides an upgrade path from D7 url field to D10 link field, but that is outside the scope of this feature request.

Proposed resolution

Add the same check from d7_field_formatter_settings and d7_field_instance_widget_settings to d7_field_instance.

Remaining tasks

• Review patch.
• Write tests.

User interface changes

None.

API changes

Not sure if the migration plugin is a public API.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

When we have a d7 to d8/d9 comment migration where the created datetime is repeated, and we set a batch_size, migrate adds a range to the query that gets the source data. Apparently, that query is also orded by created property, and this makes the range not able to manage which entities with an identical created datetime have been migrated and which have not.

Steps to reproduce

- Build a d7 to d9 comment migration, where some of the source comments have the exact same 'created' property.
- Add an small batch_size to the migration yml.
- Launch the migration and check if all comments where migrated or not.
- If it fails, you should see that some comments are still in the Unprocessed column.

Proposed resolution

Change the query orderBy from created to cid. In this way we respect the primary key, and also we do not suffer from the problem of ranges in the queries. Furthermore, ordering the comments by cid seems more coherent and correct.

Problem/Motivation

The web/core/modules/node/src/Plugin/migrate/source/d6/Node.php did not get the constructor updated to use ModuleHandlerInterface instead of ModuleHandler

Steps to reproduce

This is likely triggered by the hook_event_dispatcher module being enabled as well.

Run migration and receive error:
[Exec] TypeError: Drupal\node\Plugin\migrate\source\d6\Node::__construct(): Argument #7 ($module_handler) must be of type Drupal\Core\Extension\ModuleHandler, Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler given, called in /code/web/modules/legacy/shop6_migrate/src/Plugin/migrate/source/ErpCore.php on line 38 in Drupal\node\Plugin\migrate\source\d6\Node->__construct() (line 81 of /code/web/core/modules/node/src/Plugin/migrate/source/d6/Node.php).

Proposed resolution

Update the constructor

Problem/Motivation

Trying to migrate any migrations that depend on "upgrade_d7_field_instance" will fail if in the original database duplicate combined field_name entries ('entity', 'bundle', 'field_name') exist.

For us, we tried migrating "upgrade_d7_field_instance_widget_settings" after migrating "upgrade_d7_field_instance". The following error appeared, after trying to migrate:

[error] Migration upgrade_d7_field_instance_widget_settings did not meet the requirements. Missing migrations upgrade_d7_field_instance. requirements: upgrade_d7_field_instance.

After a bit of debugging, we found out, that the migration fails inside the health check for upgrade_d7_field_instance inside "Drupal\migrate\Plugin\Migration.php""allRowsProcessed()". The problem: The source count is higher, then the processed count, thus failing.

// Output: "182|181"
var_dump($source_count . '|' . $processed_count);

After digging inside D7's "field_config_instance" db table and comparing it to the "migrate_map_upgrade_d7_field_instance" migration mapping table, we found a duplicate combined field_name entry ('entity', 'bundle', 'field_name').

After deleting the older entry, the migration worked as expected again.

Drupal 7 allows duplicate combined field_name_bundle entries, because of a faulty index setting:
Image may be NSFW.
Clik here to view.

The "field_name_bundle" key instead should be unique and add the "delete" row to be correct.

Steps to reproduce

Proposed resolution

Throw a more meaningful error like, [error] Migration upgrade_d7_field_instance_widget_settings did not meet the requirements. Migration upgrade_d7_field_instance has duplicate field_name_bundle entries, please delete the duplicate entries or something along those lines.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Postponed on

• #3039240: Create a way to declare a plugin as deprecated
• #2746541: Migrate D6 and D7 node revision translations to D8

Problem/Motivation

#2746541: Migrate D6 and D7 node revision translations to D8 introduced a new better way to migrate node content that support revisions and translations migrated in the right order. It was too late to remove the old solution before Drupal 9 but we should not have both solutions in Drupal 10.

Proposed resolution

We should deprecate the old classic node migration plugin before Drupal 10.

Remaining tasks

Do it.

User interface changes

None.

API changes

Classic node migrations will be deprecated.

Data model changes

None.

Release notes snippet

Classic node migrations are deprecated in Drupal 9 for removal in Drupal 10.

Problem/Motivation

\Drupal\Tests\rest\Functional\EntityResource\XmlEntityNormalizationQuirksTrait skips both testPatch and testPost but this occurs after installing Drupal. This can cost 15 seconds of compute time per skipped test... see page 169 of https://git.drupalcode.org/project/drupal/-/pipelines/227006/test_report...

Steps to reproduce

Run ./vendor/bin/phpunit core/modules/comment/tests/src/Functional/Rest/CommentXmlBasicAuthTest.php --filter testPostDxWithoutCriticalBaseFields

Proposed resolution

Use attributes to add methods run before a test to mark it skipped if we are skipping based on name.

Running ./vendor/bin/phpunit core/modules/comment/tests/src/Functional/Rest/CommentXmlBasicAuthTest.php --filter testPostDxWithoutCriticalBaseFields before takes Time: 00:08.349, Memory: 10.00 MB and after takes Time: 00:00.463, Memory: 10.00 MB

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

This is a follow-up to #2321609: Provide a helpful message in case requirements are not met, see this comment from @dawehner:

Given that the requirements for example are in english anyway did you thought of dropping the translatablity here? For sure this would be out of scope, just asking.

Here is a typical usage of RequirementsException:
throw new RequirementsException('The module comment is not enabled in the source site');

This message is always in English, hence it doesn't make to translate a string, where this message is being injected.

It was discovered while looking at #3254986: Remove requirements array from RequirementsException message, so let's wait until it lands.

Proposed resolution

Remove translate function (t) from this message:

$this->message->display(
        $this->t(
          'Migration @id did not meet the requirements. @message @requirements',
          [
            '@id' => $this->migration->id(),
            '@message' => $e->getMessage(),
            '@requirements' => $e->getRequirementsString(),
          ]
        ),
        'error'
      );

Remaining tasks

todo

Problem/Motivation

Wrong langcode in node table due to wrong Query in d7_node_complete Source Plugin.

Steps to reproduce

1. Needs Drupal 7 site with:
   • entity translation enabled
   • language enabled: en, de, it
   • at least one existing node with original language English and translations in Italian and German
2. Needs Drupal 9 site with translation enabled.
3. Enable modules (migrate_plus, migrate, migrate_tools, migrate_drupal, migrate_drupal_ui, drupal_upgrade) in Drupal 9 site
4. Make sure a proper Drupal 7 DB configuration should be exists in settings.php file.
5. Run migrations.

The node_field_data.langcode and node_field_data.content_translation_source fields have the correct value.
The node.langcode field has the wrong value set to "de" (instead of "en")

Proposed resolution

Change the orderBy and use etr.source instead of etr.language so that the first content created is that with the original language

Remaining tasks

In the next comment the proposed patch

Problem/Motivation

Migration plugins throughout core and contrib keep having to do this sort of thing:

$delimiter = isset($this->configuration['delimiter']) ? $this->configuration['delimiter'] : '';

Proposed resolution

Implementing https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Plug... means that plugins can define default values for any configuration in defaultConfiguration().

The result is:
- better DX as you don't have to keep checking array values in $this->configuration are defined
- better DX as the default value for something in $this->configuration is in one place only
- better DX as there's a place where all the configuration options for the class are listed (well the class docs should have that too... but it nudges modules that are lax on docs towards listing them)

This can be done in SourcePluginBase, ProcessPluginBase, & DestinationBase.

To facilitate this, create an @internal ConfigurablePluginTrait in the migrate module to use with migration base plugins. There is discussion to do this in the core plugin system in #2852463: Create a trait and base class to implement \Drupal\Component\Plugin\ConfigurableInterface, however for the migration plugins we want to prevent use of the calculateDependencies method from the interface, as these plugins are not configurations and do not use dependencies. Depending on the outcome of that issue and #2946122: Deprecate ConfigurablePluginInterface and replace with an interface that doesn't extend DependentPluginInterface there may be a future core plugin library solution to address this, and refactoring the migration plugins around a module trait now will make that process much easier, and provide immediate benefits in cleaning up the plugin code. Making the trait @internal will make sure we can refactor around any potential plugin library solution in the future.

Remaining tasks

Postponed on #2852463: Create a trait and base class to implement \Drupal\Component\Plugin\ConfigurableInterface
Create an @internal ConfigurablePluginTrait use with migration base plugins.
Implement ConfigurablePluginInterface in the migration base classes and use the trait. Remove the interface from any core classes that extend these base classes.
Remove unused calculateDependencies() methods from core migration plugins as these plugins are not config entities.
Commit it!
As a follow up to this issue, refactor plugins to set default configurations and remove unnecessary isset() calls. @see #2995393: Refactor migrations plugins that now implement ConfigurablePluginInterface

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

When a view with an exposed form (or another form using GET as #method) is being rendered using a lazy builder and that form throws a EnforcedResponseException (for example when the exposed form reset button is pressed), big pipe does not handle this exception; the redirect will not happen.

Steps to reproduce

Using Views Reference Field and a view with exposed filters and ajax:

1. Enable Views
2. Install module BEF
3. Create a view with some exposed filters, enable ajax, enable BEF and activate showing the Reset button.
4. Install module Views Reference Field (> 8.x-2.0-beta4)
5. Create a content type with a field View Reference and configure it to allow selecting the view created.
6. Add a node and select the view
7. View the page and use some exposed filters, then when the reset button appears, press it

It will reload the page showing an error instead of the view.

Proposed resolution

Have Big Pipe catch the EnforcedResponseException and send a redirect response ajax command.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Big Pipe now handles redirect responses in GET requests.