Problem/Motivation

Identified while working on Bean Migrate:

The block config migration destination plugin EntityBlock forces every block config migrations to calculate the plugin and theme destination properties, because the destination ID is returned by a Storage::loadByProperties() call.

This is a big overhead for translation migrations, because:

  • The plugin and the theme need to be re-calculated due to the destination plugin's logic.
  • The static map of the plugin property should be kept in sync, but for no reason, because:
  • Right now, the block plugin ID uses a lookup – but this isn't used at all, due to the destination plugin.

Proposed resolution

For block config translation migrations (at least) it should be possible to specify only the destination block content ID and the actual property translation.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#3 core-migration_destination_block_config_id_dx-3200936-3.patch2.59 KBhuzooka

Comments

huzooka created an issue. See original summary.

huzooka’s picture

huzooka
Primary language Hungarian
Location Hungary 🇭🇺🇪🇺
commented
Issue summary: View changes
huzooka’s picture

huzooka
Primary language Hungarian
Location Hungary 🇭🇺🇪🇺
commented
Assigned: huzooka » Unassigned
Status: Active » Needs review
StatusFileSize
new core-migration_destination_block_config_id_dx-3200936-3.patch2.59 KB
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Evidently tests are passing. I don't know how thorough tests are for block migrations though.

I think it'd be helpful if you could explain this:

  1. +++ b/core/modules/block/src/Plugin/migrate/destination/EntityBlock.php
@@ -16,6 +16,16 @@ class EntityBlock extends EntityConfigBase {
+      $row->getDestinationProperty('langcode') &&
+      !empty($id = $row->getDestinationProperty('id'))

    This is touching the langcode and id properties… 

  2. +++ b/core/modules/config_translation/migrations/d7_block_translation.yml
@@ -26,50 +26,6 @@ process:
-  # The plugin process is copied from d7_block.yml
-  plugin:
...
-  # The theme process is copied from d7_block.yml
-  theme:

    … but this is touching the plugin and theme properties.

huzooka’s picture

huzooka
Primary language Hungarian
Location Hungary 🇭🇺🇪🇺
commented

Re #4:

I think it is unnecessary. The lines following that condition (in EntityBlock) explain what's going on.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

#5:
Aha. Those lines are:

    // Try to find the block by its plugin ID and theme.
    $properties = [
      'plugin' => $row->getDestinationProperty('plugin'),
      'theme' => $row->getDestinationProperty('theme'),
    ];
    $blocks = array_keys($this->storage->loadByProperties($properties));
    return reset($blocks);

And so you're saying they're no longer being used now. I see.

So … d7_block_translation does not need to migrate those values at all?

quietone’s picture

quietone commented
Status: Needs review » Needs work

Interesting find.

Changing the destination plugin will affect all block migrations and I would like to see more documentation here about these changes.

+++ b/core/modules/block/src/Plugin/migrate/destination/EntityBlock.php
@@ -16,6 +16,16 @@ class EntityBlock extends EntityConfigBase {
+    // Block placement translation can be easily identified by block plugin ID.

I don't understand 'placement translation'. The translations are for properties like 'title' not about placement. Am I missing something?

Some questions, are we always guaranteed that if there is a langcode and id that the id is correct? Will migrations such as d7_block still work if a language property was added to the process pipeline?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Issue tags: -migrate-d6-d7 +migrate-d7-d8

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.