Needs work
Project:
Display Builder
Version:
1.0.x-dev
Component:
display_builder_page_layout
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
22 Jul 2026 at 16:59 UTC
Updated:
28 Jul 2026 at 09:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
pdureau commentedstarted
Comment #4
pdureau commentedDone.
The phpstan fails are probably not related to this work.
Comment #5
mogtofu33 commentedA rebase should fix ci.
Comment #6
pdureau commentedIndeed
Comment #7
mogtofu33 commentedComment #8
mogtofu33 commentedFrom User experience perspective, Page Layout seems confusing:
Then you have this 'Page Layout (from active theme)' with slot based on regions.
Obviously the user experience is confusing on creation and after. We need to facilitate adoption, not create strange unexplained behaviors.
Page Layout source was created as a way to merge existing block layout configuration so user do not have an empty page. But then we create a unexplained component with regions without real markup.
And problem is worst when using a proper theme with layout components, you basically on every new Page Layout have to remove the page layout to build your page.
What can we do to fix that and remove confusion?
Comment #9
pdureau commentedThanks for the review.
Review
The source plugin label is "Page layout (from active theme)", it may not be the best label, but I don't have better idea right now. Do you?
That's the point, this source plugin is the exact representation of the rigid, hardcoded, not configurable,
page.html.twig.Oh! Really? That's a bug, i will a have a look.
Styles: As far as I know,
page.html.twigdoesn't haveattributes, but UI styles is supposed to manage this.Visibility: Weird.
I will have a look.
UX improvements
I agree there is something to consider here. The automatic initialization with this PageLayoutSource plugin is relevant for the projects keeping Block Layout as a fallback/default. But not for the projects already using a Page Layout entity without any condition plugins set as a fallback/default.
Today, this situations is managed by:
But we can do better.
I am afraid those proposals are not fixing the fallback/default pages dichotomy because:
To improve the UX, we can make this choice more obvious by exposing it directly in the creation page (and not the edit page) of the config entity type:
Screenshot:

What do you think?
Comment #10
pdureau commentedDiscussed with Jean.
Review:
UX improvements:
Comment #11
pdureau commentedReview
Styles are using the "drilling" system of UI Styles which is sometimes working weird because the Drupal Render API is weird.
For example, with UI suite DaisyUI, it drills until the navbar slots.
So, to have a consistent behavior, I have wrapped the renderable in a
html_tagwhich will host the styles and other dynamic attributes.For visibility, I don't see surprising behaviour in Preview and final result. But I see weird stuff in Builder/Canvas: the renderable is not rendered anymore, that's normal, but the children are. Not being familiar with Visibility panel, i don't know if it is OK, but it doesn't seem something introduced by the current work which is fixing already a lot.
UX improvments
The create form page will be discussed after beta6.
Comment #12
mogtofu33 commentedTest KO ❌
return $page;Comment #13
pdureau commentedOh shout! you are right.
The current state of the MR is not working with every theme:
I will do a change, test with all themes I have available, so i will send to review only when i am 100% sure.