Enterprise Drupal
website development
in Philadelphia

Sooner or later every Drupal project meets the same request. Editors want to build pages from blocks, move sections around and add a new layout without calling a developer. Drupal offers two main ways to do this, and the choice shapes the site for years.

Paragraphs is a contributed module that adds structured components to a content type. An editor adds a text section, then an image with caption, then a quote, then a call to action. Each component has fixed fields and a fixed design. The page is built as a stack, from top to bottom.

Layout Builder is part of Drupal core. It lets editors place blocks into sections with columns, either as a default layout for a whole content type or as an override for a single page. It is closer to visual page building, with more freedom over arrangement.

Paragraphs keeps content structured. Because each component is a set of fields, the content can be reused, exported to an app or moved to another system with little loss. Design stays consistent, because editors choose from a menu rather than arrange things freely.

Layout Builder gives flexibility that marketing teams often want for landing pages and campaign content. The cost is that layout and content become mixed. Overrides on individual pages are hard to update in bulk, and a design change may need editing page by page.

Performance and accessibility matter here too. Both approaches can produce heavy markup if components are poorly designed. Deeply nested sections with many blocks slow the editing screen as well as the public page.

Many sites use both. Standard content types, such as articles, events and staff profiles, use fixed templates with Paragraphs for the body. A limited set of landing pages uses Layout Builder, with a small library of approved blocks.

Governance decides whether either approach works. Somebody must own the component library, decide when a new component is justified and remove ones nobody uses. Without that, the library grows to dozens of near duplicates, and editors pick at random.

Migration is the other long term question. Content in Paragraphs moves cleanly between Drupal versions, and there are established migration paths. Layout overrides are harder to carry forward and often need manual rework.

Test the choice with real editors before committing. Ask them to build three typical pages. Where they get stuck, and where they ask for freedom, tells you more than any feature list.

Editorial training should follow the decision. Editors need a short guide that shows each component, where it fits and where it does not. Examples of good pages help more than written rules. A guide that lives inside the editing interface, as help text next to each component, gets read far more often than a document stored somewhere else.

Revisions and translations deserve a check before choosing. Both approaches handle revisions, but the way layout overrides interact with translations can surprise teams. A multilingual site should test the full flow, from creating a page to translating it and publishing a new revision, before committing to either model.

Accessibility belongs in the component itself. Headings, image alternatives, colour contrast and keyboard behaviour should be designed into each block once, so editors cannot accidentally break them. A component that lets editors choose any heading level or any background colour will eventually produce pages that fail basic checks.

Front end performance should be measured with real content. A component that looks light in a demo can become heavy when editors add large images, embedded video and several nested sections. Testing a few of the longest real pages, on a mid range phone, shows whether the chosen approach holds up in daily use.

Finally, plan for change. The library of components will grow and some will be retired. A simple process for deprecating a component, finding the pages that use it and moving them to a replacement keeps the site consistent over years rather than months.

Content editors are not the only users of these tools. Designers need a place to preview every component in every state, and developers need a way to test changes without breaking live pages. A component gallery page, built with the same blocks as the real site and kept up to date, serves both groups and shows quickly when something has drifted.