Not a lot of information ATM but this is the failure in my log:

Running d6_field_instance_widget_settings
The "filefield_widget" plugin does not exist.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

neclimdul created an issue. See original summary.

phenaproxima’s picture

Status: Active » Needs review
FileSize
1.18 KB

Does this help?

neclimdul’s picture

Fixes it.

phenaproxima’s picture

So the weird thing here is that the widget type migration is already specifically asserted in MigrateFieldWidgetSettingsTest. So I'm not sure why it's failing for you -- but the fact that it worked when the mapping was explicit in the migration entity versus when it was (supposed to be) put there dynamically by the migration builder is very telling. I don't know if I can reproduce this without looking at your specific case.

But I do have a theory -- did you have the Drupal 8 File module enabled when you ran the migration? It contains the cckfield plugin which sets up the correct mapping, so if you didn't have the module enabled, this could very well be the source of the failure.

neclimdul’s picture

Enabled:
Field types File (file) Module Enabled 8.0.0-dev

neclimdul’s picture

Issue tags: +Needs tests

Forgot about this guy.

phenaproxima’s picture

Issue tags: -Needs tests
FileSize
1.49 KB

Added a test, but it passes against 8.0.x. Not sure how to reproduce your issue.

phenaproxima’s picture

Title: d6_field_instance_widget_settings seems to fail with filefield_widgets » migrate-manifest does not support the migration builder system
Project: Drupal core » Migrate Plus
Version: 8.0.x-dev » 8.x-1.x-dev
Component: migration system » User interface
FileSize
641 bytes

@neclimdul and I did a screen share and figured out why this was happening -- it's because the migrate-manifest command is not aware of the builder system, which must be invoked in order for the proper widget mapping to be added to the migration.

Attached patch adds builder support to migrate-manifest.

neclimdul’s picture

Status: Needs review » Closed (won't fix)
osopolar’s picture

Title: migrate-manifest does not support the migration builder system » d6_field_instance_widget_settings seems to fail with filefield_widgets
Version: 8.x-1.x-dev » 8.x-3.x-dev
Component: User interface » API
Status: Closed (won't fix) » Needs work
Related issues: +#2767237: Files not attached to nodes using drush migrate-import

Sorry for reopening this issue, I have the same problem and it seems that I am not alone, see: #2767237: Files not attached to nodes using drush migrate-import. The attaching in that issue works with additional settings in #13, but the filefield is not migrated (correctly).

According to #2 I added to my customized d6-to-d8 migration (in modules/custom/my_migration/config/install/migrate_plus.migration.upgrade_d6_field_instance_widget_settings.yml the filefield_widget mapping filefield_widget: file_generic:

process:
  # ...  
  options/type:
    type:
      # ...
      map:
        # ...
        filefield_widget: file_generic

I uninstalled Migrate manifest module, as I am not using it anymore, but anyway, the problem persists. Not sure if it is a core bug or migrate plus issue or a problem with my setup.

Maybe related to this issue is, that the field formatters aren't set for images/files. In migration messages I can find for example:

Failed to lookup field type array ( 0 => 'filefield', 1 => 'image_plain', ) in the static map.
Failed to lookup field type array ( 0 => 'filefield', 1 => 'default', ) in the static map.
Failed to lookup field type array ( 0 => 'filefield', 1 => 'imagefield__lightshow2__img_in_page__original', ) in the static map.
Failed to lookup field type array ( 0 => 'filefield', 1 => 'Thumbnail_linked', ) in the static map.

And the fields are set to hidden.

mikeryan’s picture

Status: Needs work » Closed (duplicate)

Hard to imagine what the fieldfield_widget error would have to do with migrate_plus - since that's raised in #2767237: Files not attached to nodes using drush migrate-import, that's a better place for further diagnosis (although still more likely to do with core than migrate_upgrade).