[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

christian.wiedemann → made their first commit to this issue’s fork.

I created a first draft. Lets discuss tommorow.

Hi Christian,

Thanks for the first draft.

Quickly looking, I think we need to introduce interface, like in Layout Builder LayoutBuilderOverridableInterface.

Can we merge ✨ Remove Layout Builder dependency Active before this one please?

Christian,

Can you name your context requirement simply "content" (instead of "display_builder_entity_view_override") in order to be ready for 📌 Align source contexts Active  and ✨ [2.1.0] Add a ContentBlock source for slots with a Content entity context Active ? And also (it is related) add the same requirement to ContentEntitySource so the source plugin will only be visible in entity view display overrides?

When finished, assign the issue to me. I will add the updated documentation before sending it to review.

Let's not forget this:

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

It may not be part of the current MR, we can create a follow-up ticket to deal with that. However, let's make it sure we are not blocking it here

Some parts of the initial goal were moved to beta: 📌 Allow override of displays not build with display builder Active

I am rebasing the MR on another branch https://git.drupalcode.org/issue/display_builder-3529125/-/tree/3529125-...

Rebased and code slightly improved with proper dependency injection on https://git.drupalcode.org/project/display_builder/-/merge_requests/66

Not tested.

I have updated the documentation and the wording of the two forms to make it more inline with Drupal Core "standard":

• Imperative wording instead of casual
• No "click here" link
• A button to load the display builder

https://git.drupalcode.org/project/display_builder/-/merge_requests/62/d...

I will update again the documentation when the review will be OK.

So, the review.

Set the override:

• ⚠️ When I add a source field from the modal or from Feild UI, I have this error: "Text format field is required.". I need to set a default value as a workaround change the WYSIWYG format and uncheck the default. If I forget to uncheck, the override is init from this default value instead of the entity view display.
• ❌ The UI Patterns Source field is visible in Entity Form Display by default and it is preventing the content edit form to be submitted
• ✅ It is not possible to pick the same field in many displays

Use the override:

• ✅ I see the tab(s) with "@display display"
• ❌ However, there seems to be in random order. For example, I have: View, Edit, Default Display, Delete,Teaser display, Revisions
• ✅ the override is init with the value of the entity view display
• ❌ No"Revert" button in State island to revert the content override to the display config, but we can add it in a follow-up issue.
• ✅ When I empty the override and I remove the default value from the field settings, it is falling back to the entity view display
• ❌ "content entity" source is avaialble in overrides (which is OK) but also in enttiy view display config

Advanced use: I have overridden two display (default & teaser) and I put the override field of teaser in the default entity view display:

• TODO: I will do the test after the previous point are fixed or discarded

Topics to discuss:

• Does OVERRIDE_FIELD_PROPERTY constant belongs to ConfigFormBuilderInterface ?
• What about translation? Have you tested?
• What about lock mechanism? it is out of the scope of this issue (we need to create a follow-up but we need to be sure we are not blocking anything)
• What about a default display with both Layout Builder overrides and display builder overrides? Who is winning? Is it the same rules as the entity view display one?
• Do we need to add messages like Layout builder does: " You are editing the layout template for all Basic page content items. " "You are editing the layout for this Basic page content item. Edit the template for all Basic page content items instead."

I will add a second commit with:

• Remove bundle from URL. Example: from /node/3/display-builder/article/teaser to /node/3/display/teaser
• Add the list of overrides for each display in Manage display
• Clean info.yml

Pierre: Little commit to add:

• Some doc update
• "edit' in permission
• Remove the list of overrides
• (without considering layout builder) Check what happen if you activate override in a entity view display, set a override in a content, and then deactivate override

Pierre: To move to a follow-up issue

• The UI Patterns Source field is visible in Entity Form Display by default. Can we disable it by default?
• No"Revert" button in State island to revert the content override to the display config.
• What about translation? Have you tested?
• Do we need to add messages like Layout builder does: " You are editing the layout template for all Basic page content items. " "You are editing the layout for this Basic page content item. Edit the template for all Basic page content items instead."

Christian: To do in the current issue:

• Add a destination parameter in the add field modal
• Tabs seem to be in random order. For example, I have: View, Edit, Default Display, Delete,Teaser display, Revisions >> Maybe having just "Display" tabs and a second row for each display?
• Embedding a display (teaser) in the other (full/default) with the ui_patterns_field's: Render Source formatter. None of them are overridden: I don't see the teaser
• Permissions: We add a Profile selector alongside the Field selector (mandatory, so no possible to pick none). If an user has both the entity.edit permission and the permission related to the chosen Profile, it can do the override.
• The logic in DisplayBuilderSubscriber::onSave() is not clear. Why are there 3 calls to saveSources() >> Maybe a merge error. Need to be fixed. also, we have the same getContextRequirement value in the 2 cases.
• Play with Layout Builder: activate both for config, both for override. Desactive one, active again, desactive both... You may find bugs to fixes.

Follow-up tickets: 📌 Improve content display overrides Active  & 📌 Add "Revert" button in State island Active (and the already existing ✨ [1.0.0-alpha2] Add "content edit" panel Active )

Tabs seem to be in random order. For example, I have: View, Edit, Default Display, Delete,Teaser display, Revisions >> Maybe having just "Display" tabs and a second row for each display?
>> I moved them under to an extra tab Display. Not sure how to sort type should be used. Maybe there is a weight. Did not investigate it right now.

Embedding a display (teaser) in the other (full/default) with the ui_patterns_field's: Render Source formatter. None of them are overridden: I don't see the teaser
>> Not checked right now

Permissions: We add a Profile selector alongside the Field selector (mandatory, so no possible to pick none). If an user has both the entity.edit permission and the permission related to the chosen Profile, it can do the override.
>> Add new select field and use it as profile for overriden tabs.
>> Permissions are check in the custom permission handler

The logic in DisplayBuilderSubscriber::onSave() is not clear. Why are there 3 calls to saveSources() >> Maybe a merge error. Need to be fixed. also, we have the same getContextRequirement value in the 2 cases.
>> I removed the last saveSources call.

Play with Layout Builder: activate both for config, both for override. Desactive one, active again, desactive both... You may find bugs to fixes.
>> Works now

I think "display_builder_entity_view/src/EventSubscriber/DisplayBuilderSubscriber.php" is still wrong. Make sense that someone else has on eye on that for review.

Rechecking what was already OK

TODO

Checking the new fixes

Add a destination parameter in the add field modal

Was it forgotten?

Tabs seem to be in random order. For example, I have: View, Edit, Default Display, Delete,Teaser display, Revisions >> Maybe having just "Display" tabs and a second row for each display?
>> I moved them under to an extra tab Display. Not sure how to sort type should be used. Maybe there is a weight. Did not investigate it right now.

✅ the second row of tabs is visible only if there is more than one override.

✅ It is in alphabetical order, like in Display Modes and Manage Display pages.

Embedding a display (teaser) in the other (full/default) with the ui_patterns_field's: Render Source formatter. None of them are overridden: I don't see the teaser
>> Not checked right now

TO CHECK

Permissions: We add a Profile selector alongside the Field selector (mandatory, so no possible to pick none). If an user has both the entity.edit permission and the permission related to the chosen Profile, it can do the override.
>> Add new select field and use it as profile for overriden tabs.
>> Permissions are check in the custom permission handler

I have 2 profiles: default & devel.

I have set the override profile to "devel" and tested with 3 users:

• one with the permission of using all display builder profiles and node.edit >> ❌ "Access denied"
• one with the permission of using only the default profile and node.edit >> ❌ "Access denied"
• one with the permission of using only the default profile but not node.edit✅ "Access denied"

The logic in DisplayBuilderSubscriber::onSave() is not clear. Why are there 3 calls to saveSources() >> Maybe a merge error. Need to be fixed. also, we have the same getContextRequirement value in the 2 cases.
>> I removed the last saveSources call.
I think "display_builder_entity_view/src/EventSubscriber/DisplayBuilderSubscriber.php" is still wrong. Make sense that someone else has on eye on that for review.

I will ahve a look.

Play with Layout Builder: activate both for config, both for override. Desactive one, active again, desactive both... You may find bugs to fixes.
>> Works now

Great. Thanks for the check. I will not check again.

pdureau → changed the visibility of the branch 3529125-no-more-lb-dependency to hidden.

grimreaper → closed merge request !66

✅ OK, finally, I did the fix about permissions in https://git.drupalcode.org/project/display_builder/-/merge_requests/73

Embedding a display (teaser) in the other (full/default) with the ui_patterns_field's: Render Source formatter. None of them are overridden: I don't see the teaser

Will be moved to a follow-up ticket.

Some last checks before review.

Hi Jean,

This issue for review: rebased & cs-fixer executed (except ordered_class_elements on 2 files to not mess with the diff).

The work will continue in beta with the follow-up issues:

• 📌 Improve content display overrides Active
• 📌 Add "Revert" button in State island Active
• ✨ [1.0.0-alpha2] Add "content edit" panel Active
• Embedding a display in an other with the ui_patterns_field's Source field.
• Remove EntityViewDisplay::getDisplayInfos

pdureau → changed the visibility of the branch 3529125-add-content-display to hidden.

Thanks for the work, added tests and some minor refactoring.
We are at the edge of using too much trait instead of abstract or services,this makes reading and tests harder to write, and ide failing completion. To discuss.