When you’re looking for a Drupal Commerce developer, what exactly are you looking for? A lot hangs on this question. We’ve encountered some, let us say, “creative” implementations that painted the business into a corner or wasted a lot of time and money.

E-commerce websites are often mission-critical, and Drupal Commerce reliably powers $100s of millions in revenue per year, but an inexperienced developer can inadvertently introduce unnecessary risk. A mission-critical website needs experienced hands. Someone who can navigate the intersection of technical architecture and business logic that defines successful ecommerce implementations.

So what makes a good Drupal Commerce developer? What should you look for and what should you expect?

Drupal Mastery

At its core, Drupal Commerce is simply an arrangement of Drupal's core building blocks—entities, fields, configuration objects, views, and forms. But "simply" doesn't mean "easy." A developer needs intermediate to advanced PHP skills and must understand Drupal's architectural patterns deeply enough to know which tool fits which job. They also need to be familiar with Drupal.org and the ecosystem of contributed modules so they don’t go off half-cocked and decide to reinvent the wheel.

Why is this important? When a developer reads about creating a custom price calculation, they will learn about the system of price resolvers, which are services sorted by weight. A qualified developer immediately understands what a service is, how to define one, and how Drupal's dependency injection system will execute their code at the right moment. Without this foundational knowledge, they'll be copying and pasting code without understanding the underlying architecture. When bugs appear, they won’t know where to look to solve them.

The developer should also master essential development disciplines:

Securing Drupal Commerce: The Role of a Content Security Policy in Payment Compliance

Content Security Audit? Vardot Can Help.

By submitting this form you agree to our Terms of Service and Privacy Policy.

After nearly two decades and over 1,600 blog posts written in raw HTML, I've made a change that feels long overdue: I've switched to Markdown.

Don't worry, I'm not moving away from Drupal. I'm just moving from a "HTML text format" to a "Markdown format". My last five posts have all been written in Markdown.

I've written in Markdown for years. I started with Bear for note-taking, and for the past four years Obsidian has been my go-to tool. Until recently, though, I've always published my blog posts in HTML.

For almost 20 years, I wrote every blog post in raw HTML, typing out every tag by hand. For longer posts, it could take me 45 minutes wrapping everything in <p> tags, adding links, and closing HTML tags like it was still 2001. It was tedious, but also a little meditative. I stuck with it, partly out of pride and partly out of habit.

Getting Markdown working in Drupal

So when I decided to make the switch, I had to figure out how to get Markdown working in Drupal. Drupal has multiple great Markdown modules to choose from but I picked Markdown Easy because it's lightweight, fully tested, and built on the popular CommonMark library.

I documented my installation and upgrade steps in a public note titled Installing and Configuring Markdown Easy for Drupal.

I ran into one problem: the module's security-first approach stripped all HTML tags from my posts. This was an issue because I like to mix Markdown and HTML. I want to write most of a post in Markdown but turn to HTML for custom styling or elements that Markdown doesn't support. One example is creating pull quotes with custom CSS classes:

HTML in Markdown by design

Markdown was always meant to work hand in hand with HTML, and Markdown parsers are supposed to leave HTML tags untouched. John Gruber, the creator of Markdown, makes this clear in the original Markdown specification:

HTML is a publishing format; Markdown is a writing format. Thus, Markdown's formatting syntax only addresses issues that can be conveyed in plain text. [...] For any markup that is not covered by Markdown's syntax, you simply use HTML itself. There is no need to preface it or delimit it to indicate that you're switching from Markdown to HTML; you just use the tags.

In Markdown Easy 1.x, allowing HTML tags required writing a custom Drupal module with a specific "hook" implementation. This felt like too much work for something that should be a simple configuration option. I've never enjoyed writing and maintaining custom Drupal modules for cases like this.

I reached out to Mike Anello, the maintainer of Markdown Easy, to discuss a simpler way to mix HTML and Markdown.

I suggested making it a configuration option and helped test and review the necessary changes. I was happy when that became part of the built-in settings in version 2.0. A few weeks later, Markdown Easy 2.0 was released, and this capability is now available out of the box.

Now that everything is working, I am considering converting my 1,600+ existing posts from HTML to Markdown. Part of me wants everything to be consistent, but another part hesitates to overwrite hundreds of hours of carefully crafted HTML. The obsessive in me debates the archivist. We'll see who wins.

The migration itself would be a fun technical challenge. Plenty of tools exist to convert HTML to Markdown so no need to reinvent the wheel. Maybe I'll test a few converters on some posts to see which handles my particular setup best.

Extending Markdown with tokens

Like Deane Barker, I often mix HTML and Markdown with custom "tokens". In my case, they aren't official web components, but they serve a similar purpose.

For example, here is a snippet that combines standard Markdown with a token that embeds an image:

These tokens get processed by my custom Drupal module and transformed into full HTML. That basic image token? It becomes a responsive picture element complete with lazy loading, alt-text from my database, Schema.org support, and optional caption. I use similar tokens for videos and other dynamic content.

The real power of tokens is future proofing. When responsive images became a web standard, I could update my image token processor once and instantly upgrade all my blog posts. No need to edit old content. Same when lazy loading became standard, or when new image formats arrive. One code change updates all 10,000 images or so that I've ever posted.

My tokens has evolved over 15 years and deserves its own blog post. Down the road, I might turn some of them into web components like Deane describes.

Closing thoughts

In the end, this was not a syntax decision: it was a workflow decision. I want less friction between an idea and publishing it. Five Markdown posts in, publishing is faster, cleaner, and more enjoyable, while still giving me the flexibility I need.

Those 45 minutes I used to spend on HTML tags? I now spend on things that matter more, or on writing another blog post.

Image galleries are a common feature in website development. They are used in portfolio, product, or event presentations, as well as sharing pictures with other users. Discover how to create your own with available Drupal gallery modules and tools.

The following code snippets should be compatible with Drupal 10+.

Challenges in detecting meaningful entity changes

One working with entities in Drupal answering of the following seemingly simple questions can pose a challange:

Has this entity meaningfully changed since its last revision? Has it changed meaningfully since it was last saved?

Drupal doesn't provide a built-in mechanism for this. That's intentional, because what counts as a change can vary greatly between use cases. While there are ways to hack around the problem—such as comparing $entity->toArray() with $entity->original->toArray()—these approaches fall short quickly.

• Timestamps, UUIDs, and metadata fields will almost always differ, even when the entity's "meaningful" data hasn't changed.
• Some values are normalized differently on save (for example, 0 stored as an integer versus false cast as a boolean).
• Rich text fields often come back from CKEditor with extra markup or formatting quirks, even when the human-readable content is the same.
• The moderation module forces the creation of new revisions even if there have been no changes since the last version of the entity.

This makes raw array comparisons noisy and unreliable.

Enter the Diff Module

Luckily, Drupal already has a well-established module for detecting meaningful changes between entity revisions: Diff.

The Diff module is designed to highlight what actually changed between two revisions of an entity. It provides a user-friendly UI for visualizing differences, but behind that UI is a powerful service that can be reused programmatically.

I recently installed Markdown Easy for Drupal and then upgraded from version 1.0 to 2.0.

I decided to document my steps in a public note in case they help others.

On my local machine, I run Drupal with DDEV. It sets up pre-configured Docker containers for the web server, database, and other required Drupal services. DDEV also installs Composer and Drush, which we will use in the steps below.

First, I installed version 2.0 of Markdown Easy using Composer:

If you are upgrading from version 1.0, you will need to run the database updates so Drupal can apply any changes required by the new version. You can do this using Drush:

As explained in Switching to Markdown after 20 years of HTML,I want to use HTML and Markdown interchangeably. By default, Markdown Easy strips all HTML. This default approach is the safest option for most sites, but it also means you can't freely mix HTML tags and Markdown.

To change that behavior, I needed to adjust two configuration settings. These settings are not exposed anywhere in Drupal's admin interface, which is intentional. Markdown Easy keeps its configuration surface small to stay true to its "easy" name, and it leads with a secure-by-default philosophy. If you choose to relax those defaults, you can do so using Drush.

The skip_html_input_stripping setting turns off input stripping in the CommonMark Markdown parser, which means your HTML tags remain untouched while Markdown is processed.

The skip_filter_enforcement setting lets you turn off input stripping in Drupal itself. It allows you to disable the "Limit allowed HTML tags" filter without warnings from Markdown Easy.

You can enable just the first setting if you want Markdown to allow HTML but still let Drupal filter certain tags using the "Limit allowed HTML tags" filter. Or you can enable both if you want full control over your HTML with no stripping at either stage.

Just know that disabling HTML input stripping and disabling HTML filter enforcement can have security implications. Only disable these features if you trust your content creators and understand the risks.

Next, I verified my settings:

You should see:

Finally, clear the cache to apply the changes:

Next, I updated my existing Markdown text format. I went to /admin/config/content/formats/ and made the following changes:

• I set the Markdown flavor to Smorgasbord
• Disabled the "Limit allowed HTML tags and correct faulty HTML" filter
• Disabled the "Convert line breaks into HTML" filter

That's it!

The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source DXP Drupal. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who’ve submitted responses. 

Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association in order to promote global reach and protect the confidentiality of the information. Janne, Michel, and Imre are still involved in the analysis and reporting of the anonymized data from the survey.

Drupal’s open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal’s market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies. 

The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.

Take the survey here!

Results in 2024

Nearly 72% of participating companies hired new staff, with most saying it was to meet growing project demand. Many agencies also shared that over half of their revenue came from Drupal 9 and 10 clients, reinforcing Drupal’s continued strength in enterprise work.

We also saw some interesting shifts in client sectors. Public sector, education, and nonprofits remained Drupal’s strongest markets. Healthcare and medicine showed signs of growth and is gradually catching up, which could make it one to watch in future surveys. A number of agencies told us that after a difficult 2023, their pipelines were looking stronger in early 2024. Almost half of respondents said they were already using AI in client work or planning to, which is something we’ll definitely want to keep tracking in this year’s results.

Changes for 2025

In 2025, as the Drupal Association fully takes over the administration, maintenance, and communication of the Drupal Business Survey, we are implementing a few changes.

First, the response window has been shortened and moved to a time that better aligns with firms planning for 2026. The survey will be issued on 19 August 2025, with a submission deadline of 23 September 2025.

Second, the questions have been reviewed and adjusted to improve their analytical value, particularly for comparing trends across years. This standardization process will continue in future editions to ensure we can report data with statistical significance.

Finally, the Drupal Business Survey will now serve as the Drupal Association’s official business survey. We will no longer support duplicative business surveys throughout the year. The survey originally developed by Janne, Michel, and Imre has a long and respected history, and we believe it’s best for this to become the official Drupal market survey.

Drupal Business Dinner

The Drupal market is eager to see how digital service providers are using Drupal and how the market has evolved this year. The key takeaways from the 2025 Drupal Business Survey will be shared at the Drupal Business Dinner on Wednesday, 15 October. Please note that you must register separately for this event by purchasing your ticket here. A deeper dive into the survey results will be given during the dedicated session on Thursday at 9:15 am. View session details here.

DrupalCon Europe is the yearly Drupal conference where over 1,000 Drupal users and professionals meet to exchange ideas and further evolve Drupal. This year’s event will be held from 14–17 October in Vienna, Austria.

About the Business Survey

The Drupal Business Survey supports Drupal businesses worldwide and is organized by a team of industry experts Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (Craftmore) in collaboration with the Drupal Association. 

Drupal is the open source Digital Experience Platform used by many organizations worldwide including Nestlé, Lufthansa and World Wildlife Fund ( WWF).

Participate and share your insights

Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.

You can take the Drupal Business Survey 2025 anonymously here. The survey closes on 23 September.