Drupal.org aggregatorImplications
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.
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 …"
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.
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
Drupal 12 is coming later this year. As with previous major releases, the contributed ecosystem will require updating for breaking changes . Thousands of modules and themes will need their deprecated API uses updated before they are ready. Doing that by hand, across all of contrib, would cost the community an enormous number of hours.
That is the job the Project Update Bot exists to do. We have refreshed it, and it now targets Drupal 12 readiness: it scans contributed projects automatically and opens issues with patches that fix deprecated API uses for you.
If you are a maintainer, you should already know the bot. For the Drupal 12 cycle, our rector rules grew to cover more than 80% of the deprecated API uses introduced in that release. Using our proven toolset: Gábor Hojtsy's Upgrade Status for the analysis, and Drupal Rector for the fixes, now maintained primarily by SWIS and the glue that puts it all together Project Analysis.
Two things improved this round. Rule coverage is more complete, some of that came from AI-generated rector rules based on Dries Buytaert's drupal-digests. And submodule dependencies are now resolved during analysis. In the earlier cycles we scanned submodules but not their dependencies, which caused failed scans and false errors. That is fixed now, so results are cleaner and considerably more accurate.
Patches arrive as either GitLab or Drupal.org issues. The two work a little differently, and every issue the bot opens explains how to apply the patch, pause the bot, or close it. You stay in control of your project throughout.
If you have questions or want to help, we are in #d12readiness on Drupal Slack. And if a patch looks wrong, tell us so we can fix the rule for everyone, open an issue in the Drupal Rector or project_analysis queue.
The bot builds on a lot of other people's work: Upgrade Status, Drupal Rector, and the AI-generated rules derived from drupal-digests. Thanks also to the maintainers who let us test the refreshed bot on their repositories.
09 Jun 2026 10:11am GMT
This blog post summarizes the key insights from the CX Decoded podcast episode featuring Dries Buytaert, the founder of Drupal and Executive Chairman of Acquia.
In the fast-moving world of digital experience, few names carry as much weight as Dries Buytaert. As the creator of Drupal, he has spent over two decades navigating the evolution of the web. But in his latest appearance on the CX Decoded podcast, Dries issued a candid warning: AI isn't just another tool - it is a fundamental disruption that is stress-testing every business model in its path.
During the conversation, Dries broke down the "Stable Triangle" of open source and explored why the rise of AI is creating a period of both incredible excitement and existential fear.
For 20 years, the Drupal ecosystem has relied on three balanced sides:
AI is currently hitting all three sides simultaneously. It is changing user expectations for what a CMS should do, challenging the hourly-billing model of agencies, and flooding the contributor community with "AI slop."
One of the most provocative points Dries made was the distinction between a contribution and a can-tribution.
Because AI lowers the barrier to entry, anyone can now generate a thousand lines of code and submit it to an open-source project. This sounds like a win for innovation, but Dries warns of "AI slop" - low-quality, AI-generated code that lacks context or security rigor. For human maintainers, reviewing this influx of code is exhausting.
The takeaway: Just because you can contribute doesn't mean you should if you don't understand what the AI has produced. Quality and accountability must remain human-led.
The agency world is facing a reckoning. If an AI can generate a website or a specific feature in seconds, charging by the hour becomes a race to the bottom.
Dries argues that agencies must evolve. Their value will no longer be in the "writing of code," but in strategic configuration, high-level architecture, and accountability. In an AI world, clients aren't paying for labor; they are paying for a partner who can guarantee that the AI-generated solution actually works, is secure, and achieves business goals.
Dries also touched on the "broken deal" between publishers and AI companies. Currently, AI crawlers extract value from publishers' content to train models, often giving nothing back in return - no traffic, no revenue, and no attribution.
He highlighted a potential shift toward marketplace models (similar to what companies like Cloudflare are exploring) where publishers can set terms for how their data is used. For mid-sized publishers, this might be the only way to survive the "extraction economy."
The podcast concluded with a sobering example: Tailwind Labs. Dries used this as a "canary in the coal mine" for business models. When the thing you sell (like a CSS framework or specific design components) can be perfectly specified and generated by an AI prompt, your original value proposition disappears.
Dries's message to CX leaders and developers is simple: Prototype fast with AI, but build for the long term with a robust CMS. AI is an incredible accelerator for those with expertise, but a dangerous trap for those looking for shortcuts. To survive the stress test, businesses must move away from selling "tasks" and start selling "results and reliability."
To hear the full conversation, check out the CX Decoded podcast episode on CMSWire.
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
Drupal.org aggregatorToday 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
Resources
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
08 Jun 2026 6:00pm GMT
Drupal 11: The Upgrade Experience I've Been Waiting For
john
Recently I upgraded this site from Drupal 10 to Drupal 11. While I've been through my share of Drupal upgrades over the years, this one stood out for a different reason: it was surprisingly straightforward.
Like many Drupal site owners, I started with the Upgrade Status module. Before touching core, I wanted a clear picture of what needed attention. Upgrade Status did exactly what it was designed to do, identifying deprecated code and highlighting modules that weren't quite ready for Drupal 11.
08 Jun 2026 4:08pm GMT
LocalGov Drupal Camp 2026 will bring together public-sector practitioners, developers and digital service teams at Sheffield Hallam University on 11-12 June 2026. Speaker previews released ahead of the event show a programme centred on practical implementation experiences, artificial intelligence governance and product-led approaches to digital services, with knowledge sharing and peer learning emerging as common themes across multiple sessions.
08 Jun 2026 2:28pm GMT
AI coding agents like Claude Code and OpenAI Codex tend to choose the path that is cheapest to complete. They work within a budget of tokens, context, time, tools, and permissions. Every step spends from that budget: reading documentation, installing software, running it, configuring it, changing it, and fixing errors.
For Open Source, this is a rare opportunity. AI agents could become its biggest adoption engine yet. While that should energize Open Source communities, it should also make proprietary vendors deeply uncomfortable.
Many proprietary software vendors have spent years optimizing for a human buyer journey: capture a lead, qualify the buyer, force a signup, offer a demo or trial experience, ask for a credit card, schedule a sales call.
Humans may grumble but keep going. To an AI coding agent, these are blockers, not buying steps.
Open Source starts from a different place. AI agents can read the source code, run it locally, and change it without asking anyone for permission. That does not guarantee adoption, but it removes the proprietary gates that slow agents down.
But being Open Source is not enough. Open Source removes the "permission barriers", but it can still have "execution barriers". If an Open Source project is hard to install, configure, extend, debug, or verify, an agent may choose an easier Open Source project instead.
In that sense, AI agents amplify an old truth about software adoption: the best software does not always win. The software with the easiest path to a working result often does.
But AI agents amplify that truth through "silent rejection". A human evaluator might complain, ask for help, file an issue, or write an angry Reddit post. An AI agent just tries another path. You may never know your software was considered and rejected.
If you want your project to be adopted, you have to make the best path the easiest one to complete.
And "easy" means more than low friction. For an AI agent, there are at least three costs: friction, abstraction, and verification.
Friction is the cost of getting to a system the agent can run and change. Some friction comes from the environment: runtimes, containers, databases, package managers, local services, and setup choices that must be installed or configured before useful work can begin. Some comes from access and authorization: private repositories, account creation, credentials, and API keys.
Abstraction is the cost of figuring out what to do next. Once the software is running, the agent still has to know which modules to use, how to structure the data, which settings to apply, which conventions to follow, and how the pieces should fit together. A good site template, recipe, or scaffold packages that expertise so the agent can take several correct steps at once instead of reconstructing the path from scratch.
Verification is the cost of knowing whether the work succeeded. Tests, clear errors, inspectable state, and fast debugging cycles help the agent compare what happened with what should have happened. As I wrote in AI rewards strict APIs, agents do not struggle with complexity; they struggle with ambiguity.
Each cost burns tokens, meaning the AI agent has to spend more of its limited context and reasoning budget reading documentation, comparing different options, or recovering from failed attempts.
This is not just an AI problem. People have always preferred software that is easy to get running, gives them a clear path forward, and tells them when something worked. AI agents make the same preference more obvious because they have even less room for trial and error.
Developer Experience (DX) makes software easier for developers to evaluate, build with, and maintain. Agent Experience (AX) makes software easier for agents to install, modify, and verify.
In practice, the overlap is large. Better scaffolding, clearer errors, faster setup, opinionated best practices, and reliable tests help agents, but they also help developers, evaluators, and contributors.
The cheap-to-run advantage will not belong to Open Source forever. Proprietary vendors and SaaS companies are adding free tiers, programmatic access, and Model Context Protocol servers that give agents tools and context with less friction.
Open Source's structural advantage is about to expand, but it will concentrate in the projects that are easiest for agents to understand, run, and improve.
Every software project will have to earn its place in the agent flow. Being open will get you considered, but being easy to discover, install, inspect, modify, and verify will get you chosen.
08 Jun 2026 7:13am GMT
Hello, Drupal community. The first week of June showed Drupal moving from AI experimentation toward a more practical question: how AI-assisted work should be trusted, tested, and governed.
Several stories this week explored that shift. Amber Matz examined trust and expertise in AI-assisted open-source contributions, while a live experiment tested AI-assisted Drupal 7 migration. The discussion is no longer only about whether AI can be used in Drupal workflows. It is now about reliability, accountability, and the points where human expertise must remain in control.
That concern extends beyond Drupal. Recent coverage of Drupal AI 1.4.0, GitHub's outcome-based validation framework for AI agents, and Carlos Ospina's agentic recipes concept points to the same operational problem. AI systems now require governance, evaluation, and clear boundaries alongside technical experimentation.
Sustainability formed the second major thread. The Drupal Association's support for Acquia's Fair Trade Initiative reopened a familiar question about how open-source projects fund shared infrastructure while remaining community-driven. As more digital services depend on open-source software, stewardship, contribution, and long-term maintenance are becoming increasingly inseparable from technical progress.
Community activity also remained visible. Reflections from DrupalSouth 2026 highlighted collaboration and local momentum, while preparations for DrupalCon Rotterdam 2026 and the return of DrupalCamp Italy showed continued investment in face-to-face knowledge sharing.
Practical site management stories rounded out the week. Coverage included new approaches to file management through the Drupal Form File Usage module and fresh security guidance from Acquia. These updates show how Drupal's surrounding tools continue to mature while supporting day-to-day operational needs.
The coming weeks are likely to bring more examples of AI entering Drupal development workflows. The stronger test will be how clearly those workflows are evaluated, explained, and governed. Open-source projects can adopt automation without losing transparency only when human responsibility remains visible.
Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.
Allen Jason
Junior sub-editor
The Drop Times
08 Jun 2026 5:46am GMT
Drupal.org aggregatorIn the last article in this series I looked at creating a link directory on a Drupal site. In that article I looked at how I set up the links and took screenshots of the sites using a headless Chromium browser as the links were added.
The issue I had was that when I used headless Chromium to take screenshots of the sites the success rate was not very high. In these days of AI attacks, site captcha checks, and cookie popups it turned out to be quite difficult to take a clean screenshot of a site without being blocked either by a CDN or a cookie popup. In fact, most of the time the screenshot would be just a CDN error page.
I therefore looked for a different mechanism. Since I wanted to take a screenshot of a website it made sense to me to use a browser to do this, and because I am already using a browser why not get the browser I'm using to take the screenshot. After a bit of research I realised that creating browser extensions to do this was actually pretty simple. Plus once the screenshot has been taken I can post this to the Drupal site using a REST resource.
The only niggle was that I needed the screenshot to be at a set dimension, since all the link images on the site also have that dimension. That turned out to be slightly more challenging.
In this article we will look at setting up a rest resource to generate (or update) links, and then creating a Chrome extension to take a screenshot of a site at a set resolution.
First, let's look at creating the REST resource in Drupal.
This needs to accept the data from the Chrome extension and generate a Link content entity using that data.
07 Jun 2026 6:15pm GMT
Drupal.org aggregatorFor years, prefetching made me uneasy. It can make websites feel faster, but it also asks visitors to spend bandwidth, CPU, memory, and battery on pages they may never open. That always felt a little wasteful, and maybe even a little disrespectful.
A couple months ago, while updating my HTTP header analyzer, I added support for the Speculation-Rules HTTP header. Learning about the Speculation Rules API inspired me to try it on my own blog.
The idea is simple: a page can give the browser a small JSON rule set that says which links are safe to prefetch, and when. Those rules can live directly in the HTML using <script type="speculationrules">, or in an external file referenced by the Speculation-Rules HTTP header.
For my blog, I added the rules directly to the HTML of every anonymous page request:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/search*" } }
]
},
"eagerness": "conservative"
}]
}
</script>
The rule tells browsers that any same-origin link is safe to prefetch, except for paths under /search*.
The eagerness: conservative setting fires the prefetch on pointerdown or touchstart, meaning the browser only starts prefetching once the user begins to click or tap a link. There are more aggressive options, such as prefetching when a link becomes visible or when a user hovers over it.
Some of you might point out that browsers have supported prefetching for years through the older <link rel="prefetch"> tag. That is true, but I've never loved it.
Traditional prefetching is great when the next page is highly predictable, like the next step in a checkout flow or setup wizard.
On many websites, including my blog, it's anyone's guess what a visitor will click next. Sometimes you can make a smarter guess, but it is still a guess.
And when you guess wrong, visitors spend bandwidth, battery, and compute on pages they never visit. Multiply that across millions of sites and visitors, and those speculative requests add up.
So why implement Speculation Rules? With eagerness: conservative, the browser waits until the user has already started an action. At that point, the navigation is no longer a vague prediction. It is very likely to happen.
Speculation Rules also respect Battery Saver and Data Saver modes. If a device is low on battery, memory constrained, or trying to conserve data, the prefetching is skipped.
So is prefetching still worth it when the user has already started to click? I think so. With eagerness: conservative, the browser only gets a small head start but something is better than nothing.
Browsers already do some speculative loading on their own without Speculation Rules, but only for high-confidence destinations, like the address bar suggestion you are typing toward.
But they will not prefetch arbitrary links on a page, and for good reason. Prefetching /logout, for example, would sign the visitor out, even if they change their mind and never complete the click or hit Enter.
That is why Speculation Rules can be useful. You can tell the browser which paths are safe and which to leave alone.
In short, Speculation Rules changed my mind because they make prefetching feel more responsible: don't prefetch too much, don't prefetch too early, and only give the browser a safe hint when the user's intent is clear.
05 Jun 2026 2:37pm GMT
For organisations still running Drupal 7, the challenge is often less about whether to upgrade and more about how to modernise without disrupting critical business operations. Niels de Feyter, founder and lead developer of CodeLift, argues that successful upgrades depend on preserving a system's observable behaviour while modernising its underlying platform. In this interview with The Drop Times, he discusses verification, migration complexity, ageing infrastructure, AI-assisted development, and the risks organisations face as legacy systems grow older.
05 Jun 2026 2:03pm GMT
Explore the future of enterprise AI at The AI Summit London 2026. See how open-source architecture is becoming the foundation for secure, scalable, and future-ready enterprise AI.
05 Jun 2026 10:00am GMT
Drupal 11.4 is the next minor release in the 11.x branch, with a stable launch planned for the week starting June 22, 2026. It doesn't break backward compatibility for public APIs, but it brings plenty of concrete improvements: PHP attribute routing, a new bootstrap based on Symfony Runtime, Brotli compression for assets, SEO-oriented robots.txt changes, and a whole list of deprecations worth handling in custom modules. Below I walk through what actually changes compared to Drupal 11.3.
05 Jun 2026 4:38am GMT