A new node migration, d*_node_complete.yml, referred to as the 'complete node migration', now exists that will migrate all nodes, the node revisions, including translated nodes and the translated node revisions. The complete node migration will eventually replace the existing trio of node migrations, d*_node, d*_node_revision and d*_node_translation, now collectively referred to as the classic node migrations.
When using the core migrate UI, /upgrade, the d*_node_complete migration is the default. The classic node migrations are completely removed from the list of migrations that are run. It will be used for all new migrations.
The classic node migrations are not deprecated. Both exist in core and other migrations that depend on the node migrations are modified at run time to work with both the classic node migration and the complete node migration.
Changed migrations
There are several migrations that are modified so that the complete migration can use the same migrations as the classic node migration. The changes are to any process pipeline that uses a migration_lookup process plugin with a classic node migration as the migration lookup source.
The migrations changed are: d6_term_node, d6_term_node_revision, d6_term_node_translation, d6_comment, d6_url_alias,d7_comment, d7_url_alias, statistics_node_counter and node_translation_menu_links.
Migration dependencies altered
When the new complete node migration is in use any migration which has dependencies on a the classic node migrations is altered to change those dependencies to complete node migrations.
These alterations are done in migrate_drupal.module, via hook_migrations_plugin_alter(), when the complete node migration is in use.
Incremental migrations
The classic node migrations will run if, and only if, the new site has classic node migration map tables with rows. If you have run an upgrade, /upgrade, prior to this change then migrate_map node tables will have data. So that when an incremental is run from /upgrade the classic node migration will run.
Drush
When using drush to run migration both the classic and complete migrations are available.
Before
These migrations are now referred to as the classic node migrations.
| Migration | Migrates | Modules to install |
|---|---|---|
| d*_node | Current node revision | Node |
| d*_node_revision | Node revisions | Node |
| d*_node_translation | Current translated node revision | Content Translation, Migrate Drupal Multilingual |
After
There is one node migration referred to as the complete node migration.
| Migration | Migrates | Modules to install |
|---|---|---|
| d*_node_complete | All node revisions and all translated node revisions | Node |
Defaulting to the classic migrations
If you are developing custom migrations that depend on the classic migrations and you don't want to change them to use the new complete node migration then you can override the default using settings.php. Add the following line to default to classic migrations.
$settings['migrate_node_migrate_type_classic'] = TRUE;
Comments
Oops, this caused a
Oops, this caused a regression: #3184627: D8.9 breaks D8-to-foo entity migrations
Please don't deprecate classis migrations
Please, never deprecate the classic migrations - sometimes when doing a migration, you won't want the historic revisions. Without classic migrations, there'd be no way to do that afaics.
Yes I second the need to keep
Yes I second the need to keep classic. Also if you've already tried running the complete migration and are trying to switch to classic, you are likely going to have to manually drop the table to start over: https://blog.werk21.de/en/2017/12/13/change-source-id-mapping-drupal-8-m...
This looks great but...
Where is the documentation? "Complete" make me wonder how complete? For example, we typically have custom fields on entities like blog that are entity reference fields. Lets say a taxonomy term for example.
In a "classic" migration, we would migrate the taxonomy items first, then use
migration_lookupto attach those referenced items to the blog field itemIs this still the requisite workflow - or does complete infer that we can just point at the entity reference field and magic happens to resolve and migrate and attach those items.