[1.0.0-alpha2] Add content display overrides

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

pdureau → credited just_like_good_vibes → .

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.

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