Closed geerlingguy closed 4 years ago
Looks like this'll do the trick:
/**
* Implements hook_migrate_prepare_row().
*/
function custom_migrate_prepare_row(Row $row, MigrateSourceInterface $source, MigrationInterface $migration) {
$migration_id = $migration->id();
// Ignore blocks in the seven theme.
if ($migration_id == 'upgrade_d7_block') {
if ($row->getSourceProperty('theme') == 'seven') {
return FALSE;
}
}
}
Testing on a fresh install + migration now...
Since the problem in this case is a single file, would adding block.block.seven_system_main.yml
to .gitignore
also have worked as a quick workaround? Mostly to avoid the overhead of checking each row, which might make running a migration slower, like you also mention.
@gitressa - True, however for local installs it would still drop the file in there every time I migrated then exported configuration, so the next install it would pop the error message again. So better to ignore it on the row level (or maybe even preprocess the database when pulling from current production, to avoid the row-level check).
I see, thanks for clarifying that @geerlingguy, that makes sense.
As part of the
upgrade_d7_block
migration, the seven theme's block placement for the main content block is always migrated into the new D8 site. I can't seem to get that to not migrate by default, so I'd like to add something to ignore that row in the block table when migration is run:It's especially annoying because any time I export configuration after migrating the site fresh, I have to remember to remove the new file:
If I don't then installation fails due to the block being added for a theme that is not enabled on the D8 site!
I'm going to see if
hook_migrate_prepare_row()
is easy enough to use to ignore that block (mentioned in this Drupal Answers question).