Provide useful error message for: The "" plugin does not exist on Drupal 6 / 7 migrations

I have the same problem. Does anyone have a solution?

Me too. Can't see any empty "plugin" lines in the YAML.

I,ve got the same problem, any solution for this?

https://www.reddit.com/r/drupal/comments/of145l/the_plugin_does_not_exis...

here's the fix. In my case resolved the problem

I can confirm we're running into the same issue with 4.0.0 when migrating a Drupal 7 site to Drupal 9.

The reddit issue from #6 (https://www.reddit.com/r/drupal/comments/of145l/the_plugin_does_not_exis...) says:

In migrate_plus.migration.upgrade_d7_field_instance.yml the lines

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

should be

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

Now the question is, which version is correct and where the wrong one comes from or why it fails. Any ideas?

But first, please see the module page of migrate_upgrade:

Bug reports
It is important to note that this module only provides the front-end to the upgrade process - if you see a problem with the results of your migration, this is almost certainly an issue with the core framework, and should be reported to the core issue queue with a component of "migration system".

As of this, I'll now move the issue over to Drupal core.

@Kenzomus, when making an issue on drupal.org, add your details in the Problem section and leave the rest. Those headers are there to help us keep track of the work to do.

The d7_field_instance migration is well, a field, migration and can be altered by contrib and custom code. We need more information to narrow this down. Can you identify the field or fields instances that are not being created? In particular, knowing the field type (like paragraphs) is needed.

Thanks, @quietone we'll also try to help to track this issue down, as we were running into it on a large Drupal 7 to Drupal 9 migration. We'll try to provide all possible details.

@quietone, I think the first part here, wherever it is caused, should be to improve the error message. We're now running into this again, but you can't see which migration triggers the error.

This is the drush output:

[notice] Processed 5 items (5 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_taxonomy_vocabulary'
 [warning] Undefined array key "plugin" Migration.php:717
 [warning] Undefined array key "plugin" Migration.php:720
 [warning] Undefined array key "plugin" Migration.php:717
 [warning] Undefined array key "plugin" Migration.php:720
 [warning] Undefined array key "plugin" Migration.php:430
 [warning] Undefined array key "plugin" Migration.php:431

In DiscoveryTrait.php line 53:

  The "" plugin does not exist. Valid plugin IDs for Drupal\migrate\Plugin\MigratePluginManager are: addressfield, block_visibility, block_plugin_i  
  d, block_settings, block_theme, block_region, captcha_type_formatter, d7_field_settings, d7_field_type_defaults, d7_field_instance_option_transla  
  tion, field_bundle, d7_field_instance_defaults, d7_field_option_translation, d7_field_instance_settings, field_instance_widget_settings, field_fo  
  rmatter_settings_defaults, field_settings, d6_field_type_defaults, d6_field_instance_option_translation, d6_field_instance_defaults, d6_field_opt  
  ion_translation, d6_field_field_settings, process_field, field_type, file_uri, d6_field_file, filter_format_permission, filter_id, filter_setting  
  s, d6_imagecache_actions, inline_entity_form_field_instance_settings, language_types, content_translation_enabled_setting, language_negotiation,   
  language_domains, field_link, mailsystem_modules, d7_metatag_entities, d6_nodewords_entities, route, menu_link_parent, download, skip_on_empty, e  
  xplode, callback, entity_exists, default_value, concat, machine_name, flatten, substr, get, array_build, null_coalesce, sub_process, urlencode, f  
  ormat_date, static_map, make_unique_entity_field, migration_lookup, log, file_copy, extract, skip_row_if_not_set, node_complete_node_lookup, node  
  _complete_node_revision_lookup, node_complete_node_translation_lookup, file_id_lookup, media_name, check_duplicate, media_file_copy, check_media_  
  duplicate, entity_lookup, dom_select, skip_on_value, array_pop, dom_apply_styles, gate, single_value, transpose, dom_remove, file_blob, array_shi  
  ft, merge, dom_str_replace, entity_value, default_entity_value, dom, dom_migration_lookup, str_replace, multiple_values, entity_generate, service  
  , node_update_7008, field_collection_field_settings, paragraphs_lookup, paragraphs_process_on_value, paragraphs_field_settings, paragraphs_field_  
  instance_settings, field_collection_field_instance_settings, path_set_translated, d6_url_alias_language, d7_redirect_source_query, d7_path_redire  
  ct, d6_path_redirect, image_style_mappings, shield_paths, parse_dates, timezone, system_update_7000, target_bundle, forum_vocabulary, user_update  
  _8002, user_update_7002, d6_profile_field_option_translation, convert_tokens, profile_field_settings, user_langcode, link_options, link_uri        


Failed to run drush migrate-import --group=zmp_migrate --continue-on-failure --limit=365: exit status 1

As I guess the error appears AFTER upgrade_d7_taxonomy_vocabulary it would be super helpful to see in which migration fails. Having a look into the Migration.php file, I think the value given is already empty, which we might add a check for, so it's not passed to the plugin loading at all?

I'll try that...

Created a MR which throws an exception if the 'plugin' key is missing or has an empty value. First it was an !isset() check, but I think empty() is safer here, if the key is present, but has an empty value. Guess there will never be a plugin called "", 0 or something like that.

I found #3248350: Migrate Module: Notice: Undefined index: plugin in Drupal\migrate\Plugin\Migration->findMigrationDependencies() (line 641 of core/modules/migrate/src/Plugin/Migration.php). which is somehow related, improving the error handling may help to find the failing / broken migration. So we can later decide if we implement the error handling here or in the other issue.

This doesn't solve the root cause reported here yet, but if running into such an error, will help to track things down! So I'd definitely vote for adding error handling here.

BTW additionally to the issue reported here, we're also experiencing

 [warning] Undefined array key "plugin" Migration.php:717
 [warning] Undefined array key "plugin" Migration.php:720
 [warning] Undefined array key "plugin" Migration.php:717
 [warning] Undefined array key "plugin" Migration.php:720

when starting the migration using
drush migrate:import --group=my_migrate_group not only during the migration.

The migrations were generated using
drush migrate:upgrade --legacy-db-key=migrate --configure-only from a Drupal 7 website.

Okay, here we have the results:

For more details, I locally changed the line from the MR to:

throw new MigrateException('Missing \'plugin\' property for $plugin_configuration: ' . var_export($plugin_configuration, TRUE) . ' in ' . $this->getBaseId());

and it throws the following Exception when running
drush migrate:import --group=my_migration

In Migration.php line 721:
Missing 'plugin' property for migration: array (
0 =>
array (
'plugin' => 'd7_field_instance_settings',
'source' =>
array (
0 => 'settings',
1 => 'widget',
2 => 'field_definition',
),
),
'inline_entity_form' =>
array (
'plugin' => 'inline_entity_form_field_instance_settings',
),
)

which confirm the assumptions from this issue and we're running into the same issue.

I guess this might be related / the reason? #3221074: Implemented hook_migration_plugins_alter() breaks migrations, if shared configuration used in migration configs.

@quietone: 100% sure now, that this is NOT a core issue and inline_entity_form causes this in: #3221074

BUT as written above I'd really vote to improve the error handling for such cases, which isn't good here, as the comments above demonstrate.
How should we proceed? Create a follow-up with the proposed error handling from MR!2706 or should we first discuss further steps here by example or even use this issue, as it shows why this is needed?

Of course, we should then also add a failing test for broken migration config like this triggering the exception:

  settings:
    0:
      plugin: d7_field_instance_settings
      source:
        - settings
        - widget
        - field_definition
    inline_entity_form:
      plugin: inline_entity_form_field_instance_settings

Thanks :)

We forgot to change the status of this issue!

Already tested it for our custom d7 Migration, does what it should do!

I just noticed, that this is also relevant for d6 Migrations, I'll test if the MR provided will also fix it for d6!

Ok, I just tested the d6 to d9 migration, with the patch applied and instead of The "" plugin does not exist., I know get Missing 'plugin' property for 'options/type' in migration: 'upgrade_d6_field_formatter_settings'!

So also works as expected for d6. :)

PS: Couldn't find a migration tag for drupal 7 to drupal 8+, also the tag names seem to be kinda deprecated (no sign of drupal 9 / drupal 10 migration)

Updated the issue title and issue summary. This issue (and the patch) is not about fixing such issues, but about providing helpful information WHAT went wrong WHERE.

One typical CAUSE for this issue can be found in #16. The root cause is not a core issue, but core should be more helpful to provide error details.

It shows that $configuration['plugin'] can be empty, but is expected to exist and used in the next lines, so better error handling is required.

Thanks for moving this forward!

This issue does not need any special tags. The tags 'migrate-d6-d8' and 'migrate-d7-d8' are for migrations specific to d6 or d7 sources. The proposed change here is in migrate, which will apply to migrations from any source.

This will also need tests, adding tag and setting to NW for that.

I haven't reviewed the patch yet.

@quietone thanks! We'll also add tests here to trigger the Exceptions using a wrong configuration.

I guess it would make sense, if you had a short look at the MR first, to decide if the way we do it is okay?

Here is a static patch file for the time being, if anyone needs it.

Patch from #26 still perfectly applies on 11.x.

Also with this patch enabled, the root cause seems to be that an array containing the plugin arrays is passed to the method where we added the exception.
The array with the "plugin" key is one level deeper. The question is, why this happens!

Example:
drush migrate:import --group=xyz --continue-on-failure

throws this exception with the patch applied

Missing required 'plugin' property for 'vid' in migration: 'upgrade_d7_taxonomy_vocabulary'

because the following array in array is passed:

array(2) {
  [0]=>
  array(6) {
    ["plugin"]=>
    string(24) "make_unique_entity_field"
    ["source"]=>
    string(12) "machine_name"
    ["entity_type"]=>
    string(19) "taxonomy_vocabulary"
    ["field"]=>
    string(3) "vid"
    ["length"]=>
    int(30)
    ["migrated"]=>
    bool(true)
  }
  [1]=>
  array(2) {
    ["plugin"]=>
    string(16) "forum_vocabulary"
    ["machine_name"]=>
    string(6) "forums"
  }
}

In Migration.php line 733:

The .yml part looks like this:

[...]
source:
  plugin: d7_taxonomy_vocabulary
process:
  vid:
    -
      plugin: make_unique_entity_field
      source: machine_name
      entity_type: taxonomy_vocabulary
      field: vid
      length: 30
      migrated: true
    -
      plugin: forum_vocabulary
      machine_name: forums
[...]

which seems correct?

Is this eventually caused by another patch we use?

@anybody
maybe it will help
https://www.drupal.org/project/drupal/issues/2914251#comment-15407690

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.