Back in 2022, we upgraded an existing brochure-style site from Drupal 7. The project has been running in different forms for many years and has accumulated a few architectural ideas that worked well, as well as others that needed reconsideration.
This is the first in a series of posts about things I learned while rebuilding and further developing that site.
The existing editing workflow
Most of the information displayed on the site comes from external data sources. Instead of writing and formatting narrative content, editors select from a library of data-driven widgets. These display maps, charts, lists or key figures and provide a limited set of configuration options.
The target audience consists mainly of non-technical editors. They need to decide what kind of information a page should provide, but not how that information is retrieved or rendered.
The Drupal 7 version used Panels and Panels IPE for this. Editors opened the page they wanted to change, activated the editing mode and arranged the available widgets directly on the frontend.
We wanted to keep that workflow after the upgrade.
Paragraphs or Layout Builder?
Paragraphs were one of the options we considered.
Each widget could have been represented as a Paragraph type, while Layout Paragraphs provided sections and a visual interface for arranging them. Combined with Geysir, this could also have provided frontend controls and modal forms for individual components.
That approach works well when components contain editor-managed text, images or other structured content. But it would also have made every widget instance a content entity referenced from a field on the page, with its own entity and revision lifecycle.
Our widgets were application functionality implemented as block plugins. They retrieved externally managed data and rendered a particular view of it. An individual placement only needed to store configuration such as which data to show or which display variant to use.
Layout Builder could store that configuration directly with the layout, while sections and regions represented the page structure. It also allowed us to use the same widget library for per-entity layout overrides and Page Manager layout variants.
With Paragraphs, the composition would have belonged to a field on a content entity. With Layout Builder, it belonged to the page display. That matched our use case better.
Missing in-place editing
Layout Builder provided most of what we needed, but not the frontend workflow we had with Panels IPE.
To edit an individual layout, editors normally use the Layout tab. That meant keeping Drupal's local tasks visible or providing another way to reach the same administrative route.
We didn't want the local tasks on this site. The View, Edit and Layout tabs interfered with the brochure-style frontend and gave administrative functionality more prominence than it needed. Non-technical editors should normally see the same page as other visitors. The editing interface should only appear when they deliberately activated it.
The problem was particularly visible with Page Manager pages using a Layout Builder variant. Their layouts could only be edited through Page Manager's administrative wizard, using the administration theme. Blocks styled by the frontend theme couldn't be previewed in their actual context.
There was already a Page Manager issue about making Layout Builder variants editable using the frontend theme. In January 2022, I commented that even previewing the blocks with frontend styles, perhaps in an iframe, would already help. At that point, I wasn't sure where to start.
A week later, I had started experimenting with a frontend-style editing approach inspired by Panels IPE and linked the new Layout Builder IPE project in the same issue.
Instead of adding another project-specific workaround, I tried to keep the solution generic enough for regular entity layouts as well as Page Manager layout variants.
Loading Layout Builder on the frontend
Layout Builder IPE adds a Customize link at the bottom of supported pages. Clicking it replaces the rendered content area with the Layout Builder interface while keeping the surrounding frontend page in place.
This allowed us to completely hide the local tasks. Editors normally see the finished page. When they want to change its composition, they activate Layout Builder, configure the widgets they need and arrange them in the available regions.
Using the frontend theme was important. Maps, charts and other widgets can be previewed with their actual width, spacing and surrounding styles instead of inside the administrative theme.
The module loads the complete Layout Builder workflow rather than only exposing edit links for individual widgets. Layout Builder keeps configuration changes in temporary storage until the complete layout is saved. Updating and persisting individual widgets separately would require custom handling of the section storage, entity override and temporary data. I later outlined the underlying steps in this Drupal Answers post.
Using the complete interface allowed us to keep Layout Builder's existing storage and save workflow.
Keeping the interface lean
Layout Builder IPE supports Gin Layout Builder and Layout Builder Modal out of the box. We use both to provide a relatively lean editing interface.
Core's narrow off-canvas tray has been a long-standing usability problem for larger block configuration forms. Layout Builder Modal opens these forms in a modal instead, providing considerably more space and placing the form in the center of the screen.
The modal covers most of the page and focuses the editor's attention on the configuration without taking them out of the frontend context.
Editing sessions and locking
Layout Builder uses shared temporary storage by default. When two people edit the same layout, they can see each other's unfinished changes. This is also documented in the long-running core issue Concurrent editing of layouts is very confusing.
We decided to add separate work-in-progress sessions per user and later added optional content locking. This prevents editors from seeing or overwriting each other's unfinished changes. Users with the necessary permission can break locks left behind by abandoned sessions.
Conclusion
The Drupal 7 version had already given us a useful editing model: Non-technical editors composed pages from a controlled library of data-driven widgets directly on the frontend.
Layout Builder provided the right foundation for carrying that model forward, but lacked the in-place workflow we had with Panels IPE. Layout Builder IPE grew out of filling that gap without building the solution specifically into a single project.