Voting starts in March for the Drupal Association Board election.
As argued inmigrations should not use the config system. Now I agree they should not be config but instead should be plugins. Note the original issue did not suggest plugins, this was an idea of phenaproxima which I now consider doable based on a new, more complete understanding of the plugin system I've acquired during the long and hard debugging of .
Make them plugins. The current YML files themselves become a plugin each via a custom discovery. UI and code provided migrations still go into the config active store and retrieved as plugin derivatives.
Benefits of approach
- No more templates, custom to the Migrate API and hard for others to understand.
- No more builders, this now uses derivates like other parts of core. E.g. menu blocks.
- No more config objects but still a simplified YAML file to describe migrations.
- Add back a query system. This will be done in a followup. The config entity query is easy to extend for this -- only the
loadRecordsmethod needs to be overridden.
- Dependency/requirements handling is also a followup.
User interface changes
Migration entity is gone so
Migration::load calls need to be converted.
Migration::create($config) in tests becomes simply
new Migration(, uniqid(), $config); and the
use statement needs to change from
\Drupal::service('plugin.manager.migration')->createInstance($id). Once you have a
Migration object -- now a plugin -- the methods are the same. A followup will make it necessary to change the
use statement for the MigrationInterface as it will also move from Entity into Plugin.
For code provided migrations here's an example from
$term_migration = Migration::create($config); $term_migration->save();
$term_migration = MigrationConfigDeriver::save('terms', $config);
There is no create because, well, there's nothing save-able to create.
Data model changes