I've been working on a Drupal 6 to 8 migration using Drush. The Drupal 6 site includes Ubercart. In a recent migration test, the following migrations failed due to the the error "Migration did not meet the requirements. No database connection configured for source plugin uc6_product_type".

upgrade_d6_field_instance
upgrade_d6_field_instance_widget_settings
upgrade_d6_view_modes
upgrade_d6_field_formatter_settings

This happened with both beta8 and beta9 versions of the module. Has anyone seen this before? It's preventing fields and fields data from being migrated for content types that are not related to Ubercart as well. Everything else related to Ubercart seems to migrate over just fine.

Thanks for the help!

Comments

rprager created an issue. See original summary.

quietone’s picture

Status: Active » Postponed (maintainer needs more info)

Don't think is a direct result of Commerce Migrate, it doesn't do any altering of the database connection.

What have you checked so far? Check that that fallback database connection exists and is correct, it is 'migrate' and is often set in settings.local.php.

Is the uc6_product_type migration using the same database connection as other working migrations?

rprager’s picture

Thanks for the response. I don't have a fallback database connection setup. I'll have to try that. What I don't understand is why it would be trying to use the fallback connection when everything else is using the connection I setup when starting the migration using Drush just fine. One thing I found interesting looking at the YAML configurations for the migrations that failed is that each have 'upgrade_uc6_product_type' listed as both required and optional. Not sure if that's a problem. Here's the configuration for upgrade_d6_field_instance.

uuid: ef6eeccc-06bb-4fe2-9a94-b1621a4d441a
langcode: en
status: true
dependencies: {  }
id: upgrade_d6_field_instance
class: Drupal\migrate_drupal\Plugin\migrate\FieldMigration
field_plugin_method: alterFieldInstanceMigration
cck_plugin_method: null
migration_tags:
  - 'Drupal 6'
  - Configuration
migration_group: migrate_drupal_6
label: 'Field instance configuration'
source:
  plugin: d6_field_instance
  constants:
    entity_type: node
process:
  field_type_exists:
    -
      plugin: migration_lookup
      migration: upgrade_d6_field
      source:
        - field_name
    -
      plugin: extract
      index:
        - 1
    -
      plugin: skip_on_empty
      method: row
  entity_type:
    -
      plugin: get
      source: entity_type
  field_name:
    -
      plugin: get
      source: field_name
  label:
    -
      plugin: get
      source: label
  description:
    -
      plugin: get
      source: description
  required:
    -
      plugin: get
      source: required
  status:
    -
      plugin: get
      source: active
  settings:
    -
      plugin: d6_field_field_settings
      source:
        - widget_type
        - widget_settings
        - global_settings
  default_value_callback:
    -
      plugin: get
      source: ''
  default_value:
    -
      plugin: d6_field_instance_defaults
      source:
        - widget_type
        - widget_settings
  node_type:
    -
      plugin: migration_lookup
      migration: upgrade_d6_node_type
      source: type_name
  product_node_type:
    -
      plugin: migration_lookup
      migration: upgrade_uc6_product_type
      source: type_name
  bundle:
    -
      plugin: callback
      source:
        - '@node_type'
        - '@product_node_type'
      callable: array_filter
    -
      plugin: callback
      callable: current
    -
      plugin: skip_on_empty
      method: row
destination:
  plugin: 'entity:field_config'
migration_dependencies:
  required:
    - upgrade_d6_node_type
    - upgrade_d6_field
    - upgrade_uc6_product_type
  optional:
    - upgrade_d6_field
    - upgrade_d6_node_type
    - upgrade_uc6_product_type
quietone’s picture

why it would be trying to use the fallback connection when everything else is using the connection I setup when starting the migration using Drush just fine.

If migrate can't find the connection it will try the fallback as a last resort.

Please set the status to active, so a maintainer knows to look. I'm leaving it a Postponed needs more info to see what happens when you define a migrate key in settings.php

rprager’s picture

Status: Postponed (maintainer needs more info) » Active

I added the fallback connection and the migrations worked. I'm still unsure why the fallback was needed for these migrations.

rprager’s picture

I wonder if this has something to do with the fact that it's trying to run the migration called 'uc6_product_type' instead of 'upgrade_uc6_product_type'.

quietone’s picture

The prefix 'upgrade_' is added automatically but the migrate_upgrade command. You can change it using the --prefix option, even making it --prefix='' so that the migration does not have a prefix.

trying to run the migration called 'uc6_product_type' instead of 'upgrade_uc6_product_type'.

Sorry, which migration is causing the error? The error in the IS is, "Migration did not meet the requirements. No database connection configured for source plugin uc6_product_type". which merely gives the name of the source plugin, not the migration. The only migration using that is uc6_product_type.yml which should have been changed to upgrade_uc6_product_type.yml. But that doesn' t explain why the source database connection wasn't found and I'm off to bed now.

rprager’s picture

As mentioned in the original post, the following migrations produce the error Migration did not meet the requirements. No database connection configured for source plugin uc6_product_type

upgrade_d6_field_instance
upgrade_d6_field_instance_widget_settings
upgrade_d6_view_modes
upgrade_d6_field_formatter_settings

Thanks again for your help with this!

rprager’s picture

I believe this issue might be causing another issue: https://www.drupal.org/project/commerce_migrate/issues/3036242

Interestingly, I get the following error in drush if I try to import upgrade_d6_field_instance as the very first migration.

Migration upgrade_d6_field_instance did not meet the requirements. Missing migrations uc6_product_type, upgrade_d6_field, upgrade_d6_node_type, upgrade_uc6_product_type.

I find it interesting that both uc6_product_type and upgrade_uc6_product_type are included in the requirements.

If I start running the missing migrations in order, the uc6_product_type will process 9 records while the upgrade_uc6_product_type migration will ignore the same 9 records. I see tables called migrate_map_uc6_product_type and migrate_map_upgrade_uc6_product_type.

When I then try to run upgrade_d6_field_instance after migrating all its requirements, it ignores all 33 records. My hunch is that it has something do with there being both a uc6_product_type and upgrade_uc6_product_type required.

quietone’s picture

Status: Active » Postponed (maintainer needs more info)

@rprager, is this still a problem?

I find it interesting that both uc6_product_type and upgrade_uc6_product_type are included in the requirements.

That should not be the case, uc6_product_type should have been changed to upgrade_uc6_product_type. You could edit the configured migration, the one store in configuration, or start over and regenerate them.

To confirm, I ran `drush migrate-upgrade --legacy-root=http://172.18.0.12 --legacy-db-url="mysql://drupal6:drupal6@172.18.0.12/drupal6" --configure-only `. That results in the dependencies on migrate_plus.migration.upgrade_d6_field_instance.yml being

migration_dependencies:
  required:
    - upgrade_d6_node_type
    - upgrade_d6_field
    - upgrade_uc6_product_type
  optional:
    - upgrade_d6_field
    - upgrade_d6_node_type
    - upgrade_uc6_product_type
quietone’s picture

Status: Postponed (maintainer needs more info) » Active

@rprager, is this still an problem for you?

sinasalek’s picture

Würden’s picture

I am also seeing this issue working on a D6 to D8 migration currently.
I had to rename upgrade_uc6_product_type to uc6_product_type in every migration YAML it occurred before the error went away. Now the products are migrated except they don't have any fields on them because the field_instance migration ignores everything because of a bug in commerce_migrate module it would seem, that's a separate issue on the migration also filed here: https://www.drupal.org/project/commerce_migrate/issues/3036242

marcoka’s picture

This happens to normal drupal installations too. Its not special to commerce_migrate i guess.