What is the problem to solve?
Site builders find it challenging to configure Drupal's page building experience in a way that meets the requirements of content editors, who are accustomed to using flexible and easy-to-navigate tools. In many cases, this means site builders or other more technical users remain responsible for building pages.
Specific issues:
- Dependency on multiple contributed modules: Site builders currently have to rely on a large number of contributed modules to make the Layout Builder experience good in a production environment. This complicates the setup process, introduces compatibility issues, and increases the maintenance overhead.
- Key challenges site builders try to address
- Several challenges with the current off-canvas UX, most notably users are not aware that the dialog can be resized and numerous bugs in styling of elements inside the dialog.
- List of available blocks is overwhelming, need to restrict available options
- Scalability issues when the site has a large number of fields / blocks on the site
- Block configuration is not well understood by editors. Some options are too granular, and should be configured on a site level. Site builders want to be able to provide pre-configured blocks.
- Translation support.
- Not enough flexibility to use existing content as a starting point.
- Editing capabilities, e.g. nested sections or section reordering are missing.
- Subpar user experience for content editors: In usability tests, users who are otherwise familiar with Drupal fail to accomplish basic tasks in Layout Builder. Even after configuration of numerous contributed modules, the content editing experience does not meet the expectations of editors.
- Key challenges related to the user experience that are not solved by the above contributed modules:
- Editing happens on multiple pages (Edit vs Layout)
- Copy-pasting content from page to another is not possible
- The UI is clunky and there are limited options for editing content.
- In order to change from single column to two column layout, a new section needs to be created and content needs to be moved over manually.
- It is not clear through the UI, what some of the content is.
- Reverting incremental changes is not easy, especially when the taken action isn't well understood.
Result: what will be the outcome?
Page building experience that:
- Combines the strengths of structured content with modern page building tools.
- Has a user experience that is intuitive and empowers content editors to easily create, modify and manage content.
- Supports common scenarios needed in production sites without requiring contributed modules.
Proposed resolution
- Allow editing structured data as part of the page building experience
- Site builders lock sections that are not being editable by editors, e.g. a pre-defined hero section.
- The pre-configured sections can contain unstructured and structured content
- "Unstructured data" is edited using a powerful block based text editor.
- Editing both types of content can be done on a single page, while keeping site builders able to leverage the power of structured data, like being able to customize several display modes.
- Introduce new concepts for pre-configured blocks and sections
- The available building blocks are configurable by the site builder. This ensures that what is visible for the editor is intended to be used on the site.
- Editors do not need to configure settings that are irrelevant to them, e.g. selecting a date format should be done by a site builder, not by an editor.
- Enable editors and site builders to store pre-configured sections to make creating new content faster and easier
- User experience that is more in line with text editors. This is an approach that is being used by the majority of the competing page building experiences and has become the industry standard.
- Think of copy and paste, drag and drop, and keyboard shortcuts instead of clicking through an UI.
- More interactive interface that enables content editors to build pages without a significant onboarding effort.
- Undo/redo for actions taken through the UI.
- Fast, visually appealing, and joyous to use.
- Provide more flexibility to change sections after they have been created
- Either allow changing from a section type to another, or replace the simple default section types with a new section that enables editors and site builders to configure the number of columns while editing content.
- Allow reordering sections.
- Both types of Layout Builder translations supported out-of-the-box with Drupal
- Allow selecting per-content type whether translation is asymmetric (separate layout per language) or symmetric (same layout but translated).
Wireframes
Note: these wireframes are intended to be used for describing the vision, not to be considered as the final UX.
Figma wireframes
Video mockup from DrupalCon Lille 2023 Keynote
How can we know the desired result is achieved?
- System Usability Scale (SUS) and task-level satisfaction measurements
- Reduce the number of required contributed modules
- Increase adoption of the core page building solution
Process and where to find it
Work is happening on several tracks:
You can join us in Drupal Slack #layouts channel.
Comments
Comment #2
lauriiiComment #3
damienmckennaIt might be useful to get a list of the 15 modules identified so that then we can itemize the functionality they provide and possibly look to recreate that functionality in core.
Comment #4
larowlanWe've kind of done that in #3361359: [META] Layout builder editorial improvements 👍
Comment #5
lauriiiUpdating the issue summary with more details and a proposed solution.
Comment #6
carlitus commentedIn case it helps you I comment some alternatives to the layout builder to have a page builder that I believe that they have very interesting points.
Mercury Editor:
This is what we are currently using. It is very intuitive and usable. Our customers have seen a big jump compared to layout builder.
It doesn't use layout builder, but layout paragraphs.
https://www.drupal.org/project/mercury_editor
https://www.youtube.com/watch?v=OVCPu4_ZtzE&ab_channel=AtenDesign
It uses style options which allows to specify in a single yml file properties like Layout Options. Very useful to be able to pass this configuration to other sites, for example new developments.
DXPR:
https://www.drupal.org/project/dxpr_builder
They have also dedicated a lot of effort to make it usable, with many customization options.
It is paid with subscription.
Comment #7
chris matthews commentedFWIW, I've been using DXPR Builder (and theme) for a while now and it's a really polished, fully Drupal integrated page builder. Demo here: https://try.dxpr.com/
Edit: there is also a free tier plan.
Comment #8
johnpitcairn commentedRelated to that: #3204494: Content Not reverting in Layout builder section
Comment #9
catchLinking some existing core issues for this, which have been getting closer to a solution recently:
#3387154: [PP-1] Move away from derivatives for FieldBlock and instead use block settings
#3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points
#2940755: block_content block derivatives do not scale to thousands of block_content entities.
Comment #10
dalemoore commentedIs the Decoupled Layout Builder intended to replace the current Layout Builder, or is it its own separate thing and there would be no upgrade path for it or anything like that (basically those of us creating sites with LB must start over)? Where does recently created things like SDC fit into it? Since SDC relies on Twig templates. Is this new DLB abandoning Twig in favor of React? I have questions 😅
Comment #11
larowlan@dalemoore the decoupled layout builder is an experimental project as part of the Pitchburgh innovation contest. It is only replacing the editing of layouts and its data-model is compatible with the existing layout builder data-model. It doesn't do anything for the display of the content, only for editing. So if you're using Twig etc for the presentation, it will still do so. If the markup from the decoupled LB in edit mode doesn't match that of your twig templates, you will be able to swap in a different React component so it looks closer to the final product. There is no intention of ditching Twig for react that I'm aware of.
There are other proposed approaches to this idea as well, i.e. the decoupled react one is just one option. The others are improving the existing one (see #9 for some links), using Gutenburg (another pitchburgh project) and other contrib options like LB Plus.
Comment #12
dalemoore commentedThanks @larowlan. That gives me some sense of relief. I was afraid we were really just getting started with LB in my org only to have to change to something else.
I can say whatever gets us closer to what’s possible in Gutenberg/Block Editor in WordPress I’m 💯 in favor for!
Comment #13
ressaAdding link to @lauriii's Layout builder mockup at DrupalCon Lille 2023 Keynote in Issue Summary. It looks awesome.
Comment #14
crzdev commentedIncluding Visual Layout Suite (VLSuite) https://www.drupal.org/project/vlsuite for ambitious site builders approach ready to use right now, in which we put much effort, please take a look, recently out 1.1.1 stable with many improvements from 1.0.x, thanks!
Keypoints are:
Demo & related conferences (1.1.x & 1.0.x):
Comment #15
lauriiiThe problem itself has been validated and Dries announced building a solution for this as a strategic initiative for Drupal in his keynote at DrupalCon.
During DrupalCon, several people worked on documenting pro's and con's of the existing solutions. There's also a list of contributed modules, and module setups that could be used as an inspiration. There's also a list of prioritized user stories for the page building tool.
The next step is to find initiative coordinators and to start defining a plan for this.
In the meanwhile, we are doing deeper analysis on some of the available open source projects like GrapeJS, Gutenberg, and puck to understand if there are anything we can reuse or learn from them.
There's lots of prior art to improving Layout Builder, and we are hoping to find a way to let the broader community leverage some of these in the short term. One idea was to build a community "recipe" that installs targeted contributed modules on top of Layout Builder, to have a more opinionated starting point.
Comment #16
ressaI think this would fit under a "Ambitious Site Builder" tag?
Comment #17
juc1 commentedI agree that the current Layout Builder UX is horrible, for example the URL separation between field content = /node/50/edit and layout = /node/50/layout, and that Drupal needs a modern page builder.
Here is this problem mentioned in an old blog post from 2020:
I wish that the wheels at Drupal HQ turned more quickly but it is great to see some progress.
Comment #18
juc1 commented@larowlan thanks for the detailed Pitchburgh updates on your blog. So is it possible that your Pitchburgh work could be adopted by the core team? Or if not could it become a contrib module?
Comment #19
larowlanYep the Drupal bits are in decoupled_lb_api and the npm bits in decoupled_lb projects
Comment #20
user654 commented.
Comment #21
fabianx commentedHello there!
At Tag1 we have been hard at work to create a drop-in replacement for the Layout Builder UI, which is fully compatible with all existing contrib modules and used by our Enterprise clients already for a while in production.
It essentially changes the experience in three key points:
It's called lb_plus and can be found here:
https://www.drupal.org/project/lb_plus
Here is a quick GIF to show how it works in action:
Some more detailed description by Tim Bozeman, who wrote the second version of lb_plus follows:
Like larowlan said, we've been working on a drop in replacement for the Layout Builder UI that addresses many of these issues. There has been interest in adding LB+ to core also.
lauriii said:
I think LB+ can help fill the gap.
Features include:
Click here to see LB+ in action!
Comment #22
juc1 commented@lauriii is there any progress to report since your first post 7 months ago?
Two things I am hoping for =
live CSS on the edit page:
browsable component libraries in the page builder UI:
Comment #23
juc1 commented@larowlan did the core team reply to you about your Pitchburgh work https://www.previousnext.com.au/blog/pitchburgh-diaries-decoupled-layout... such as they will / will not adopt it?
Comment #24
dalemoore commentedI would be interested in where this is headed too. I'm about to embark on redesigning our "flagship" website and picking something, whether it's Layout Builder, Layout Paragraphs, or some new thing that we can be sure will be around for a while would be helpful. WordPress has mostly moved to the Block Editor/Gutenberg, if we could standardize on something (while still allowing others to go their own way) it would help a lot of us on small (or, er, mostly one person >_>) teams.
Comment #25
larowlan@Juc1 @lauriii has been doing evaluation of options and decoupled LB was in the mix.
Comment #26
juc1 commented@larowlan yeah I was just wondering if there was any progress yet, with Drupal 11 approaching.
Comment #27
larowlanNot at this stage. For what it's worth, we don't have to wait until major releases to add new features
Comment #28
juc1 commented@larowlan ok thanks, no reply from @lauriii yet but this recent blog post https://www.thedroptimes.com/38267/drupal-page-builders-part-1-paragraph... says it could be another year before page builder improvements get into core. it is depressing to me that Drupal core can move so slowly, like a snail, and I have lost some Drupal clients to Wordpress because they have seen modern page builders with features such as live CSS on other platforms, and I can't explain why Drupal can't do this in 2024.
Comment #29
dmezquia@Juc1 Many entrepreneurs and companies, rather than starting to develop a full application with "Drupal", prefer to launch an MVP and that is where Drupal does not fit, they want to create websites quickly, pages, sections... like no-code apps do.
I think Drupal has not put as much effort into this part because it has been seen by clients for more advanced solutions, not to release quick MVPs.
I think that if a solution could be reached between (Recipes + Single Directory Component SDC + "Better" Layout builder) Drupal would be used much more in other communities that only want to launch Web/MPV quickly to the market.
Comment #30
effulgentsia commentedI opened #3440578: [PP-2] JSON-based data storage proposal for component-based page building which I think is general enough to be able to support any UI we might end up wanting for this.
Comment #31
jmolivas commentedThe off-canvas UX is challenging for sure. There are some work happening at the modules
Decoupled Preview Iframe
https://www.drupal.org/project/decoupled_preview_iframe
Visual Editor
https://www.drupal.org/project/visual_editor
Adding some screenshots related to the OffCanvas

And a link to short demo video
https://www.youtube.com/watch?v=OElix4t3gCQ
Comment #32
quietone commentedThe Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.
Comment #34
bkosborneSeems like this can be closed since Canvas has emerged?