Migration from Name module

As explained:

AM:A has grown to provide >2500 recommendations, >700 of which are hand-curated, and 280 are vetted, which means we've manually tested, verified and patched the migration path from >400 Drupal 7 modules to >250 Drupal 9 modules.

The https://www.drupal.org/project/name → module has fairly low adoption: ~7K Drupal 7 sites at its peak: https://www.drupal.org/project/usage/name → .

That's why this module is not one of the 400 Drupal 7 modules with a vetted recommendation. See this for yourself:

• https://git.drupalcode.org/project/acquia_migrate/-/blob/recommendations... DOES NOT contain drupal/name → if it's not been curated, it cannot be vetted
• https://git.drupalcode.org/project/acquia_migrate/-/blob/recommendations... DOES contain drupal/name→ it was automatically generated by parsing d.o's API responses to find D7 contrib modules with stable D9 releases

It'll be up to you and others to help vet this migration path. It looks like it does have a migration path already though: 🐛 Remove deprecated MigrateCckField plugin and replace with a MigrateField plugin to allow migrations of the name field to Drupal 9+ Fixed 🥳

That means the next step here is to:

1. reinstall your AM:A Drupal 9 site
2. install the Name module in Drupal 9
3. then start the migration anew — now the 🐛 Remove deprecated MigrateCckField plugin and replace with a MigrateField plugin to allow migrations of the name field to Drupal 9+ Fixed should take effect!
4. report the results! 🙏😄

Thanks for opening this issue!

Following up on #2 ✨ Migration from Name module Needs work I did some testing locally. Steps performed:

1. Install Drupal 7.99
2. Set up a content type
3. Add the NAME module (version 7.x-1.13)
4. Install and add to content type from step 2
5. Create new piece of content with name field populated
6. Generate a new D9 project using acli
7. Connect D7 database as migrate source for D9 site
8. Run migrations for content type created in step 2

Summary
This resulted in the data being transferred over, but the field configuration appeared missing in D9. I think this should work to transfer the data over but you may need to manually port over the field settings to get the fields properly configured again.

More details...

On a new D7 Site
Node add/edit form display:

Display:

DB Storage:

On my D9 Site
On the field settings you can see no components selected after the migration:

You will need to manually update settings here in order for the node add/edit display to look correct:

Display:

DB Storage:

I was able to get the active+required components to transfer over by adding the following to :

if ($row->getSourceProperty('type') == 'name') {
  $settings['components'] = $field_data['settings']['components'];
  $settings['minimum_components'] = $field_data['settings']['minimum_components'];
  $settings['max_length'] = $field_data['settings']['max_length'];
  $settings['labels'] = $field_data['settings']['labels'];
}

However, is this the best way to accomplish this or is there perhaps a better way? Altering the core field module to accommodate a name based field instance seems a bit..too specific. 🤔

#5: your hunch/suspicion is totally warranted! The problem is that Drupal core does not provide the necessary API — see ✨ [PP-1] Provide option for contrib modules to map their D6 / D7 field formatter and widget plugin IDs to the equivalent D9 plugin ID Postponed . This is patch that AM:A applies to Drupal core automatically, precisely to allow contrib modules such as this one to provide a migration path. See #3220294: [PP-2] Migrate D7 colorbox formatter config to D8/D9 → for an example of how to use it — better yet: see the change record → .

@dan612 did , so untagging.

I tried to get this working locally but am still facing some issues. Things get a little confusing between FieldInstance, FieldInstanceSettings, FieldInstanceWidgetSettings 🤪

I thought adding something like this would suffice:

/**
 * Implements hook_field_migration_field_widget_info().
 */
function name_field_migration_field_widget_info() {
  return [
    'name' => ['name_widget' => 'name_default'],
  ];
}

But it seems like the module has already provided a custom field plugin with the mapping therein. IIRC this hook should not be needed since the custom plugin and getFieldWidgetMap() + getFieldFormatterMap() are present.

I think the Migration that controls the settings which we need is d7_field_instance. That migration maps the settings like this:

  settings:
    plugin: d7_field_instance_settings
    source:
      - settings
      - widget
      - field_definition

Where is the correct place to alter these? I could:

1. adjust the d7_field_instance source plugin
2. adjust the d7_field_instance_settings process plugin
3. add a prepare row hook to override the settings

Im leaning towards #3 right now, but thats only because I dont think its OK to propose altering the core field module. So, doing this locally I am able to migrate a name field WITH the current field settings:

/**
 * Implements hook_migrate_prepare_row();
 */
function name_migrate_prepare_row(Row $row, MigrateSourceInterface $source, MigrationInterface $migration) {
  if (!str_contains($migration->id(), 'd7_field_instance')) {
    return;
  }
  if ($row->getSourceProperty('type') == 'name') {
    $field_definition_settings = unserialize($row->getSourceProperty('field_definition')['data'])['settings'];
    $settings = $row->getSourceProperty('settings');
    $settings['components'] = $field_definition_settings['components'];
    $settings['minimum_components'] = $field_definition_settings['minimum_components'];
    $settings['max_length'] = $field_definition_settings['max_length'];
    $settings['labels'] = $field_definition_settings['labels'];
    $settings['widget_layout'] = 'inline';
    $row->setSourceProperty('settings', $settings);
  }
}

I started exploring porting the code in #8 ✨ Migration from Name module Needs work to an EventSubscriber (as I believe the Event system is superior to hooks) and ran into this issue - https://www.drupal.org/node/2952291 → . See this change record → .

It looks like migrate_plus → is dispatching and providing the PREPARE_ROW event which we need to subscribe to. Until this issue - https://www.drupal.org/node/2952291 → - lands, it probably does not make sense to add this to the name module itself as it would then cause a dependency on Migrate Tools (or we alter the composer.json of name module to pull in that issue MR, which is still in process so that seems unstable)...as such I think the only recommendation I have right now is to add the (deprecated) hook into the name.module file.

confusing between FieldInstance, FieldInstanceSettings, FieldInstanceWidgetSettings

Agreed, that's what the ✨ [PP-1] Provide option for contrib modules to map their D6 / D7 field formatter and widget plugin IDs to the equivalent D9 plugin ID Postponed patch stack should've fixed.

I think the Migration that controls the settings which we need is d7_field_instance. That migration maps the settings like this:

Make sure you're looking not at d7_field_instance as it lives in 10.2.x, but at its post-patching state: AM:A applies lots of core patches! I suspect you might have been looking at "plain core"?

Did the two samples I linked in #6 not provide concrete examples? 🤔

Did the two samples I linked in #6 not provide concrete examples?

Isn't the purpose of those to allow mapping of D7 plugin IDs to their modern D8+ counterpart? Those hooks are being added so that developers dont have to maintain a migrate Field plugin with getFieldWidgetMap() and getFieldFormatterMap() but rather can just simply add this hook to adjust the mapping.

In our case we already have those methods so I think those hooks are moot (right?), unless im misunderstanding their purpose.

Make sure you're looking not at d7_field_instance as it lives in 10.2.x, but at its post-patching state: AM:A applies lots of core patches! I suspect you might have been looking at "plain core"?

I am looking at d7_field_instance after an AM:A generated Drupal 9 project (as this was filed against D9). The patches/hooks do not appear to alter the d7_field_instance migration, but rather the d7_field_instance_widget_settings migration, which does not appear to control the name field settings. The hooks do not fire in the d7_field_instance migration.