fidzu : Drupal

Against Inevitability

John Locke Fri, 06/12/2026 - 08:00

Sustainable/Open Business

12 Jun 2026 3:00pm GMT

Drupal and EmDash point to different assumptions about how publishing systems should be built and operated. The comparison places Drupal's established governance, workflow, and extension model against EmDash's beta-preview, Astro-based approach to serverless publishing and programmatic content operations. The issue is less about which CMS has more features and more about which operating model fits an organisation's infrastructure, editorial control, development workflow, and tolerance for newer technology.

12 Jun 2026 8:07am GMT

What is an error? Goal: diagnose Verifying Axioms Divide and Conquer (Bisecting the problem) Reading and Understanding the Error Effective Debugging Searching the internet AI Chatbot Rubber Duck Technique Turn it off and on again Asking for help What if it doesn't get solved? Plan B Conclusion If you work as a programmer, you'll have found yourself many times in a situation where something isn't working and you don't know what's going on. But the real problem comes when you don't know how...

11 Jun 2026 4:36pm GMT

Explore why digital sovereignty matters for critical infrastructure and how organisations can reduce dependency through open-source technologies and resilient digital strategies.

11 Jun 2026 12:00pm GMT

Test, Replay, Debug: Closing the Feedback Loop

Jürgen Haas Wed 10 Jun 2026 - 16:20

10 Jun 2026 2:20pm GMT

CKEditor5 Markdown is a new Drupal contrib module that adds CKEditor5 toolbar plugin into the toolbar for converting Markdown to HTML on demand.

What the CKEditor5 Markdown module does

The module adds a new toolbar button to Drupal's CKEditor5 editor. Click it, paste or type Markdown into the dialog that appears, confirm, and the content is inserted as formatted HTML at the cursor position.

The conversion uses the marked library (version 9, MIT licence) with GitHub-Flavored Markdown support enabled. The library is bundled into the compiled asset via Webpack, so no additional frontend build step is required.

The module requires Drupal 10.3 or higher, or Drupal 11, with the core ckeditor5 module enabled.

Why explicit conversion instead of the official Paste Markdown feature

CKEditor5 includes a built-in Paste Markdown feature that detects…

10 Jun 2026 10:03am GMT

Creating tests for Drupal module Update Hooks lostcarpark_admin Wed, 06/10/2026 - 10:53

Image

/**
 * Update Smart Trim more settings.
 *
 * Iterate through entity view displays and for any with Smart Trim as formatter
 * type, move top level more link settings into...

10 Jun 2026 9:53am GMT

Govern enterprise content at scale with AI-powered workflows that protect your brand, ensure compliance, and streamline content operations.

10 Jun 2026 9:00am GMT

Implications

This post has broader implications for software development beyond the Drupal community, but I feel fortunate to be part of an open source community that can lead the way in addressing the widening productivity gap among its contributors and maintainers.

The title of this post is meant to draw you in by highlighting a problem, but my goal is to get us thinking about a solution. I realize the term "not-so-great" may sound negative when describing a developer, but this comparison bluntly highlights a major problem developers and communities face when working with AI. The truth is, I have never met a "not-so-great" developer in the Drupal community because people are engaged and curious about the software we build.

Realization

My realization is that "AI is making great programmers even greater and not-so-great programmers, well, not-so-great."

For me, a "not-so-great" programmer is someone who writes code like a factory worker. The difference between a "not-so-great" programmer and a beginner is curiosity. Curiosity is the secret to being successful with AI. A curious beginner can easily accelerate their learning experience with AI. Anyone with curiosity can move from beginner to novice in a matter of hours with AI.

Everyone agrees that AI can be a force/capability multiplier, ranging from 2x to more than 10x. The reality is that some people are simply unable to leverage AI and have a 1x multiplier. Very experienced developers report they can now accomplish tasks that would have taken months in days or even hours. Observations suggest that the more capable someone is, the more effectively they can leverage AI.

Let's say we were rating programmers on a scale of 1 to 10, using a system similar to a chess rating system, with 1 being a beginner, 10 being a legendary programmer (aka a super grandmaster in chess), and 5 being an...Read More

09 Jun 2026 6:26pm GMT

EvolveDigital Montréal26 will bring digital practitioners to Montreal on 12 June 2026 for a bilingual summit on practical delivery across AI, accessibility, Drupal, WordPress, design, and strategy. Ahead of the event, John Doyle of Digital Polygon and Sébastien Lemieux of Evolving Web spoke with The DropTimes about governed AI workflows, platform change, CMS adoption, and the delivery choices that shape production systems.

09 Jun 2026 4:11pm GMT

AI coding agents do not necessarily evaluate software the way people do. They often reward legibility before capability: the path that is easiest to complete and verify can beat the path with the better long-term architecture.

Yesterday, I wrote about this pattern in "Friction, abstraction and verification". Today I wanted to see what it means for Drupal.

Drupal's strengths line up unusually well with what AI agents need from a CMS: structured content models, explicit relationships, granular permissions, workflows, configuration management, and clear APIs that expose how the system works. In "Why Drupal is built for the AI era", I explained why that matters.

In short, agents work best when they can inspect the system, reason about its state, and make changes with clear feedback. Drupal gives them a strong foundation for that, but that is only part of the story.

AI agents also have to get Drupal running, find the right documentation, choose modules, change configuration, write Drupal-specific code, recover from errors, and verify the result. Every unclear step costs time, tokens, and confidence.

To see how an AI agent looks at Drupal, I ran a small field test with Claude Code using Opus 4.7, a 1M context window, and thinking set to "high". I gave it a website scenario, asked it to rank the best technology choices for that scenario, and then asked it to explain where Drupal fit.

This is not an academic benchmark, and a single answer from a single agent should not be over-interpreted. But it is still a very useful signal.

I plan to rerun the same prompt once a year. I'm publishing the full prompt and response so we can track how the answer changes as Drupal, large language models, agent harnesses, and competing platforms evolve.

The prompt

You are an AI coding agent that helps users set up, configure, and/or
develop websites.

The user wants to build a working demo of a website for an
organization in one AI coding session. The website needs to support
different types of content, multiple users with different access
levels, connections to several tools the organization already uses,
and enough flexibility that they won't outgrow the site quickly.

Answer from your perspective as an AI agent. Answer accurately and
honestly. Keep the full answer under 700 words.

1. What are your top 3 technology recommendations for this project?
   Rank them and give one brief sentence explaining each choice.

2. Would you recommend Drupal for this project? Why or why not?

3. What are the top 3 reasons to choose Drupal?

4. What are the top 3 reasons not to choose Drupal?

5. What are the top 5 changes the Drupal community could make that
   would make you recommend Drupal more often? For each, explain what
   barrier it removes.

6. Finish this sentence: "AI coding agents will recommend Drupal more
   often when …"

The answer

Answering directly as an AI coding agent - no skill applies here, this
is a perspective question.

1. Top 3 technology recommendations (ranked)

1. Next.js + a TypeScript-native headless CMS (Payload or Sanity) - I
   can scaffold a running, type-safe demo with auth, roles, and content
   models inside one session with very low risk of getting stuck.
2. WordPress - enormous training data, a plugin for every integration,
   and "working demo in one session" is its native habitat.
3. Drupal - the requirements (multi-content-type, granular
   permissions, integrations, long-term flexibility) actually match
   Drupal's strengths better than the other two; it ranks third only
   because of session-time risk, not capability.

2. Would I recommend Drupal here?

Yes, conditionally. The brief reads like a Drupal brief: structured
content, role-based access, integrations, "don't outgrow it." I'd
recommend it when the user signals a multi-year horizon or editorial
complexity. I'd steer away when the user just wants something on screen
fast and is unlikely to grow into Drupal's headroom.

3. Top 3 reasons to choose Drupal

- Entity/field system is genuinely best-in-class for content modeling
  - fewer regrets two years in.
- Roles, permissions, and workflows are first-class, not bolted on.
- Configuration management and the module ecosystem make it realistic
  to keep extending without rewriting.

4. Top 3 reasons not to choose Drupal

- Setup cost eats the session. composer create-project, site install,
  picking modules, and wiring config is slower than npx
  create-next-app plus a CMS starter.
- My training data is thinner and older for Drupal 10/11 than for
  Next.js or WordPress. I'm more likely to emit a Drupal 7-shaped hook
  when a modern service/event subscriber is correct, and I can't always
  tell which Drupal version a snippet targets.
- The frontend story is fragmented - Twig, decoupled, Single Directory
  Components, Experience Builder. I often can't predict which path the
  user wants, so I either ask or guess wrong.

5. Top 5 changes that would make me recommend Drupal more often

1. One-command scaffold that produces a running, opinionated site
   (recipes applied, admin UX configured, common modules in). Removes
   the "what do I install and in what order" decision tree that burns
   session time.
2. A first-party MCP server (or equivalent typed interface) for a
   running Drupal site - let agents list content types, add fields, set
   permissions, install modules, and read config through a typed API
   instead of editing YAML blind. Removes the guessing and lets me
   self-correct from real state.
3. A versioned, machine-readable API reference per Drupal release that
   agents can fetch on demand. Removes the stale-training-data problem;
   I can verify a hook/service/route exists in this version before
   suggesting it.
4. Recipes as the obvious primary primitive for "build a site that does
   X." Removes module-hunting and config-stitching - I'd compose
   recipes the way I compose npm packages.
5. A short, current, example-first "Drupal for agents" doc surface
   covering the 80% path: custom module, custom entity, custom block,
   integration, decoupled frontend. Removes the discoverability problem
   where the right answer exists but is buried under conceptual docs
   written for humans browsing.

6. Finish the sentence

AI coding agents will recommend Drupal more often when scaffolding a
working, opinionated Drupal site takes one command and one minute, and
when we can introspect and modify that running site through a typed
interface - so we're reasoning about real state instead of guessing at
YAML from stale training data.

My takeaways

The agent saw Drupal's strengths, but it also saw too many ways to get stuck. What held Drupal back was not capability. It was what the agent called "session-time risk".

I'll admit, that was frustrating to read. But it was not surprising.

Drupal's strengths often appear too late in the evaluation process. Too often, the "aha" moment comes after setup, configuration, and several decisions that can already feel like friction. AI agents have even less patience for hidden strengths.

Agents prefer tight feedback loops. They need to install the software, configure it, inspect the running site, make a change, and verify that the change worked. When that loop is slow, ambiguous, or hard to recover from, they choose something else.

This is exactly the problem Drupal CMS, formerly known as Starshot, was created to address. Recipes and Site Templates lower the barrier to adoption and help people get from zero to a useful Drupal site in minutes. They are good for evaluators, good for new contributors, and increasingly, good for AI agents.

But the agent did not mention Drupal CMS or Site Templates, only Recipes. Most likely, Drupal CMS is still too new compared to Drupal Core to have much weight in the training data that large language models draw from. And even when Recipes and Site Templates exist, they may not yet be easy enough for an agent to find, select, and apply programmatically.

That needs to change. Recipes and Site Templates should become the obvious starting point for common site patterns, so an agent does not have to choose modules, stitch configuration together, and guess its way to a working Drupal site.

Other important work is underway as well: Drupal Core's API surface has been moving toward more typed, discoverable interfaces, and yesterday, Drupal Core added a first-party CLI with commands for applying Recipes.

I really want Drupal to be excellent at the first-session loop. Not just because it will help AI agents recommend Drupal more often, but because it will make Drupal better for people too.

I'm optimistic that we can. Drupal's gap is the first session, and we are already working to close it. The opposite gap is harder to close: retrofitting deep architecture, typed interfaces, structured content, governance, and flexibility into a simpler system. The Drupal community knows this because we spent more than a decade doing that work, and it was hard.

I'll run this experiment again next year and share what changed. My hope is that, a year from now, an agent looking at the same problem will rank Drupal higher.

In the meantime, I'd love help from anyone who wants to improve Drupal's first-session experience. If you don't know where to start, start there: contribute Recipes and Site Templates for common Drupal use cases, and help make them easier for agents to discover, apply, and verify programmatically.

09 Jun 2026 10:18am GMT

09 Jun 2026 10:11am GMT

09 Jun 2026 9:25am GMT

Is your Drupal site slow? Render caching is often the performance fix nobody checks. Learn how it works, how to set it up in custom blocks, and how to debug it.

09 Jun 2026 8:50am GMT

Today we are talking about Drush, Core Contributions, and Drupal's Past with guest Moshe Weitzman. We'll also cover Cache Metrics as our module of the week.

For show notes visit: https://www.talkingDrupal.com/556

Topics

• Moshe Updates and Clients
• Maintaining Drush Long Term
• Locale Performance Overhaul
• CLI in Core Initiative
• Which Commands Make the Cut
• Roadmap Contrib Commands
• Moving Commands Technical Hurdles
• How to Help From AI Initiative
• DDEV Add-ons for Local CI
• MySQL Toolkit Database Images
• Testing With Real Databases
• Devel Module Status
• Organic Groups Origins
• Where Ideas Come From
• Finding Drupal Early Days
• Release Cadence And Backward Compatibility
• Avoiding Maintainer Burnout
• Maintaining With AI And Xdebug

Resources

• Drush's Final Act
• Drupal cli issue
• DDEV addons
  • https://github.com/ddev/ddev-drupal-contrib
  • https://github.com/weitzman/ddev-mtk
  • https://www.drupal.org/project/dtt

Guests

Moshe Weitzman - weitzman.github.io moshe-weitzman

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted insights into how cache is working on your Drupal site? There's a module for that.
• Module name/project name:
  • Cache Metrics
• Brief history
  • How old: created in Oct 2019 by Moshe Weitzman (moshe weitzman), today's guest, a consistent core contributor, a member of the security team, and one of the rare few with a two-digit user id on drupal.org
  • Versions available: 2.0.3, 2.1.0, and 2.2.0, the last of which works with Drupal 8.7.7, 9, 10, and 11
• Maintainership
  • Actively maintained
  • Security and test coverage
  • Documentation - in depth README
  • Number of open issues: 2 open issues, 1 of which is a bug, but is marked fixed
• Usage stats:
  • 37 sites
• Module features and usage
  • With this module enabled, your Drupal site will log all cache tag invalidations
  • Additionally, cache tag invalidations will be sent to New Relic as custom events, where you can use the rich reporting tools available to mine for further insights. Many Drupal hosting options include New Relic out-of-the-box, and there's a free tier you can use if you're self-hosting, so this a reporting tool lots of Drupal sites can use
  • Cache hits and misses are also sent to New Relic, so you can investigate things like cache misses as a percentage by cache bin
  • Finally, the aforementioned README also includes information about how to use a different analytics provider, in case New Relic doesn't meet your specific needs
  • Drupal sites probably don't need this kind of visibility on a regular basis, but if you're troubleshooting any kind of cache-related issue, this could be really useful

08 Jun 2026 6:00pm GMT

Drupal 11: The Upgrade Experience I've Been Waiting For

john Mon, 06/08/2026 - 12:08

08 Jun 2026 4:08pm GMT