[PP-3] Migration support

I tested this manually, on a real-world site. This does not work at all? 😅

1. +++ b/src/Plugin/migrate/field/d7/MultipleSelectField.php
   @@ -0,0 +1,31 @@
   + *   type_map = {
   + *     "list_text" = "list_string",
   + *   },
   

   Why only these two types? It supports much more!

2. +++ b/src/Plugin/migrate/field/d7/MultipleSelectField.php
   @@ -0,0 +1,31 @@
   +  public function getFieldWidgetType(Row $row) {
   +    return 'options_select';
   +  }
   

   Huh, this Field Widget Type is not even provided by the multiple_selects module?

\Drupal\migrate\Plugin\migrate\destination\ComponentEntityDisplayBase::import() is still calling it with unmodified raw values.

I have a field_course node_reference field. This is its field_config_instance data:

a:7:{s:5:"label";s:5:"Track";s:6:"widget";a:5:{s:6:"weight";s:1:"7";s:4:"type";s:16:"multiple_selects";s:6:"module";s:16:"multiple_selects";s:6:"active";i:1;s:8:"settings";a:0:{}}s:8:"settings";a:1:{s:18:"user_register_form";b:0;}s:7:"display";a:1:{s:7:"default";a:5:{s:5:"label";s:6:"inline";s:4:"type";s:22:"node_reference_default";s:6:"weight";s:1:"8";s:8:"settings";a:1:{s:21:"field_formatter_class";s:10:"pull-right";}s:6:"module";s:14:"node_reference";}}s:8:"required";i:0;s:11:"description";s:39:"Select which track this course reflect.";s:13:"default_value";N;}

Why isn't this just modifying process.widget_type_mapped[0].map in d7_field_instance_widget_settings? Wouldn't that solve it more accurately and with far less code?

Basically, the alter hook equivalent of

diff --git a/core/modules/field/migrations/d7_field_instance_widget_settings.yml b/core/modules/field/migrations/d7_field_instance_widget_settings.yml
index f7977757b7..102aae9dd1 100644
--- a/core/modules/field/migrations/d7_field_instance_widget_settings.yml
+++ b/core/modules/field/migrations/d7_field_instance_widget_settings.yml
@@ -63,6 +63,7 @@ process:
         entityreference_autocomplete: entity_reference_autocomplete
         entityreference_autocomplete_tags: entity_reference_autocomplete_tags
         taxonomy_autocomplete: entity_reference_autocomplete
+        multiple_selects: multiple_options_select
   'options/type':
     -
       plugin: get

… and by stepping through this with a debugger, I ended up with this, which does work for me too:

Just discussed with @phenaproxima.

He sort of reached the same conclusion. He wrote:

18:45
WHOA! I see a way past this problem for you. We’d have to change core, but justifiably so
18:45
\Drupal\migrate_drupal\Plugin\migrate\field\FieldPluginBase::getFieldWidgetMap() — why don’t we just add an alter hook here?
18:46
Or something like that.
18:47
For example:

  public function alterFieldWidgetMigration(MigrationInterface $migration) {
    $process = [];
    $map = $this->getFieldWidgetMap();
    $this->moduleHandler->alter('migrate_field_plugin_widget_map', $map, $this);
    foreach ($this->getFieldWidgetMap() as $source_widget => $destination_widget) {
      $process['type']['map'][$source_widget] = $destination_widget;
    }
    $migration->mergeProcessOfProperty('options/type', $process);
  }

18:47
That’d be entirely BC, and get you out of your predicament.

Wouldn't that make this 100x easier to support?

Yes, I agree that would be better. But let's try it locally first just to be sure.

👍

Thanks for that super helpful update! 🤩🙏

Per #3202462-2: [PP-1] Provide option for contrib modules to map their D6 / D7 field formatter and widget plugin IDs to the equivalent D9 plugin ID, if #3204212: Convert remaining widget and formatter type migrations to MigrateField plugins and #3202462: [PP-1] Provide option for contrib modules to map their D6 / D7 field formatter and widget plugin IDs to the equivalent D9 plugin ID were to land, then all we'd need is this:

/**
 * Implements hook_field_migration_field_widget_info().
 */
function multiple_selects_field_migration_field_widget_info() {
  return [
    'entityreference' => ['multiple_selects' => 'multiple_options_select'],
    'node_reference' => ['multiple_selects' => 'multiple_options_select'],
    'user_reference' => ['multiple_selects' => 'multiple_options_select'],
    'taxonomy_term_reference' => ['multiple_selects' => 'multiple_options_select'],
    'list_integer' => ['multiple_selects' => 'multiple_options_select'],
    'list_float' => ['multiple_selects' => 'multiple_options_select'],
    'list_text' => ['multiple_selects' => 'multiple_options_select'],
    'list_boolean' => ['multiple_selects' => 'multiple_options_select'],
    'commerce_product_reference' => ['multiple_selects' => 'multiple_options_select'],
  ];
}

… and we would not be putting the burden of writing complex test coverage on the shoulders of every single field formatter/widget contrib module maintainer. Which is good, because it increases the likelihood that they'll actually work on providing a migration path!

@huzooka should be credited for #15 btw 🤓