DEV Community: Wendy Stocker

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

Wendy Stocker — Sat, 21 Jun 2025 15:46:39 +0000

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.

Observations of a Business Owner by a Code Cruncher

Wendy Stocker — Mon, 12 Aug 2019 14:51:49 +0000

Throughout the years I've worked for many companies both for agency style businesses as well as internal developer for larger organizations.

Along the way I've noted some growing pains and learning experiences that business owners have gone through while adjusting their business practices to meet the demands of the market.

Now to preface this, understand that one of the biggest expenses a business owner has, is the cost of an employee whether the organization be small or large.

That is why it's SO tempting to want to...

Outsource the labor to a non-US based labor pool

I cannot tell you how many times I've seen companies make this mistake. Either it be the person who was hired on to clean up the legacy code, or untangle a huge mess that something like this has created. In the long run it always ends up costing the business more than it saves. A good rule of thumb to remember is you always get what you pay for.

Second mistake, if they already haven't made the first is to...

Strip down costs and operate on a skeleton crew

This is often painfully felt by workers the most. In this kind of situation no one really wins. If your developers are spread too thin they are going to produce subpar work that isn't well thought out and could create more issues in the long run. While an application might be visibly functional on the front-end, yyou can bet your booties that there are some skeletons being created in the closet on the back-end. Often when developers need to cut corners to meet a deadline, things like security, documentation and QA will be sacrificed to get something done on time. Eventually those problems are going to surface whether it be now or later.

Third issue that can make your organization suffer...

No clear process in place and skipping over documentation

Many companies that produce tech have converted to an agile or at least agile-ish structure and process. Although I initially found this structure a bit intimidating, it was something that ended up being crucially beneficial. Agile methodologies really help developers create meaningful work that they are excited about. They also help them to create more accurate estimates by not pinning them down to an hourly deadline, while accounting for a certain amount of unknown or discovery that goes into developing a project especially if it is a new API or technology that you haven't worked with.

Documentation is often something that gets prioritized last which is indefinitely important. With good documentation you can easily avoid hellish scenarios where everyone is going to that one developer that has been there for years to find the most basic of information and everyone cries when they take the day off.

A good company to work for is a successful one

A good company to work for is like a well oiled machine, capable of meeting the demands of the market while producing a high quality product. Cutting corners, although extremely tempting will inevitably lead to the decay of both quality and culture.

Beware business owner, beware! :)

Caught Red-Handed!

Wendy Stocker — Sat, 26 May 2018 13:47:45 +0000

One of the pitfalls about being a Developer is you're eventually going to screw something up, and royally. It may not be today or tomorrow, but trust me when I say, it's inevitable.

I would even go as far as to say that the potential to create disastrous bug goes hand in hand with the amount of responsibility you have. You will create a bug that will surreptitiously seep through even the best unit tests, QA testing, and pull request reviews. It will leave you scratching your head and perhaps wondering why you didn't choose another line of work.

We all know that feeling you get in the pit of your stomach when you come to the stunning realization, "Oh bleep it was my fault!"

There's a couple of different ways to handle this sort of situation, and I'm going to explain those and why I think that taking full responsibility for your bug with dignity and grace is the best one.

First option: Try to pass the buck onto someone else.

In my opinion the worst option. I have been in a situation where I have spent hours going in circles with other Developers like some kind of horrible game of hot potato trying to pinpoint who created a bug. So much so that I wished it was me, so I could move on with my life. Not only is this a giant waste of time, but you're a Developer not a Detective. Eventually everything will fall into place, and you will wish you had those hours of your life back.

Try to correct the bug before anyone notices.

There are situations for example, like maybe you made a spelling error in your git commit message, and you want to correct it. That's a different story. If you are dealing with an issue that could have the potential to effect other Developers on your team, I would think twice before you do this. While fixing a bug quickly so that it goes under the radar is probably the most tempting option, sometimes this can come back to haunt you. Also making someone aware of a bug, helps your team document the process so that the same mistake doesn't happen again.

The jig is up!

A good manager and/or PM will understand that making boo-boos is unfortunately part of the job. It happens, and at the end of the day we're all human and we make mistakes. Don't be afraid to reach out and tell someone.

What you should be looking for to take away from this experience are these things:

How was the bug created and why? Make sure you fully understand this so you can learn from it.
What will you do in the future to avoid creating the same situation?
Document it, so that members of your team can learn from your mistake.

I will say this, some of the craziest bugs I have created are some of the biggest opportunities to grow and learn. As Niels Bohr said, "An expert is a [wo]man who has made all the mistakes which can be made, in a narrow field."

So if you handle your bugs with dignity and grace and approach them as a learning tool rather than a total embarrassment to be avoided completely, you will end up with some valuable information. That way you will take away some great tools to add your back pocket which will help you avoid creating those pesky bugs in the first place.

Tech in Pop Culture - Accurate or Hilarious?

Wendy Stocker — Wed, 23 May 2018 14:36:30 +0000

It's pretty amazing to see how much technology is appearing as a star of the show rather than an extra in the entertainment world.

While watching 'Mr. Robot' I almost fell over backwards when I saw Elliot was using BitchX - an IRC shell client. Kali Linux, terminal programs, and various toolkits are realistic depictions of the things a hacker would use to attack their victim.

Rami Malek as Elliot in Mr. Robot. Photo: Virginia Sherwood/USA Network

Here is a funny discussion on a subreddit about whether the hosts are actually using React or Swift: from the HBO series 'West World'.

Another HBO series, 'Silicon Valley' has its finger on the pulse of the tech industry and culture that has permeated out from the west coast. It's a fabulous depiction of the start-up entrepreneurial mentality of many tech companies, and the expedition to create the latest and greatest thing. Also,
who doesn't love Gilfoyle?

Trust me, they didn't always get it quite right. Let's look at some hilarious examples of when they didn't. Shall we?

From the show 'CSI':

Hold up, rewind the tape, what was that?

"I'll create a GUI interface using visual basic. See if I can track an IP address."
Wow, tracking the killer wasn't a pressing situation I guess.

Here's another one from the movie 'Jurassic Park':

I guess that Dennis fellow really liked the idea of organizing files in some sort of 3-D UI system. Very high tech!

From "Castle" Season 8 Episode 8:

Remember kids if you want to get root privileges on a server, all you have to do is crack the outer layer of the system, but beware of the intrusion inspection or else they'll be able to track your IP address!

As you can see the entertainment industry is now realizing they have to shell out a few extra dollars to create more realistic depictions of the tech industry if they want to avoid so many facepalms. Even in some cases tech is completely forefront, and it's nice to finally get an appreciative nod to us techies from them crazy Hollywood folks.

You Can't Pay Your Bills with Craft Beers.

Wendy Stocker — Mon, 21 May 2018 23:10:56 +0000

Culture is a very interesting thing in the tech community, and it has really come a long way. Over the years I've worked with an array() of wonderfully talented people, from all sorts of walks of life, and it has been a really cool ride.

When I first began cutting my teeth as a Developer, it was right around when the dot-com bubble had fizzled out. Web Development was a fairly new thing, Flash was everywhere, and mobile app development was a twinkle in Steve Job's eye. CSS was just beginning to replace that god awful table markup, and everyone and their dog was coming out with a new CMS in their preferred language. It was the new frontier, back when learning something new meant gasp opening a book.

The tech culture then was similar to something you might find in the movie 'Office Space'. Depending on your organization, you might see a definite delineation between tech department and everyone else. You know, the weirdos that look at that black cmd prompt all day, and if your computer breaks they will definitely know how to fix it.

Over time, agency work began to get more popular. Many upper management positions were replaced with PMs. Around this time I began to notice a cultural shift forming. Office casual was replaced with the sweatshirt, backpack, jeans and sneakers ensemble, and you could definitely tell that companies were starting to place fly traps in their job descriptions that attracted this type of individual.

You started to see things like, "Rock Star Developer", "Craft beers on tap", "Ping-pong table","Free Spotify subscription". All of those things are well and good if you are a 20 something male fresh out of college, but as someone who is not, let me tell you that those things don't actually have too much value.

Which brings me to the point of this post: You can't pay your bills with craft beers.

Though it's not always the case, be a little bit weary of an organization that tries to sell these things to you as part of the package deal. Money is definitely not everything, and working with a team of great people is invaluable. However, in my experience when an organization tries to do this, it's because they might be lacking in other areas.

All of those things can be pretty good bonuses, but when you're weighing the pros and cons of accepting a position take those things out. Ask yourself instead

Is this the best fit for me culturally and personality wise?
Is this a position where I can really see myself growing into what I want to be both short-term/long-term and inside/outside the company?
Will they see the value in what I can potentially bring to the organization?
Most importantly, will I be happy there?

If all of those questions are answered with a yes, then you can take a look at their craft beer selection.

Cheers! :)

Developer Interview Bloopers

Wendy Stocker — Sat, 19 May 2018 14:27:05 +0000

In my quest to find a new job, I've had a lot of interviews. I'm talking
$interview = range(30,40);

In person, over the phone, quizzes, tests, projects - you name it.

So I figured I would share some wisdom to anyone whom may now, or eventually be in the same boat. Through this sometimes hellacious process I've learned a few things.

The best interviews that test my true abilities are project based ones.

I know it sucks, and you have to work for free, but doing an ACTUAL project is the best reflection of the real-world application of your role. I don't know about you, but when I'm on the spot during an interview, and someone pulls the pop-quiz out of their pocket, I freak. They may ask something like, "What's the difference between an abstract class and a interface?" Something I know well and good, but at the time I can't even seem to remember what a computer is, let alone what my own name is. My brain literally does an exit(); and I have to recompile it again.

While I'm on that topic, I think the pop-quiz format is the worst way to interview a candidate. (I'm talking to you employers!) In my humble experience you don't want to work for someone that enjoys seeing you squirm like that anyway. You want to work somewhere that cultivates growth and where you can thrive as a Developer.

Go back to the basics.

A lot of the positions I have applied for are all across the board. I'm a PHP Developer, so I've been applying for Full-stack, PHP Software Developer, Web Developer, Drupal Developer, Laravel Developer. They all have very different names but are all under the umbrella. PHP/DB integration, some JS frameworks, CSS3 and maybe some DevOps as a secondary function. Sometimes I really did feel like a ping-pong ball each time I had an interview studying between those things. I found though, what helped me most was going back vanilla concepts without the help of a framework and re-learning the fundamentals. If you have those down, sticking a framework on top of that will seem less like magic and you will truly understand what is going on in the background.

I read somewhere that Ryan Dahl the creator of NodeJS said something like, It's impossible to know everything, but you can push yourself to learn the system. (I can't find the damn quote anywhere, but even if he didn't say that, it's true.)

Alright, I'm talking to you again employers! With new frameworks, new hosting services, new workflow processes coming out every day, please for the love of god stop trying to find Developers that only have experience with your specific stack. If a Developer is good with another framework or CMS that's structurally the same as the one you need to do the job, they can learn it quickly. Technology is always evolving, and again in my humble experience you want someone that can adapt to new things quickly, just as much as you want someone to have experience working with your specific technologies.

The worst thing you can do is be nervous.

I know, that may be easier said than done, but when I look back on this whole calamity the first couple of interviews I had after I lost my job were TERRIBLE. My voice was shaking, I couldn't quite articulate things the way I wanted, and I was incredibly insecure about the things I didn't know. Fast forward a couple months, and each interview is like riding a bike and you get a little better. You have your script, but you also feel comfortable going off script a bit too. You have to look at from the employers' perspective. In their mind they're thinking, I have to sit with this freaking person for a long time and 8-9 hours a day. The last thing they want to do is sit next to some sweaty, shaking robot who sounds like they just digested PHP.net. As much as it's hard, just relax and be yourself. Strangely every time I feel like I'm not too interested in a position, those are the people that are scrambling to get me on board. Which brings me to my last point.

Never stop interviewing.

I loved the previous team I worked with, they were like family. I thought I would work there forever. I got comfortable after 6 years. Then BAM just like that, corporate restructuring had me out on my butt as fast as I could blink. I really feel like if I had continued with the interview process, I could have had a better leg up on some of the earlier positions I applied for. Who knows, maybe I would have found something better suited for me than before. The world is your oyster as they say. When you see something come across your plate that looks great, you gotta jump on those opportunities, or someone else will!

Good luck coders, it can sometimes be a jungle out there and you're not alone. I wish you all the success in your future, and may the force be with you.

Why I'm leaving Drupal for Laravel

Wendy Stocker — Fri, 18 May 2018 14:08:48 +0000

For the past 6 or so years, I have been a Developer that primarily works with Drupal and I've pretty much been married to it for better or for worse.

Drupal has had many ups and downs over the years, and its steep learning curve gives Drupal Developers an edge over the market. As a Drupal Developer I've never had an issue finding a job, and it has a very strong community. Until now...

A series of unfortunate events has lead me back to hitting the bricks right around the time that Drupal's core version 8 has been released and is gaining popularity.

More often now I'm seeing job descriptions say things like, those who have not launched a Drupal 8 site need not apply. When I left my former job I was using Drupal 7 though... Crap. Don't get me wrong there's still a lot of companies and organizations that primarily work with Drupal 7, because it's quite the hurdle to update.

What makes this so difficult you ask? Well, one of the key differences is that it is essentially a different architecture entirely. Though it has a lot of backwards compatibility, the entire core has shifted from a procedural code base with some object oriented elements to using Symfony and object orient design patterns, a completely new templating engine, and many new concepts such as configuration. All that great documentation that exists in the community, doesn't exist for Drupal 8 yet since not enough people are using it. Though many of the key contributed modules provide you with a Drupal 8 version, it's not an easy switch.

If you're a Drupal Developer you know that up until Drupal 8 the code base consisted of working with arrays galore. Drupal 7 and pervious versions are basically really crappy design patterns with not much room for optimization, and a really superb caching layer to pick up the tab. Since I come from an OOP background I was pretty happy to learn that Drupal had made this switch, but other Devs that are sipping Drupal's kool-aid don't seem to question why such a leap? Why didn't Drupal's creators make better choices regarding design patterns in the first place?

That's when my eye started to wonder to other frameworks.

I started to play around with Laravel, and what a lean and elegant framework it was! Especially coming from something as bloated as Drupal, it was love at first code. Unlike Drupal, which does provide you with a GUI for things like constructing queries, and making Restful APIs, you have to know how to code, and optimize your own queries. Instead of the whole contributed module system which has a lot of overhead, you simply get model, view, controller. The documentation is very straight forward (there's a lot of stale documentation floating around on Drupal.org). It also has great support for Full-stack Developers using Bootstrap and VueJS.

So here I am about to accept a job offer after 6 years with Drupal, now a Laravel Developer. From the moment I first met Drupal it has been a wild ride, full of trials and tribulations. Over the years it has changed A LOT. Some day I might return, you never know. It's nothing personal Drupal. Laravel is a much better match for me. </3