The Drupal platform that I manage now is the product of a number of developers, each with their own philosophy on how things should function. In the mix we had custom block types, Layout Builder, CKEditor 4 widgets, one Lit-based widget, and a variety custom modules to support them.

Content managers had varying levels of success creating page layouts with Layout Builder, and most reported that it was hard to understand. In most cases editors were merely inconsistent, inserting incorrect navigational elements or completely removing them; in the worst cases they created security and accessibility violations. WordPress and Squarespace were repeatedly mentioned by users who found their admin experience to be much better than Drupal’s. Atop these concerns, there had been at least two releases of our design system and the Drupal 10 upgrade still looms.

Editing experience options

I am a strong advocate for doing as much with Drupal core as possible, but struggle with finding a way to satisfy all the stakeholder needs using Layout Builder. One component proved particularly tricky—that damned carousel. I tried out many Layout Builder additions, and polled my developer friends. Some suggested custom entities for the slides but most asked, “Why wouldn’t you use Paragraphs?” Sigh.

With D10 coming we would have to update or replace our CKE4 widgets, and going all-in on CKE5 was a consideration. However, because of some serious feature-parity challenges and my mistrust of the commercial ambitions of CKSource, this didn’t feel right either.

We could also leverage Layout Builder more deliberately and attempt to improve the user experience there. This was my first inclination, but I kept hitting roadblocks with repeatable elements (e.g., the carousel and accordions), and the need for nested layouts. Yes, we could have solved those issues in a more-Drupally way. But the development resources I have available are not typically seasoned Drupalists, so eliminating the back-end overhead seemed wise.

One of our companion units reported success rolling out Layout Paragraphs. The feedback from their users was that it was a better admin experience, especially in that it gave them a more representative WYSIWYG layout-building process.

Settling on Paragraphs

I begrudgingly made the choice to move away from Layout Builder, and convert our components to Paragraphs and layout engine to Layout Paragraphs. It was driven by the notion that the layout- and component-building process needed to be as standardized as possible for the developers, and easily understood for our various content editors.

I could replace the CKEditor widgets and most of the custom blocks with a familiar entity type, and end users could build layouts and insert components in a friendlier interface. Developers can create additional components and share them more easily within our organization, with less development overhead. And most importantly, the content data will remain structured, meaning that I can re-extract and convert it again later to another model or even a different CMS.

The implementation wasn’t without its own challenges. I was close to launching the experimental Layout Paragraphs Builder widget when it was discovered that it wasn’t observing our content moderation rules—a major blocker. I never really liked that editors still needed to go to two screens to edit a page, just as with Layout Builder. So I arrived at using the standard Layout Paragraphs widget on the edit form, but pull in the site theme so elements look almost identical to the published page.

I feel it was the right choice given my unique circumstances. Still, it feels rather dissatisfying that the Drupal-native option wasn’t the obvious solution.