webjoke.de

Markdown has become a practical drafting format for Drupal teams working across notes apps, code editors, documentation systems, and AI-assisted writing tools. Jorge Tutor’s CKEditor5 Markdown module addresses the handoff into Drupal by converting pasted Markdown through an explicit editor dialog, then letting CKEditor5 enforce the active text format’s HTML rules. In written responses to The DropTimes, Tutor framed the module as a narrow fix for teams that want Markdown during drafting but not as the stored or rendered content format.

Drupal is a strong platform for complex digital services, but its long-term value depends on how well people can use it every day. The admin interface should support the editorial team, not slow it down. The admin interface is part of service quality Public-facing user experience usually receives most of the attention. That is understandable. Visitors, residents, students, customers or partners see the public website first. But there is another important user group: the people who create, update, translate, review, publish and archive content. When their work happens in a slow or confusing admin interface, the impact appears quickly: content is updated less often; errors remain visible for longer; editors need more support; developers are asked to handle changes the content team should…

Drupal CMS 2.0 brings a new starting point, Canvas and site templates, but an existing site created from Drupal CMS 1 does not automatically become the same thing. Before changing it, you need to understand what the site actually uses. Drupal CMS 2.0 raises an obvious question: if a site started from Drupal CMS 1, can it simply be upgraded to Drupal CMS 2? The short answer: carefully. Drupal CMS is not a product version in the same sense as a Drupal Core major version. The Drupal CMS project page describes it as a starting point for new sites. Once a site has been created, what you have is a Drupal site with selected modules, configuration and content. That means Drupal CMS 1 to 2 should not be treated as just a Composer command. It should be treated as a technical change to an…

Drupal CMS 2.0 promises a faster start, visual page building and AI-assisted workflows. In a client project, the important question is not only how good the demo looks, but how the solution behaves two years later. Drupal CMS 2.0 was released on 28 January 2026. Its main themes are Canvas, AI tools and site templates. Drupal.org describes it as a way for marketing teams to launch branded sites faster. This is an important shift for Drupal. Drupal has long been strong for complex systems, but getting started has often required more technical work than simpler CMS products. Drupal CMS is an attempt to reduce that friction. What changed in Drupal CMS 2.0? Drupal CMS 2.0 is not a separate technology branch. It is still Drupal, but with a new starting point. The main changes include: Canvas…

DrupalCon Rotterdam is one of those events that naturally attracts attention across the Drupal ecosystem. Not only because it brings the community together, but because it creates a space where technology, strategy, contribution and real-world digital projects meet.

For anyone working with Drupal, open source or digital experience platforms, the question is not just “what happens at DrupalCon?”, but it might be: “If you have never been before, why should this be the year to go?”

 

Image

            Photo by Joris Vercammen 

Why Rotterdam?

Rotterdam feels like a strong fit for an event like DrupalCon. It is a city known for innovation, architecture, international connections and a forward-looking mindset — qualities that align naturally with the spirit of the Drupal community.

Bringing DrupalCon to Rotterdam creates an opportunity to connect the European Drupal community in a dynamic and accessible setting. It also gives professionals from different markets the chance to meet, exchange perspectives and discuss how Drupal continues to evolve in a fast-changing digital landscape.

Learning from real experience

One of the strongest reasons to attend DrupalCon is the quality of the knowledge shared by the community.

This is not only about product updates or technical presentations, It is about learning from people who are building, maintaining and improving digital platforms in real contexts, often with complex requirements, long-term governance needs and ambitious user experience goals.

From technical sessions to strategic case studies, DrupalCon gives attendees access to practical insight that is difficult to get from documentation alone.

Meeting the community behind Drupal

Drupal has always been more than a content management system; It is an open-source project supported by a global network of contributors, companies and professionals.

For someone who has never attended before, this is one of the most compelling reasons to go: Online discussions, issue queues and documentation are valuable, but meeting people face to face adds a different layer to the experience.

Conversations during sessions, between talks or at community events can lead to new ideas, partnerships and a better understanding of how others approach similar challenges.

 

Image

            Photo by Matthew Saunders 

Inspiration beyond the technical track

DrupalCon is also a place to see what organisations are doing with Drupal today.

Real-world examples often show the platform’s value more clearly than feature lists. They reveal how Drupal is being used to support public sector platforms, media websites, higher education, enterprise ecosystems, multilingual content, accessibility requirements and complex editorial workflows.

That is why DrupalCon is relevant beyond development, project managers, designers, UX professionals, marketers, content teams and business leaders can all find useful perspectives on delivery, governance, accessibility, platform strategy and the role of open source in long-term digital transformation.

Why attend for the first time?

Attending DrupalCon for the first time is a way to move from observing the community to being part of it.

It is an opportunity to learn from experienced professionals, understand the direction of the platform, discover practical use cases and build connections that can continue long after the event ends.

DrupalCon Rotterdam represents more than another event in the digital calendar, It is a chance to understand Drupal through the people and projects that keep it moving forward.

For a first-time attendee, that may be the strongest reason to go. 

Because sometimes the best way to understand the value of a community is not to read about it from the outside. It is to be in the room where that community comes together. 

See you there?
Register now!

 - Article by Daniela Moreira 

Project: Drupal coreDate: 2026-June-17Security risk: Moderately critical 11 ∕ 25 AC:Complex/A:User/CI:Some/II:Some/E:Theoretical/TD:UncommonVulnerability: Improper validationAffected versions: <10.5.12 || >=10.6.0 <10.6.11 || >=11.2.0 <11.2.14 || >=11.3.0 <11.3.12 || 11.0.* || 11.1.*CVE IDs: CVE-2026-55808Description: 

The JSON:API and REST modules allow you to upload image files to image fields.

The validation rules check the file extension of the uploaded file but not the file MIME type. This may allow a malicious user to upload a file that is not an image.

Certain web-server configurations may serve the uploaded file with its actual MIME type rather than an image type. This may lead to cross-site scripting (XSS) or other unexpected behavior.

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.12.
• If you use Drupal 11.2.x, update to Drupal 11.2.14.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.11.
• If you use Drupal 10.5.x, update to Drupal 10.5.12.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)

Reported By: 

• cantina_security

Fixed By: 

• Björn Brala (bbrala)
• Kim Pepper (kim.pepper)
• Lee Rowlands (larowlan) of the Drupal Security Team

Coordinated By: 

• Damien McKenna (damienmckenna) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Project: Drupal coreDate: 2026-June-17Security risk: Moderately critical 10 ∕ 25 AC:Basic/A:User/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Server-side request forgeryAffected versions: <10.5.12 || >=10.6.0 <10.6.11 || >=11.2.0 <11.2.14 || >=11.3.0 <11.3.12 || 11.0.* || 11.1.*CVE IDs: CVE-2026-55807Description: 

The Media module comes with support for oEmbed. The oEmbed specification contains two discovery mechanisms, via providers.json and via URL discovery.

The URL discovery code could be leveraged to trick Drupal into making server-side requests to any URL.

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.12.
• If you use Drupal 11.2.x, update to Drupal 11.2.14.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.11.
• If you use Drupal 10.5.x, update to Drupal 10.5.12.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)

Required site changes for URL discovery

Most users of the oEmbed functionality in Drupal likely use providers.json to define known providers (such as YouTube and Vimeo) for embedding content.

If you are using URL discovery, you now need to set a list of trusted oEmbed discovery hosts in settings.php.

This is an array containing a series of regular expressions for matching host names for discovery. It follows the same pattern as the existing trusted hosts settings.

Example:

// Only allow URL discovery from example.com. $settings['media_oembed_discovery_trusted_host_patterns'] = [ '^example\.com$', ]; Reported By: 

• Hamed Kohi (0xhamy)
• assaf alassaf (ama62)
• Albert Skibinski (askibinski)
• Jon Minder (ayalon)
• Lautaro Casanova (betah4k)
• Gabe Sullice (gabesullice)
• John Morahan (john morahan)
• Michael Winser (michaelwinser)
• nbanderson
• offensive-ai
• Francesco Placella (plach)
• quynh ho (qquynh)
• Himanshu Anand (unknownhad)

Fixed By: 

• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Adam G-H (phenaproxima)
• Sean Blommaert (seanb)

Coordinated By: 

• Benji Fisher (benjifisher) of the Drupal Security Team
• cilefen (cilefen) of the Drupal Security Team
• Damien McKenna (damienmckenna) of the Drupal Security Team
• Mori Sugimoto (dokumori) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• James Gilliland (neclimdul) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Project: Drupal coreDate: 2026-June-17Security risk: Less critical 9 ∕ 25 AC:Basic/A:None/CI:None/II:None/E:Theoretical/TD:DefaultVulnerability: Cache poisoning and open redirectAffected versions: <10.5.12 || >=10.6.0 <10.6.11 || >=11.2.0 <11.2.14 || >=11.3.0 <11.3.12 || 11.0.* || 11.1.*CVE IDs: CVE-2026-55806Description: 

Drupal core ships a rebuild.php front controller that can be used to rebuild Drupal (clearing the caches and rebuilding the container) when the site is in an unexpected condition.

This script doesn't correctly check the Host header against the list of trusted host patterns. This could result in cache poisoning or a redirect to an attacker-controlled domain.

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.12.
• If you use Drupal 11.2.x, update to Drupal 11.2.14.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.11.
• If you use Drupal 10.5.x, update to Drupal 10.5.12.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)

Reported By: 

• Melih Acikoz
• Michael Winser (michaelwinser)
• Willem Drupal enthousiast (willempje2)

Fixed By: 

• Lee Rowlands (larowlan) of the Drupal Security Team

Coordinated By: 

• catch (catch) of the Drupal Security Team
• cilefen (cilefen) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• James Gilliland (neclimdul) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Project: Drupal coreDate: 2026-June-17Security risk: Moderately critical 14 ∕ 25 AC:Complex/A:Admin/CI:All/II:All/E:Theoretical/TD:UncommonVulnerability: Gadget chainAffected versions: <10.5.12 || >=10.6.0 <10.6.11 || >=11.2.0 <11.2.14 || >=11.3.0 <11.3.12 || 11.0.* || 11.1.*CVE IDs: CVE-2026-55804Description: 

Drupal core contains a chain of methods that could be exploitable when an insecure deserialization vulnerability exists on the site. This so-called "gadget chain" presents no direct threat, but is a vector that can be used to achieve remote code execution or SQL injection if the application deserializes untrusted data due to another vulnerability.

This issue is not directly exploitable.

This issue is mitigated by the fact that in order for it to be exploitable, a separate vulnerability must be present to allow an attacker to pass unsafe input to unserialize().

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.12.
• If you use Drupal 11.2.x, update to Drupal 11.2.14.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.11.
• If you use Drupal 10.5.x, update to Drupal 10.5.12.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)

Reported By: 

• Michael Maturi (michaelmaturi)

Fixed By: 

• Lee Rowlands (larowlan) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Mohit Aghera (mohit_aghera)

Coordinated By: 

• Anna Kalata (akalata) of the Drupal Security Team
• Benji Fisher (benjifisher) of the Drupal Security Team
• cilefen (cilefen) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Project: Drupal coreDate: 2026-June-17Security risk: Critical 18 ∕ 25 AC:None/A:User/CI:All/II:All/E:Theoretical/TD:UncommonVulnerability: PHP object injectionAffected versions: <10.5.12 || >=10.6.0 <10.6.11 || >=11.2.0 <11.2.14 || >=11.3.0 <11.3.12 || 11.0.* || 11.1.*CVE IDs: CVE-2026-55803Description: 

SA-CORE-2019-003 added protection for fields that store serialized data to disallow direct writes via web services.

The above fix did not cover all potential attack vectors for JSON:API. An attacker with appropriate JSON:API write permission could potentially inject a malicious payload in certain rare circumstances, potentially resulting in PHP Object Injection.

This vulnerability is mitigated by the fact that in order to be exploitable:

• A site must use an entity reference field type that stores a serialized property.
• An attacker must have permission to write to the entity via JSON:API.

No field type shipped with Drupal core meets these criteria, and contributed or user-created field types that do appear to be extremely unusual. This update protects all such fields; no changes are required in contributed modules.

JSON:API is read-only by default, so sites are only affected if they have enabled write access (either through administrator configuration or the installation of a contributed or custom module that enables write access).

Drupal Steward protection:

This issue is being protected by Drupal Steward. In this instance, we believe that the WAF rule will provide mitigation for the common/obvious vulnerability paths, but may not be able to cover all cases or work for all hosting providers. Additionally, several other core security advisories released today are not mitigated by Drupal Steward. Therefore, our recommended action is still to plan an actual Drupal update within 24 hours of this release.

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.12.
• If you use Drupal 11.2.x, update to Drupal 11.2.14.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.11.
• If you use Drupal 10.5.x, update to Drupal 10.5.12.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)

Reported By: 

• Michael Maturi (michaelmaturi)

Fixed By: 

• Björn Brala (bbrala)
• Sascha Grossenbacher (berdir)
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team

Coordinated By: 

• Anna Kalata (akalata) of the Drupal Security Team
• Benji Fisher (benjifisher) of the Drupal Security Team
• Damien McKenna (damienmckenna) of the Drupal Security Team
• David Strauss (david strauss) of the Drupal Security Team
• Neil Drumm (drumm) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Tim Hestenes Lehnen (hestenet)
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Ra Mänd (ram4nd) provisional member of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

QED42 has opened a waitlist for EventHorizon, a Drupal-focused code-intelligence suite built on the scanning engine behind its open-source EventHorizon CLI. The CLI runs static analysis locally without AI, cloud upload, or telemetry, addressing audit environments where client code is covered by NDAs, data residency clauses, and security review. The broader suite adds visual dependency maps, code health views, and optional AI through user-controlled provider keys.

Context debt Government agencies are deploying AI faster than they’re managing the information those systems depend on. That gap has a name. It’s not only model risk. It’s not only data risk. It’s context debt. Content debt is the familiar problem of published content that has lost its structure, ownership and discipline. Context debt is its AI counterpart, sitting in the operational layer between that content and the AI system reading it: the prompts, system instructions, retrieval rules, scoping logic, brand and tone guidance, and example libraries that shape what the AI actually says. When that operational layer is scattered, stale, duplicated or inconsistent across prompts, tools and teams, AI output suffers regardless of how good the underlying content is.

Cypress is ideal for testing Drupal content moderation, but the learning curve is rather steep. Well, with the cypress-json-tests package, you can be done within a couple of hours.

The Drupal marketplace is driving a shift toward high-quality, accessible, and easily maintainable templates tailored for specific industry verticals (like government, healthcare, and education).

Good news for everyone still polishing their entry, we've extended the submission deadline for the International Splash Awards 2026 by four weeks. You now have until 16 July 2026 to submit your project.

As part of our commitment to a fair process, we want to give every Drupal community and agency ample time to put their best work forward. So we're opening the doors wider rather than closing them.

The Splash Awards celebrate the very best Drupal projects from around the world, with winners announced at DrupalCon Rotterdam 2026 (28 September – 1 October). Submitters will be notified of their status in early August.

Learn more & submit your project

Questions? Email drupal@kuonitumlare.com or reach us in #drupalcon_europe on Drupal Slack.

Image

What an exciting time to be a developer. Over the past year, I've gradually begun adopting a number of AI tools to improve the quality of my work, be more efficient, and even dive into areas of development I had never been strong in.

The days of reading blog posts and tutorials or trying code challenges are over. Or are they?

I subscribe to a handful of technical newsletters which arrive in my inbox every week. I always look forward to learning about the new stuff, improvements to old stuff, or the exciting features or tools coming down the development pipeline. I read each one of them in their entirety and if I am too busy, I keep them in my inbox until I have the time to go through them. Sometimes this means I have two issues to read through because I have not been able to get the previous one. I never delete them until I am done with them.

Why waste my time when I can easily ask AI for help? The learning process is exciting for me, it always has been. In the AI era it might even be more important because what if AI is wrong? How do I know the code snippet I am provided is correct or won't cause regressions in my project? Maybe this is the reason I don't use front-end frameworks like Bootstrap or Tailwind in my projects. I have used them for prototyping, but never to dictate the direction or coding conventions in my project.

Let's take a look at a basic example that may seem trivial but could lead to major issues if not understood. Then we will dive into the real reason I decided to write this post.

HTML/CSS Block-level element vs. Inline-level element

If you know CSS really well you can skip these examples, but if you don't know what block-level and inline-level elements are in the context of HTML/CSS, you may run into issues with your code you'd think is not working when in fact it might be working as intended.

.block { display: block; /* 1 */ margin: 24px; /* 2 */ padding: 24px; /* 3 */ width: 100px; /* 4 */ }

display:block:

1. every side affects the layout.
2. all 4 sides push surrounding boxes.
3. all 4 sides expand the box.
4. width/height are honored.
5. breaks content flow by creating a line break (i.e. <p>, <div>, <h2>)

.inline { display: inline; /* 1 */ margin: 24px; /* 2 */ padding: 24px; /* 3 */ width: 100px; /* 4 */ }

display:inline:

1. only the horizontal axis affects layout.
2. left/right push adjacent inline content; top/bottom are IGNORED entirely.
3. left/right push adjacent content; top/bottom are PAINTED but reserve NO space — they don't push the lines above/below apart.
4. width / height have NO EFFECT.
5. does not break content flow (i.e. <a>, <span>, <img>)

.inline-block { display: inline-block; /* 1 */ margin: 24px; /* 2 */ padding: 24px; /* 3 */ width: 100px; /* 4 */ }

display:inline-block:

1. best of both worlds, inline element with block characteristics.
2. all 4 sides reserve space.
3. all 4 sides reserve space.
4. width / height honored again.
5. it does not break content flow (i.e. any element with display: inline-block;)
6. because the element is inline, a whitespace of typically ~4px is rendered in your HTML. That's why a row of inline-block boxes set to width: 25% won't fit four-across.

Did you know all those specifics about the display CSS property? What if I didn't understand them and wondered why my layout is broken? What if I want to turn an inline-level element into a block-level element and vice versa? What would that do to my layout or spacing around elements?

The real example that validated my learning thirst

Here is when it became clear to me that you don't need to be an expert, but at the very least understanding your code can provide you with the ability to question AI's decisions and even push back on its recommendations.

The code challenge was relatively simple because I have done this many times, but this time it was at the end of my day and I was exhausted. So I figured I'd make use of AI to help me complete this task.

Build a Card component with SDC in Storybook

I'll focus on only the one piece AI and I had a disagreement on and had to have a heart-to-heart talk about; The card's cta link.

• As any typical card, I needed a title, image, label, and a link/cta field.
• The link needed a label (i.e. "Read the full article"), url, and an icon (svg).

AI built the component for me using Single Directory Component (SDC) conventions along with my custom Storybook's workflow and it worked as expected in Drupal and Storybook, but since this was one of the first components I was building in this new project, I decided that for the link's icon, I wanted to extract the inline SVG from the link.twig template and instead create an <svg>...</svg> asset out of it so I could re-use it in other components.

Originally, AI had opted to use Twig's source() function which is a valid and proper approach for inlining SVGs into components or Twig templates, however, I like to use {% include %} as it provides better cache management especially if I plan to use many icons on my site.

Here's the verbatim conversation about this "simple" change:

Me:
can we extract the icon's svg tag and create a file for it inside src/assets/images/? then twig include it in link.twig? this way we can reuse it in other components

Simple enough, except my project's workflow is unique in that SDC and Storybook share assets (twig, yml, css, js, images), to ensure there is a single source of truth. However, since this was a new project, I had not registered all the required namespaces for Drupal and Storybook to share assets.

AI:
Good call — {% include %} sidesteps source() entirely and avoids the namespace registration work in both Drupal and Storybook.

At this point AI proposed to write a theme hook to register a new Twig namespace Drupal could use to access assets directory.

The proposal of a theme hook to register a new Twig namespace was a NO NO for me because I knew it was not necessary. This takes me back to my original point of being able to understand the code to challenge AI proposed solutions that may not be necessary or an alternative/twig-friendly approach may do just fine.
I immediately questioned the proposal and provided a recommendation.

Me
how about adding a new namespace for drupal that points to src/assets so both storybook and drupal use the same path for assets?

AI
That's the cleanest approach. A single @assets namespace registered in both Storybook and Drupal means the same {% include '@assets/images/icon-arrow.svg' %} line works identically in both environments - no <theme-name>.theme hook needed at all

Needless to say, this was the right call and the final result was summarized by AI as:

AI

- src/assets/images/icon-arrow.svg — created, contains the SVG
- vite.config.js — assets namespace added (Drupal)
- .storybook/main.js — assets namespace added (Storybook)
- components/link/link.twig — inline SVG replaced with
{% include '@assets/images/icon-arrow.svg' %}

For me the main learning lesson of these simple yet real examples is that in the past, “knowing how to code” mostly meant knowing the syntax, semantics and understanding what you were writing. That part is becoming less critical with AI. But the more important skill, "knowing what not to write", hasn’t changed. Avoiding poor tradeoffs, recognizing over-engineered or fragile solutions, those still require judgment. That judgment hasn’t gone away; it’s just being applied later in the process.

In closing

These are interesting times for developers. We don’t yet know what this shift means for how we consume knowledge, but I do hope I never lose the desire to read, watch, and try new learning materials, and to still feel excited about them.

Happy learning!

An opportunity to help Web standards move in a good direction

Drupal now ships with HTMX, and there is currently a proposal to add a few of the building blocks into the HTML specification. The effort is nicknamed the triptych and the goal is to add three new HTML features: 

theodore June 17, 2026

Join us THURSDAY, June 18 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.

The question I get most these days is: did AI kill the CMS? Should we still invest in a CMS, switch to AI agents, or wait until the market becomes clearer?

At a friend's birthday party recently, I was talking with engineers and startup CEOs. They were all smart people, but none of them worked in the CMS industry. From where they sat, AI seemed to make the CMS obsolete.

I understand why. AI can now generate copy, design pages, write code, translate content, and assemble websites. If that is what you think a CMS is for, it does look like the CMS is in trouble.

They may be right about one part of the CMS market. But I think they are wrong about the larger picture.

To see why, it helps to separate what a content management system, or CMS, does into two planes: the control plane and the execution plane.

The control plane governs content: who can edit it, what gets approved, which version is canonical, how translations move through workflow, and where content can be used.

The execution plane creates, assembles, and delivers that content into websites, mobile apps, feeds, and other customer experiences.

AI is unbundling these two planes. It is commoditizing the execution plane while making the control plane more valuable. That is why I think AI is killing one corner of the CMS market, but making the CMS more critical everywhere else.

This post is a companion to AI and the great digital agency unbundling. That post looked at AI's impact on the digital agency market. This one looks at the same unbundling pattern in content management systems and digital experience platforms. AI lowers the cost of creation, not the cost of trust

We have seen this pattern before. The printing press made it cheap to produce and distribute content, but it did not make editors or publishers irrelevant. It made them more important, because more content created more need for judgment, trust, and standards.

AI is doing something similar to digital content. It makes production cheaper: drafting, generating, translating, designing, assembling pages, and adapting content for different channels.

But AI should not be the final authority on what is correct, approved, compliant, or safe to publish. It can help, but people and systems still need to own those decisions. The more content AI helps produce and distribute, the more that ownership matters.

As production gets cheaper, control becomes more important, not less.

That is the real test for a CMS. Not whether AI can generate content or build a page, but whether your organization needs a control layer: roles, review, approvals, publishing states, revision history, and more.

How shared is your work?

Two simple questions can help decide how much you need a CMS:

1. How many people or agents create, review, and publish content?
2. How many systems need to use, update, or trust that content?

Put those questions on a grid, and four use cases emerge.

The more people, agents, systems, and channels involved, the more a CMS matters as the control layer.

When one person creates and publishes content, and no other systems depend on it, you may not need a CMS. A lightweight publishing tool or AI site builder may be enough.

When multiple people or agents touch content, you need a CMS for coordination: roles, review, approvals, publishing states, and revision history. AI inside the CMS can help teams create, review, and publish faster without losing control.

When many systems touch content, you need a CMS as the trusted source for content, permissions, workflows, and publishing controls. AI around the CMS can coordinate work across tools, but it still depends on the CMS to know what content is approved, who can use it, and where it can go.

In short, when many people and many systems are involved, the CMS becomes the critical control layer for people, agents, and systems working together. It gives people and agents a safe place to create and approve content, and gives other tools a trusted system they can read from, write to, and build on.

The decision, by quadrant 1. Assist: one person, one system

This is the simplest case: one person, one system, and little coordination.

If you are creating a new website quickly, an AI site builder may be the right tool. It can turn a prompt into a working site in an afternoon. In that case, a CMS may slow you down more than it helps. This is 1a in the quadrant image: the job is to create, not to manage.

But one person does not always mean a CMS is unnecessary.

My website has been around for more than twenty years. It has more than 1,500 blog posts and 10,000 photos. That is not just a website to create; it is a body of content to manage. Drupal helps me manage that content as structured content: content types, fields, taxonomy, media, revisions, URLs, and search.

I would not move my site to a standalone AI site builder. But I do use an AI agent to work on it through Drupal: updating content, improving existing features, and building new ones. This is 1b on the chart. AI helps with the execution work, while Drupal remains the control plane. This is unbundling at the smallest scale.

So use an AI builder when speed to a new site matters most. Use a CMS when the work is about managing a large or growing body of content over time: keeping it structured, consistent, reusable, and reliable.

2. Relay: many people, one system

This is a clear case for a CMS.

When many people collaborate on one website, the work becomes a "relay": a designer uploads an image, a developer builds a component, a marketer writes the copy, an editor reviews the page, legal approves it, and someone presses publish.

AI does not remove that relay; it makes it move faster. The developer may use an AI coding agent, the marketer may use an AI writing assistant, and the editor may use an AI policy checker. More work moves through the same website, with less time between handoffs.

But the moment several people and several agents are working on the same website, you need a control layer to manage roles, permissions, approvals, revision history, and one source of truth.

A CMS lets teams move at AI speed without losing track of who changed what, which version is approved, and what is safe to publish.

3. Delegate: one person, many systems

Here the logic changes. You are still one person, so there is little coordination with other people. But the work now spans many systems: a CMS, an email marketing platform, a commerce system, a CRM, and a planning tool.

When one person spans many systems, no single product sees the whole job. The center of gravity moves to the coordinator: an automation tool that connects your systems, or an AI agent that works across their APIs.

That is why this quadrant is debatable. For a short-lived campaign, you may not need a traditional CMS. You might use an AI builder for the site and an automation tool or agent to coordinate the rest.

But that only works while the content is small, short-lived, and easy to manage by hand. Once the content has to be structured, reused, updated, approved, or kept consistent across systems, you need a trusted source for it.

4. Orchestrate: many people, many systems

This is the most complex environment, and the clearest case for a CMS.

A company campaign can involve many people and many systems at once: a marketer plans the campaign, a designer reviews the creative, legal approves the content, an editor publishes the page, marketing operations builds the email, and a commerce manager checks the discount. Every person has a role, and every system has a workflow.

AI can remove much of the coordination work: reminders, status updates, handoffs, and manual routing. But coordination is not control. Someone still has to approve the content, approve the promotion, and answer for the campaign's effectiveness.

In this quadrant, the CMS has two jobs. First, it has to govern and accelerate the work that happens inside the CMS. Second, it has to make that work usable by the broader digital ecosystem.

The CMS is not necessarily the orchestrator of that ecosystem. It is the governed workspace where people and agents can work safely, and the trusted source that other systems and agents can read from, write to, and build on.

At this scale, and at AI speed, a weak content foundation becomes expensive fast. A strong CMS is not optional.

From unbundling to rebundling

One thing the grid does not show is where the market is moving the fastest. Right now, most of the visible energy is on the bottom row of Assist and Delegate, sections 1a and 3a, where no control plane is needed: one person using AI to create and coordinate faster.

In Assist, that means AI site builders that turn an idea into a working website. In Delegate, it means agents and automation for single-person workflows across different systems.

Lovable reportedly reached roughly $400 million in annual recurring revenue less than two years after launch. n8n raised $180 million at a $2.5 billion valuation in 2025.

But once many people are involved, individual productivity is no longer enough. Organizations need productivity, coordination, and control.

The current wave of AI site builders is mostly making one person faster. The next wave has to make organizations faster without losing trust.

AI is unbundling creation from the CMS and driving its cost toward zero. But once creation becomes cheap and abundant, the value shifts to control.

That is where rebundling starts. The next generation of products will combine AI-powered creation with a trusted control plane.

So, is the CMS dead? No. Its role is changing.

The more AI you use to create, translate, update, and publish content, the more you need a system that keeps that work structured, approved, reusable, and safe.

That means that a CMS is not a competing line item to your AI budget. It is what makes that budget pay off.

And the real risk is not that AI replaces your CMS. It is running AI without one.

AI gives you speed. A CMS gives you control at speed.

Maintainers of ECA, FlowDrop, and Maestro are discussing whether Drupal automation tools can share backend contracts without merging their interfaces or use cases. Based on details Shibin Das shared with The DropTimes, the planning-stage work focuses on common graph models, shared language, and reusable processor patterns. The discussion matters for developers who now rebuild similar automation logic across different Drupal workflow systems and for teams that need governance, permissions, and observability to remain close to Drupal.