[1.0.0-alpha2] Add content display overrides

Created on 9 June 2025, about 2 months ago

Problem/Motivation

Now we have a:

  • a (WIP) entity view display integration in display_builder_entity_view
  • an experimental ui_patterns_field sub-module in UI Patterns 2

We can start working on content display overrides

Proposed resolution

Implement it like layout builder. With a "Display" tabs, instead of a "Layout" tab, in the entity edit tabs.

Locked / unlocked sub trees

Can we implement a layout_builder_lock like mechanism?

Layout Builder Lock allows administrators to lock sections of a default layout so users can't perform certain actions when overriding the layout for an individual entity.

Because we work on tree structure instead of flat sections, it is best described like that:

the ability to lock/unlock slots and component subtrees allows the Site Builder to define the creative freedom of the Content Creator on a per-content type basis, which is another way of saying: controlling how rigid/consistent/enforced the layouts are.

It may be a new "special" State property of the display builder, alongside _instance_id & _third_party_settings.

Translation

What do we decide?

  • Symmetric translations: The translations have the same state data tree, but some values (mostly strings…) need to be translated.
  • Asymmetric translations: The translations can have different data trees. The simpler solution.

Anyway, translations mechanisms must be implemented and managed at StateManager level and be the same for content display overrides and other translations uses cases (config translation of displays, of views...)

An override by display?

Layout Builder is allowing only the override of default display. I beleive Experience builder has not reached the moment they need to thing about that yet.

What do we do?

Restrictions

No need for a mechanism like layout_builder_restrictions or layout_builder_restrictions_by_role because it will be managed by the intersection between:

📌 Task
Status

Active

Version

1.0

Component

display_builder_entity_view

Created by

🇫🇷France pdureau Paris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @pdureau
  • 🇫🇷France pdureau Paris

    You may need the Content context planned for UI Patterns2: [2.1.0] Add a ContentBlock source for slots with a Content entity context Active
    Also discussed in 📌 Align source contexts Active

  • 🇫🇷France pdureau Paris

    Discussed with just_like_good_vibes:

    Override a full display

    we can override any display (not only the default one like Layout Builder), where do we put the information than this field override this display ?

    We store this information in the ui_patterns_source field instance config, so not in the content. So, it is up to the site builder to decide this.

    However, how do we know if the field is effectively used for override by the contributor?

    • If we rely on ListInterface::isEmpty(), how do we know for sure an empty ui_patterns_source field will empty the overridden display or will do nothing?
    • Do we add a new boolean field property in ui_patterns_source to tell if the field is used for override or not?

    None of those options is OK for just_like_good_vibes but the debate is ongoing.

    About tabs: instead of "Displays" with a sub-tab for each display, do we flat the list with "Display: Card", "Display: Full"... ?

    Use your content field in a slot

    How the widget will be rendered in entity form display? An iframe in order to get the front theme in the admin theme?

    A link to a display builder page, like in Display Builder Views.

  • 🇫🇷France pdureau Paris

    However, how do we know if the field is effectively used for override by the contributor?

    I would prefer to rely on ListInterface::isEmpty() because i don't see the

    When we will be decided, the scope of this issue may be only:

    • a new display_builder field widget plugin for ui_patterns_source
    • a new override optional string enum setting in ui_patterns_source instance or storage
    • a mechanism to generate automatically tabs in content view/edit/delete tabs

    however, what is happening if 2 fields are override the same display?

    Oops! We need to address this too :) Christian prefer to store the link between a display and a display_builder field in the entity view display config entity instead on the ui_patterns_source instance or storage

    So, if we do that, we will need:

    • a new display_builder field widget plugin for ui_patterns_source
    • a new overriden_by optional string enum setting in entity view display config entity
    • a mechanism to generate automatically tabs in content view/edit/delete tabs
  • 🇫🇷France pdureau Paris
Production build 0.71.5 2024