Drupal + Gutenberg: Not a Match Made in Heaven, But Full of Potential
#drupal#gutenberg#cms
Wendy Stocker

Wendy Stocker @wstocker

About: PHP code monkey.

Joined:
Mar 21, 2018

Drupal + Gutenberg: Not a Match Made in Heaven, But Full of Potential

Publish Date: Jun 21
2 3

When Gutenberg was introduced to WordPress in 2018, it fundamentally redefined how content is created and structured. Instead of working within a large, monolithic WYSIWYG field, Gutenberg brought a block-based editing experience allowing users to compose rich content layouts using reusable and configurable blocks. This shift empowered editors and site builders alike, introducing modularity without requiring full developer involvement for every content change.

Gutenberg in WordPress: The Block Revolution

The block-based philosophy behind Gutenberg aligns closely with the field-based system of WordPress. Each content type in WordPress comes with a pre-defined set of fields, but Gutenberg blurred those lines by making layout and content structure part of the same visual experience. Blocks could be text, images, galleries, buttons even entire templates. For WordPress, it was a unification of content and layout.

Enter Drupal: A Field-First, Structured CMS

Drupal, on the other hand, is a highly structured CMS. Its field API allows site builders to define complex data schemas across content types. Views, display modes, and entity reference fields offer powerful ways to organize and reuse content. Editors work within these constraints to ensure content is consistent, reusable, and structured for downstream uses (like search, APIs, or layout builders).

One of the biggest complaints among Drupal content editors is the lack of a truly flexible, drag-and-drop editing experience. While tools like Layout Builder have made progress, the editing flow can still feel fragmented, rigid, or overly complex especially for non-technical users. The expectation set by modern page builders and editors (like Gutenberg or Elementor) has raised the bar for intuitive content composition.

Integrating Gutenberg into Drupal

In recent years, the Gutenberg module for Drupal has aimed to bring the same visual block editing experience into the Drupal ecosystem. The module allows developers to plug the Gutenberg editor into any content type, making core WordPress blocks available inside the Drupal UI with relatively minimal configuration.

This plug-and-play capability is surprisingly effective. You can quickly enable Gutenberg for any content type, and start composing content with drag-and-drop blocks including custom blocks or even blocks backed by Views (e.g., EVA blocks). This opens up exciting possibilities for combining Drupal's powerful data architecture with the expressive editing experience of Gutenberg.

The Field Mapping Problem

However, a key challenge quickly emerges: field mapping.

Within Drupal, when you add blocks via the Gutenberg UI, all that block content is stored in the body field of the node. This fundamentally diverges from Drupal's field-based architecture. Although the module supports some field mapping, it's limited. Entity reference fields, view modes, and other structured content types are often left out of the equation.

This can lead to duplication of content maintaining one version in a reference field (for APIs, theming, Views, etc.), and another version as raw Gutenberg content inside the body field just for the editor experience. It’s not ideal.

Enhancing Integration: Gutenberg Content Embed

To help bridge the gap between Gutenberg’s visual editing capabilities and Drupal’s structured content system, the community has also introduced the Gutenberg Content Embed module. This module provides a set of custom Gutenberg blocks that allow editors to embed Drupal entities like nodes, media, or users directly within the Gutenberg editor.

Rather than copying and pasting content into a generic block or recreating it manually, this approach lets editors reference existing Drupal content dynamically. It's a step toward more seamless integration between Drupal's structured backend and Gutenberg’s visual frontend.

However, while it helps bring entity-based content into the editing canvas, it still doesn’t fully solve the field mapping limitations mentioned earlier. Embedded content is still treated differently than fielded data, and layout control around these blocks can be somewhat constrained compared to Layout Builder or Paragraphs.

Still, the Content Embed module represents a strong effort in the right direction reinforcing the potential for Drupal and Gutenberg to coexist more harmoniously with better UX and stronger content reusability.

A Path Forward for the Drupal Ecosystem

There’s a significant opportunity here for the Drupal community.

If the Gutenberg module could evolve to offer more adaptable, dynamic field mapping tightly integrated with Drupal’s field API and entity systems we could unlock a powerful hybrid approach: visual content editing without sacrificing structure, reusability, or display flexibility.

Imagine being able to drop a block in Gutenberg that’s directly tied to an entity reference, or to a media field, or even to a view mode. The editor experience would remain fluid, while content architecture stays intact.

Conclusion

Gutenberg and Drupal aren’t a perfect match today, but they could be. The foundations are there, and the community has already laid impressive groundwork. With further development in field mapping and tighter integration with Drupal’s core systems, the two worlds could coexist more harmoniously.

And perhaps most importantly, it could finally offer Drupal content editors the kind of intuitive, drag-and-drop experience they’ve been asking for without compromising the structured power Drupal is known for.

The Drupal community is already exploring ideas like Fieldable Blocks, deeper Field Mapping integrations, and better Gutenberg–Layout Builder hybrids. The potential is huge, and it rests on collaboration between module maintainers, site builders, and editors.

Comments 3 total

  • Ben Sinclair
    Ben SinclairJun 21, 2025

    I'm going to be outspoken here because I feel quite strongly about the subject.

    Drupal isn't perfect, but it's the best general-purpose PHP CMS overall. WordPress isn't a CMS, it's a blog and two unrelated modules in a trenchcoat.

    And Gutenberg is one of the worst things to happen to WordPress.

    Drupal is a better CMS than WordPress, and even with all its flaws it deserves better than Gutenberg.

    Management of data, separation of content from layout, the ability to easily replace existing components or re-theme the site - these things are all left at the side of the road.

    Within Drupal, when you add blocks via the Gutenberg UI, all that block content is stored in the body field of the node.

    There is no positive spin for this. It's the selling point, but it's literally the reason Gutenberg is terrible. Storing rendered HTML in your database, along with metadata crowbarred into comments and custom attributes is an astronomically bad idea.

    And of course, almost every component from WordPress' example has proved to be inaccessible div soup. Gutenberg is CKEditor on valium.

    • Wendy Stocker
      Wendy StockerJun 21, 2025

      I really appreciate how passionately you’ve laid this out and you’re absolutely right about many of the flaws. Let me respond point by point:

      “Drupal isn’t perfect, but it’s the best general‑purpose PHP CMS. WordPress isn’t a CMS, it’s a blog and two unrelated modules in a trenchcoat.”

      Agreed. That’s exactly why I’m wary of bolting on something designed for a very different paradigm. Drupal shines because it treats content as structured data, and that’s worth preserving.

      “Gutenberg is one of the worst things to happen to WordPress.”

      That depends on the lens. It’s been rough for purists and developers, no doubt. But it has also changed the expectations for editors across platforms. Part of why I wrote the post was to ask, What can we learn from that shift?

      “Management of data, separation of content from layout, the ability to easily replace existing components or re‑theme the site — these are left at the side of the road.”

      Exactly and this is the biggest threat to making Gutenberg work for Drupal. I don't suggest accepting that status quo, but instead we should explore if there’s a path for Gutenberg to evolve in a way that doesn’t abandon those core Drupal principles.

      “Storing rendered HTML in your database, with metadata crowbarred into comments and custom attributes, is an astronomically bad idea.”

      That’s exactly the crux of it. The biggest issue with Gutenberg as implemented in WordPress is that it stores rendered HTML and metadata in the database, coupling the layout too tightly to content.

      But it is possible to imagine a different approach one that treats Gutenberg-style blocks more like Layout Builder, storing configuration data (blocks, settings, relationships) rather than rendered markup. In other words, aligning it with Drupal’s core concept of structured data.

      If done right, it could give editors a rich, intuitive experience without sacrificing separation of content, layout, and presentation. The idea itself isn’t broken it just needs an architecture that respects Drupal’s principles.

      “Almost every component from WordPress’ example has proved to be inaccessible div soup. Gutenberg is CKEditor on valium.”

      That doesn’t mean the concept of a rich editor can’t evolve or that we can’t learn from its approach. Compared to the sometimes clunky editor experience of Paragraphs, it’s clear editors want a smoother, more visual way to build pages. The challenge is finding a way to deliver that experience while preserving the structured, maintainable foundation that Drupal is known for.

      • Ben Sinclair
        Ben SinclairJun 22, 2025

        it is possible to imagine a different approach one that treats Gutenberg-style blocks more like Layout Builder, storing configuration data (blocks, settings, relationships) rather than rendered markup [...] could give editors a rich, intuitive experience without sacrificing separation of content, layout, and presentation.

        This would be fantastic. I've seen a lot of editors partially do this, like for example TinaCMS using Next to render previews of the components as if they were editable and update the data on a field basis behind the scenes.

        That I could definitely get behind!

Add comment