24 Jul 2026
Drupal.org aggregator
Talish Khan: Layout Builder Is Over-Applied: A Decision Framework for When It Actually Fits
The Pattern I Keep Seeing
A team starts a Drupal project. Someone asks how editors will build and arrange page content. Someone else says "Layout Builder," and that is the end of the conversation. Nobody asks what the editors actually need. Nobody asks what the content model demands. Layout Builder gets switched on because it is powerful, modern, and comes with core.
Six months later, one of two things has happened. Either the editors are happily composing layouts and everyone is glad, which is the good outcome. Or the editors are confused by a tool that gives them more power than they wanted, the developers are fighting to constrain a system designed to be open-ended, and the content is inconsistent because thirty editors made thirty different layout choices. That is the bad outcome, and it is more common than the Drupal community likes to admit.
The tool is not the problem. The reflexive selection of the tool without asking whether it fits is the problem.
The Four Options
Before the framework, a quick map of what you are actually choosing between when you decide how editors build pages in Drupal.
Layout Builder. Editors compose pages by placing blocks into regions of a layout, visually, per page or per content type. Maximum flexibility. Maximum editor power. The editor decides the structure.
Paragraphs. Editors add and arrange predefined content components in a field. Structured flexibility. The developer defines the components; the editor arranges them. The structure is constrained by what you built.
Custom templates. The developer defines the layout in Twig and the editor fills in fields. Zero layout flexibility for the editor. Maximum consistency and developer control.
Plain blocks and block layout. Content is placed in regions through the block system, configured by a site builder, largely static across pages. Good for site-wide furniture, weak for per-page composition.
Each of these is correct for some situations and wrong for others. The framework is about matching the tool to the situation.
The Framework: Four Questions
I run every "how should editors build pages" decision through these four questions, in order.
Question 1: Do editors actually need to compose layouts, or do they need to fill in content?
This is the question that settles most cases, and it is the one nobody asks.
If your editors are filling in structured content (an article has a title, a body, an author, a hero image, a set of related links), they do not need Layout Builder. They need well-designed content types with well-designed fields, rendered through templates the developer controls. Giving these editors Layout Builder hands them a layout composition tool for a job that has no layout composition in it. They will either ignore it or misuse it.
If your editors are genuinely composing pages (a marketing team building landing pages with varying structures, arranging components differently per campaign), then layout composition is a real need and Layout Builder or Paragraphs becomes relevant.
The test: watch an editor work, or ask them to describe their job. If the word "arrange" or "compose" or "build" comes up, layout tooling might fit. If they describe "entering" or "updating" or "filling in," it probably does not.
Question 2: How much layout variation do you actually need?
If the answer is "every page can look completely different," Layout Builder is designed for that.
If the answer is "editors combine a fixed set of components in different orders," Paragraphs is the better fit. It gives editors arrangement flexibility without giving them raw layout power they do not need and will misuse.
If the answer is "pages of this type all look the same," you do not need either. Custom templates with fields is the right call, and it will be faster, more consistent, and more maintainable than either flexible option.
Most projects need less layout variation than they think. The instinct is to build for maximum flexibility "just in case." That flexibility has a cost, paid in editorial inconsistency and developer maintenance, and the "just in case" scenario often never arrives.
Question 3: Who bears the cost of flexibility?
Every option shifts cost to a different party.
Layout Builder shifts cost to editors, who now have to make layout decisions on every page, and to developers, who have to constrain and style a system designed to be open. The flexibility is real but so is the ongoing cost of managing it.
Paragraphs shifts cost to developers upfront (building and styling the components) and keeps the editor experience constrained and predictable. Once built, it is low-cost for editors.
Custom templates put all the cost on developers upfront and give editors the simplest possible experience: fill in the fields, the layout is handled.
The question is not "which is most flexible." It is "who should bear the cost of flexibility on this project, and can they?" A marketing team that wants control can bear the Layout Builder cost. An editorial team of subject-matter experts who just want to publish articles cannot, and should not be asked to.
Question 4: How many people will use this, and how consistent does the output need to be?
Flexibility and consistency are in tension. The more freedom you give editors, the less consistent the output.
If three trained content designers are building marketing pages, Layout Builder's flexibility is a feature and the consistency risk is manageable because the team is small and skilled.
If thirty subject-matter experts across departments are publishing content, Layout Builder's flexibility is a liability. You will get thirty interpretations of what a page should look like, and your site will drift into visual chaos within a year. Constrained tools (Paragraphs with a limited component set, or custom templates) protect consistency at scale.
The larger and less design-trained your editorial pool, the more you should constrain their tooling.
The Framework in One Sentence Each
To compress it:
- Custom templates when pages of a type look the same and editors fill in fields.
- Paragraphs when editors arrange a fixed set of components in varying orders.
- Layout Builder when editors genuinely compose free-form layouts and the team is small and skilled enough to manage the flexibility.
- Plain blocks for site-wide furniture, not per-page composition.
Notice that Layout Builder is the right answer for the narrowest set of conditions, not the widest. That is the inverse of how often it gets chosen.
Why Layout Builder Gets Over-Applied
Three reasons the reflex exists.
It is in core and it is visible. Paragraphs is contrib. Custom templates require writing code. Layout Builder is right there in core, promoted, documented, demoed. Visibility drives adoption regardless of fit.
It demos beautifully. The drag-and-drop layout composition is genuinely impressive in a demo. Stakeholders see it and want it. The demo does not show the editorial inconsistency that emerges at scale six months later.
It feels like the modern choice. Choosing custom templates can feel like you are not using Drupal's capabilities fully. There is a subtle pressure to use the powerful tool because it is there, even when the simpler option is correct. Resisting that pressure is a senior move.
Closing Thought
Layout Builder is a good tool. I am not arguing against it. I am arguing against choosing it reflexively, without asking whether the project actually needs page composition or just needs structured content entry.
The four questions above take ten minutes to run and save months of pain. Do editors compose or fill in? How much variation is really needed? Who bears the cost of flexibility? How many people, how consistent? Answer those honestly and the right tool usually selects itself.
The instinct to reach for the most powerful option is understandable and usually wrong. The senior move is to reach for the option that fits, which is frequently the more constrained one. A Drupal site where editors fill in well-designed fields through developer-controlled templates is not a less sophisticated site than one built on Layout Builder. Often it is the more sophisticated one, because someone made a deliberate choice instead of a reflexive one.
If you have shipped Layout Builder on a large multi-editor site and kept it consistent over years, I would be curious how you constrained it. That is the hard case, and the honest accounts of making it work at scale are rarer than the demos suggest.
24 Jul 2026 8:28am GMT
Morpht: Protecting PII in Drupal AI: An introduction to Guardrails
The Drupal AI module's Guardrails system runs configurable validation plugins both before a prompt is sent to an LLM and after a response is received. Guardrails can pass, block, or rewrite content, and can be combined into sets with a scoring threshold.
24 Jul 2026 7:20am GMT