Problem/Motivation
The 'date' field plugin for Drupal 6 was replaced with a 'datetime' field plugin that works for both Drupal 6 and 7 migrations. Despite deprecating the original date plugin, the plugin manager still creates an instance of it when requesting a plugin for a D6 date field because it is found first in the plugin list and the annotations say it applies. Removing the type_map from the annotations partially solves this, but due to the fact that the field name and plugin id match, it is still selected to manage D6 date fields even though it shouldn't be anymore.
Due to this, the deprecation error triggered by this plugin was ignored globally, creating technical debt that needs to be resolved for Drupal 9.
Additionally, the same system makes it difficult or impossible for contrib plugin to override a core MigrateField plugin for a specific field. Because the first discovered applicable plugin is used, there is no way to guarantee a contrib plugin will actually override the core plugin.
Proposed resolution
Adding a weight field to the plugin annotation will allow plugins to declare the order in which they should be used for field migrations. Deprecated plugins can be set to a higher weight, and contrib overrides can be set to a lower weight. Applying a sort first by weight, then by plugin ID will assure a single deterministic, testable, and repeatable plugin will be used for any given field and core version.
Remaining tasks
Add a weight field to the MigrateField annotationSort the plugins by weight and plugin ID in MigrateFieldPluginManagerAdd/refactor/adjust testsRemove the date plugin deprecation from the global ignore list.
User interface changes
None
API changes
MigrateField plugins now have a weight field in their annotation that determines which one is used for a given field and Drupal core version.
Data model changes
None.