Migration from Layout Builder (content overrides)

The migration is located in BuilderDataConverter::convertFromLayoutBuilder()

We are triggering it only from config right now, from the implementation of DisplayBuildableInterface::getInitialSources():

  public function getInitialSources(): array {
    // Get the sources stored in config.
    $sources = $this->getSources();

    if (empty($sources)) {
      // initialImport() has two implementations:
      // - EntityViewDisplay::initialImport()
      // - LayoutBuilderEntityViewDisplay::initialImport()
      $sources = $this->initialImport();
    }

    return $sources;
  }

https://git.drupalcode.org/project/display_builder/-/blob/1.0.x/modules/...

It seems the migration logic would stay the same, we lmay just need to trigger it from content too: DisplayBuildableInterface::getInitialSources() is also implemented in https://git.drupalcode.org/project/display_builder/-/blob/1.0.x/modules/...

Hi Florent,

You are right, it must be clarified and documented.

Current state of the MR

Before talking about import and conversion, we notice Display Builder takes the lead over Layout Builder to render a content (even when there is a Layout Builder override in content).

However, the import (& conversion) when we open a DB override for the first time (ie, when there is no data in stored in the field already), is not following this priority order:

This difference is confusing, we must align the mechanisms. How?

Proposal 1: Display Builder always win

Same priority order for display and import:

Proposal 2: Overrides always win

Maybe it is confusing to lose all LB overrides once Display Builder is activated in a display, it changes the display of existing content. It breaks the content in a way.

Same priority order for display and import:

Work as expected. Kernel tests added.

Still a playwright fail in pipeline, but doesn't seem related to the current work.

ok let's talk

Changes asked by Florent: done

Remaining: playwright fail:

     - waiting for locator('[data-target="library"]')
       at objects/DisplayBuilder.ts:27
      25 |       await expect(sidebarFirst).toBeHidden()
      26 |     } else {
    > 27 |       await toolbarButton.click()
         |                           ^
      28 |       await expect(sidebarFirst).toBeVisible()
      29 |     }
      30 |   }
        at Displaybuilder.toggleSidebarView (/builds/project/display_builder/tests/src/Playwright/objects/DisplayBuilder.ts:27:27)
        at Displaybuilder.openLibrariesTab (/builds/project/display_builder/tests/src/Playwright/objects/DisplayBuilder.ts:41:7)
        at Displaybuilder.dragElementFromLibraryById (/builds/project/display_builder/tests/src/Playwright/objects/DisplayBuilder.ts:68:5)

Hi Jean

I am sorry to send the issue to you with a playwright fail but i am not reproducing it locally. Switching back to RTBC because checked by Florent.

However, it is very important to merge #3549266: Move DisplayBuildableInterface to a new plugin type before this one because they may conflict. I am OK to do the rebase my self if conflicting.

Ok thanks, i am having a look.

Aside the playwright fail, there is something else to check before sending to review:

• there is always a single Layout Builder Override per bundle: the default display stored in OverridesSectionStorage::FIELD_NAME
• there could be many Display Builder Override per bundle, one for each display stored in whatever ui_patterns_source field

Now, we are importing from Layout Builder Override when we are initializing data for any Display Builder Overrides. Maybe we need to check the display entity ID is the same in both (so it will work only for default).

only playwright left :)