Problem/Motivation
When Drupal migrates field formatter and field widget configurations into entity_view_display and entity_form_display entities, it often happens that the migrated formatter plugin (or field widget) has no replacement on the destination site.
In this cases, plugin discovery throws (and logs) a PluginNotFoundException (with an another log created by MigrateUpgradeImportBatch::onIdMapMessage), and the affected field gets hidden in its target entity_view_display (or entity_form_display) entity.
PluginManager's message:
The "file_rendered" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: address_country_default, address_default, address_plain, address_zone_default, comment_default, comment_username, comment_permalink, datetime_plain, datetime_custom, datetime_time_ago, datetime_default, file_default, file_rss_enclosure, file_extension, file_filemime, file_uri, file_url_plain, file_video, file_audio, file_table, file_size, file_link, image, image_url, link, link_separate, media_thumbnail, oembed, list_key, list_default, entity_reference_rss_category, text_default, text_summary_or_trimmed, text_trimmed, user_name, author, timestamp, entity_reference_entity_id, entity_reference_label, boolean, number_decimal, language, basic_string, string, timestamp_ago, uri_link, number_integer, number_unformatted, email_mailto (/Users/zoli/projects/drupal/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53)
Migrate Drupal UI's log message:
Source ID node,article,featured,field_image: The "file_rendered" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: address_country_default, address_default, address_plain, address_zone_default, comment_default, comment_username, comment_permalink, datetime_plain, datetime_custom, datetime_time_ago, datetime_default, file_default, file_rss_enclosure, file_extension, file_filemime, file_uri, file_url_plain, file_video, file_audio, file_table, file_size, file_link, image, image_url, link, link_separate, media_thumbnail, oembed, list_key, list_default, entity_reference_rss_category, text_default, text_summary_or_trimmed, text_trimmed, user_name, author, timestamp, entity_reference_entity_id, entity_reference_label, boolean, number_decimal, language, basic_string, string, timestamp_ago, uri_link, number_integer, number_unformatted, email_mailto (/Users/zoli/projects/drupal/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53)
The messages above always follow each other.
Proposed resolution
Instead of logging the same message with MigrationInterface::MESSAGE_ERROR twice, we prevent PluginNotFoundExceptions by automatically selecting the default field formatter plugin ID (or widget ID). In these cases (so when the fall-back logic was needed for the right field formatter plugin ID), we add the related message to the MigrateExecutable in those migrate process plugins that are doing the fallback. These are caught in MigrateUpgradeImportBatch and logged into the logger.
This still informs the user, but does allow the migration to succeed, allows checking the rendered migrated entity, and generally results in fewer pointless messages.
We can do this for both d7_field_formatter_settings and d7_field_instance_widget_settings— the same problem can occur for both formatters & widgets.
Remaining tasks
User interface changes
API changes
Data model changes
Default formatters and widgets instead of hidden fields in entity forms and rendered entities.
Less resources are needed to restore the original structure.
Release notes snippet
