[PP-1] Provide option for contrib modules to map their D6 / D7 field formatter and widget plugin IDs to the equivalent D9 plugin ID

#2: is the top-level field type key truly necessary? Why can't we just map widget plugin IDs and formatter IDs?

How does this patch relate to #3108302: [PP-2] Field formatter & widget settings: fall back to default if missing plugin?

maybe it just suddenly began to work?..

😅🔥

This is blocked on #3204212: Convert remaining widget and formatter type migrations to MigrateField plugins .

The example in #2 is wrong. It's not hook_field_migration_widget_plugin_id_info(), but hook_field_migration_field_widget_info().

Note that there is zero pre-existing documentation about the field migration infrastructure (\Drupal\migrate_drupal\Plugin\migrate\field\FieldPluginBase() and friends), so it is very unclear where to document this. This explains @huzooka's remaining task in the issue summary:

• Document the new hooks (where?..).

… so I went ahead and created a change record: https://www.drupal.org/node/3208917

Adding a concrete example of the impact to the issue summary.

1. +++ b/core/modules/field/migrations/d6_field_formatter_settings.yml
   @@ -5,7 +5,7 @@ migration_tags:
   -field_plugin_method: alterFieldFormatterMigration
   +field_plugin_method: false
   
   +++ b/core/modules/migrate_drupal/src/FieldDiscovery.php
   @@ -145,6 +145,11 @@ public function addBundleFieldProcesses(MigrationInterface $migration, $entity_t
   +        // Allow migration plugins skipping alterations.
   +        if (!$method) {
   +          continue;
   +        }
   

   🤔 AFAICT this is how we retain BC?

2. +++ b/core/modules/field/src/Plugin/migrate/process/FieldMigrationPluginIdMapper.php
   @@ -0,0 +1,173 @@
   +    if (!$this->migrateFieldPluginManager) {
   +      // Exception or return the value? Or NULL? TBD.
   +      return $value;
   +    }
   

   🤔 When could this ever occur? AFAICT this if-test is safe to remove because the constructor guarantees it exists?

3. +++ b/core/modules/field/src/Plugin/migrate/process/FieldMigrationPluginIdMapper.php
   @@ -0,0 +1,173 @@
   +    if (!is_array($value) || count($value) !== 2) {
   +      // TBD.
   +      return $value;
   +    }
   

   🤔 When can this occur?

4. +++ b/core/modules/field/src/Plugin/migrate/process/FieldMigrationPluginIdMapper.php
   @@ -0,0 +1,173 @@
   +    if (!is_string($property) || !array_key_exists($property, self::PROPERTY_MAP)) {
   +      // TBD.
   +      return $value;
   +    }
   

   This would be an invalid use of this migration plugin.

   IMHO this should throw a InvalidArgumentException or a MigrateException.

5. +++ b/core/modules/field/tests/src/Unit/Plugin/migrate/process/FieldMigrationPluginIdMapperTest.php
   @@ -0,0 +1,332 @@
   +        'Hook return' => [],
   +        'Expected' => 'unmapped_preprocessed_field_formatter_id',
   ...
   +        'Hook return' => [
   +          'foo_source_field_type' => [
   +            'foo_source_field_formatter_id' => 'bar_field_formatter_id',
   +          ],
   +        ],
   +        'Expected' => 'bar_field_formatter_id',
   ...
   +        'Hook return' => [],
   +        'Expected' => 'unmapped_foo_source_field_widget_id',
   ...
   +        'Hook return' => [
   +          'foo_source_field_type' => [
   +            'foo_source_field_widget_id' => 'bar_field_widget_id',
   +          ],
   +        ],
   +        'Expected' => 'bar_field_widget_id',
   

   Superb test coverage! 🤩

In #9 it is said that this is postponed, so changing status.

#16 LGTM! We're using this in several migration projects and it works great!

As this is a "Contributed project blocker" for many contrib issues (all field formatter and widget upgrades), would it perhaps make sense for @Wim Leers (as of #12) or @quietone to already review this for having this RTBC'd as soon as #3204212: Convert remaining widget and formatter type migrations to MigrateField plugins lands?

I think that would help in many many contrib projects and migration projects.

Rerolled on top of #3204212-52: Convert remaining widget and formatter type migrations to MigrateField plugins , due to conflict introduced by #3281427: Update Block and Theme setting migrations to not use Bartik and Seven.

@Wim Leers: Thanks a lot for #20!
As we experienced different behavior (still investigating) from #16 with 9.4.x vs. #20 with 9.5.1 could you perhaps provide an interdiff? I tried, but it didn't work, sorry. :(

And wouldn't it be more transparent to use a MR here to see the changes directly?

Update to #21. Patch #20 works great! We just had to regenerate the migration ymls! 🙂👍

Using patch from #20 for 3 site migrations now and found a little flaw with field widget configurations (and probably also with field formatter settings).

For example, I am migrating any "entityreference_view_widget" field widgets to "entity_browser_entity_reference" for every entityreference field using:

    'entityreference' => [
      'entityreference_view_widget' => 'entity_browser_entity_reference',
    ],
    'node_reference' => [
      'entityreference_view_widget' => 'entity_browser_entity_reference',
    ],

This works as expected, BUT I have no way to tell the new field widget it's settings. In my example, trying to edit a content using the mentioned field widget will result in the following error:

TypeError: key(): Argument #1 ($array) must be of type array, null given in key() (line 462 of modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget)

This happens, because the field widget has no entity browser selected. I am yet unsure if the hooks implemented through this issue should implement a way to map these settings (or set them). Or if this is the module's fault, as it should implement fallback options.

Furthermore, if anyone is using this patch together with Media Migration, make sure you implement the mapping for the field type media migration converts it to.

For example, if we have image fields on a few content types, which are using the deprecated "lightbox2" field formatter, and we want to migrate them to the "image" field formatter, we would usually do the following mapping:

'image' => [
    'image' => [
      'lightbox2' => 'image',
    ],

But because "media_migration" will convert all image fields to media fields before "hook_field_migration_field_formatter_info()" runs, we have to map "media_image" instead:

    'media_image' => [
      'lightbox2' => 'image',
    ],

@Win Leers: Re #24 should we perhaps allow to pass settings as additional value?

@Grevil: Re #25: Perhaps it would make sense to create an issue over at Media Migration to let them know and perhaps implement a default for that or add it to their documentation? This is important to know, but shouldn't be relevant in this issue.

@Anybody already did that a while ago and you already commented that issue! :P
#3317541: [PP-1] Document the use of future implementations "hook_field_migration_field_widget_info()" and "hook_field_migration_field_formatter_info()" with this module

Just thought this information might be relevant here aswell!

Patch from #20 still applies to current 11.x, using latest reroll from https://www.drupal.org/project/drupal/issues/3204212#comment-15475785!

Any chance that this goes in before D7 goes out of support? Migrating from D7 is quite difficult without and I do not like to run D7 in 2026 only because of migration failures.

@marc.bau, if you haven't already you can consider seeking support in the #migration channel of Drupal Slack.

The Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.

Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.

How should a removal of migration stuff from core fix the defects and allow people to migrate? *shakes head*

@marc.bau, sites can continue to use the Migrate Drupal functionality in Drupal 11, which will be supported until 2028. The Migrate API itself will remain Drupal 12. Fixes can still be made to Migrate Drupal but that will not include feature requests.

Oops, forgot this comment.

The Migrate Drupal and Migrate Drupal UI modules are deprecated and will be removed from Drupal 12. Since these are deprecated feature requests and some tasks will not be fixed.

Thanks to all for working on this!