Ignore the seven system main block in the upgrade_d7_block migration

[geerlingguy]

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:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    config/sync/block.block.seven_system_main.yml

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).

[geerlingguy]

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;
    }
  }
}

[geerlingguy]

Testing on a fresh install + migration now...

[gitressa]

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.

[geerlingguy]

@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).

[gitressa]

I see, thanks for clarifying that @geerlingguy, that makes sense.