drupal

Dries Buytaert: Switching to Markdown after 20 years of HTML

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:

After 20 years of writing in HTML, I switched to *Markdown*. <p class="pullquote">HTML for 20 years. Markdown from now on.</p> Now I can publish faster while still using [Drupal](https://drupal.org).

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:

Nothing beats starting the day with [coffee](https://dri.es/tag/coffee) and this view: [​image beach-sunrise.jpg lazy=true schema=true caption=false]

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.

Gbyte blog: How to Detect Entity Changes in Drupal the Right Way

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.

Dries Buytaert: Installing and configuring Markdown Easy for Drupal

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:

ddev composer require drupal/markdown_easy

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:

ddev drush updatedb

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.

ddev drush config:set markdown_easy.settings skip_html_input_stripping 1 ddev drush config:set markdown_easy.settings skip_filter_enforcement 1

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:

ddev drush config:get markdown_easy.settings

You should see:

skip_html_input_stripping: true skip_filter_enforcement: true

Finally, clear the cache to apply the changes:

ddev drush cache-rebuild

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 Drop Times: Colan Schwartz on Open Source and the Realities of Scaling with Drupal

Technical co-founder and cloud architect Colan Schwartz speaks with The DropTimes about his long history with Drupal, his work on Aegir and Drubernetes, and the transition from open source contributions to SaaS product development. The interview covers automation, infrastructure, DevOps practices, and the practical challenges teams face when adopting Drupal at scale.

DrupalEasy: Announcing a new multi-day DrupalEasy class: Professional Single Directory Components

18 total hours, delivered 3 hours/day for 6 days across 2 weeks for $600 Introducing the newest course in DrupalEasy's Drupal training catalog: Professional Single Directory Components (PSDC.) Leveraging our experience in delivering world-class long-form training material, we're excited to present this latest meticulously developed and beta-tested curriculum on an existing, emerging topic that is changing how Drupal sites are themed. This was a fantastic class! Delivered in practical lessons, it upgraded my Drupal front-end capabilities. - Eric Michalsen Single directory components (SDC) are in the midst of modernizing how Drupal themes are built. PSDC teaches the fundamentals of building SDCs while ensuring that students fully understand how to create forward-thinking SDCs that will be ready for the next evolution in Drupal site-building. Schedule The first PSDC class begins September 8, 2025 and runs from 11am-2pm EDT for 6 sessions over 2 weeks: Monday, September 8 Wednesday

Drupal Association blog: Take Part in the 2025 Drupal Business Survey

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.

Drupal AI Initiative: Exclusive first look: 200 business leaders on AI priorities - global survey analysis and roadmap reveal

Image removed.

In July 2025 we asked business leaders and agency experts to identify the AI capabilities in marketing they value most. During our upcoming webinar, we will share exclusive insights from survey analysis gathered from 216 AI professionals, business leaders, and technical decision makers from 199 different organizations across multiple industries.

Our findings provide a clear picture of where organisations are focusing their AI investments, and the features they regard as essential for future success. These insights can help your leadership prioritize AI investments to maximize their strategic benefit.

Join us 28 August 17:00-18:00 CET. Register your place today!

What You Will Learn

  • Top AI capabilities organisations value and want the most, and how these vary across different industries.
  • Emerging trends and sector-specific priorities shaping the next phase of AI in digital experience platforms.
  • How these insights are influencing the strategic direction and roadmap of Drupal AI to meet the needs of agencies, site owners, and end users.
  • Practical ways you can engage with the Drupal AI Initiative and contribute to its future development.

Exclusive early access to our analysis

All registered attendees will receive the full research report, enabling you to benchmark your organisation’s priorities against industry data.

Session Format

The presentation will run for 45 minutes, followed by a Q&A session where attendees can put their questions directly to the team.

This is an important opportunity to understand which AI features are most valued today, see how they are prioritised in Drupal AI’s roadmap, and explore the ways they could significantly benefit your organisation.

Register your place today.