The migrate_drupal_ui module displays a confirmation form indicating what source and destination modules have (or do not have) migration paths defined. Because the source and destination modules for an upgrade path are not always the same, and there was no means to automatically determine in every case what modules a migration applied for, the UI module contained a hard-coded list of migrations and their related source and destination modules. This meant there was no way for the UI to know about contributed module migration paths, and also that core changes to the migration list required editing this list.
The UI now looks for source and destination module information on the source and destination plugins in order to build the confirmation form. A module implementing Drupal-to-Drupal migrations must add source and destination module information where appropriate for those migrations to be properly reflected on the confirmation form.
All source and destination plugins must define a source_module or destination_module, respectively, in their plugin definition/annotation, or an exception will be thrown by the plugin discovery service. If the source module or destination module is defined in the migration yml file as well, that value will take precedence.
Source plugin
Add a source_module to your source plugin annotation:
Previously:
* @MigrateSource(
* id = "d6_box"
* )
Now:
* @MigrateSource(
* id = "d6_box",
* source_module = "block",
* )
If the source module is ambiguous, or may vary depending on how the migration is configured (most frequently in Drupal-to-Drupal migrations, this would be the 'variable' source plugin), you can set an arbitrary value in the plugin definition, then override it in your source plugin configuration. (Note that source_module must be added to any migration using the 'variable' source plugin.)
Previously:
source:
plugin: variable
Now:
source:
plugin: variable
source_module: action
Destination plugin
If your migration uses a custom destination plugin (defined in your module), add destination_module to your destination plugin annotation.
* @MigrateDestination(
* id = "entity:commerce_order",
* destination_module = "commerce_order"
* )The 'config' destination plugin automatically determines the destination module from the destination config_name (e.g., from action.settings it deduces that 'action' is the destination module). Migrations not using the config destination plugin should add destination_module to the destination configuration.
Previously:
destination:
plugin: entity:action
Now:
destination:
plugin: entity:action
destination_module: action
Comments
To fellow developers also
To fellow developers also going through this page:
As of today with latest drupal 8.5.0 This turned out to be limited api break change. Although it affects core sub modules, most contrib modules, and custom modules on the migrate ecosystem.
ANY migrate source plugins and migration destination plugins without these corresponding annotations will still work..
This api break change has only limited damage. Per https://www.drupal.org/node/2911881 only migrations with tags 'Drupal 7' and 'Drupal 6' will get crash.
typo
There seems to be a typo here:
this should be:
Also it still isn't clear with this text as to why or what module should be used as the source or destination, what is meant with "the module responsible for the migration"? Is this the module that contains the plugin or the module that contains the migration definition (yml)?
So I had a bunch of custom
So I had a bunch of custom migrations break, and it turns out it's because I had a source_module defined that was the name of the custom migration module. I think instead of that, it needs to be the name of a module in the source project.
In my case, a migration from a D6 Atrium system, migrations disappeared when the source_module was set to the module containing the source plugins, but when I changed them to "casetracker", "og", "og_access", suddenly the migrations reappeared.
-
John Locke
Freelock
http://www.freelock.com