I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{ "linkset": [ { "anchor": "https://dri.es/search/json", "service-desc": [ { "href": "https://dri.es/openapi.json", "type": "application/openapi+json" } ] } ] }

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

Matthew Saunders links his board candidacy to a question now facing Drupal: how the Association can earn community trust through measurable listening, accessible participation, and public accountability.

The Drupal project runs one of the most disciplined coordinated-disclosure programs in open source, and it has done so through volunteer effort for more than two decades. Millions of sites, many operated by governments, universities, and enterprises, depend on it.

This post is the first in a series stemming from the Drupal AI Security Initiative. Before I dive into how it's organized and what we've found, I wanted to share a post about how Drupal Security Team already works, because the initiative is built to supplement that foundation, not to repair or replace it. Note: this post assumes you are familiar with coordinated disclosure, CVEs, and severity scoring in general and focuses on what Drupal specifically does.

Coordinated disclosure, on a fixed cadence

Reports arrive in a private queue. A Security Team member takes triage duty on a two-week rotation, confirming whether a report is a real, in-scope vulnerability. Once validated, the affected project's maintainer and the original reporter collaborate in the confidential issue where the fix is written, reviewed, and scheduled. All of this stays out of public view until the fix and security advisory are ready on a release day.

Drupal has a predictable release cadence:  advisories publish on Wednesdays, with a Public Service Announcement the Monday before on the very rare occasion a highly critical release warrants advance warning. 

Scoring and identifiers

Every advisory carries a risk score using a system rating each issue 0–25 across six factors (access complexity, privilege required, confidentiality and integrity impact, exploit availability, and target distribution) mapped to labels from Not Critical to Highly Critical. Drupal's risk system was developed based on the NIST Common Misuse Scoring System. The project is now considering moving to CVSS, a more widely adopted standard. Drupal is also a CVE Numbering Authority, so it assigns its own CVEs: a level of formality most community projects don't reach. Summary data about the security track record is public with full details available as a series of posts or a JSON API with data going back to 2006.

What’s public and what stays private

The line between disclosure and discretion is drawn sharply. After release, advisories include all necessary details: affected project, severity, vulnerability type, affected versions, remediation, any possible mitigating factors, and CVE. Before release, the member disclosure policy permits a trusted insider to share only what is already public plus the bare numeric severity, never the affected project, the nature of the bug, or how to mitigate it. Members can't even let an employer market the fact that an employee had early knowledge.

Protection at the network layer

To protect site owners in the window between disclosure and patching, the Security Team and the Drupal Association offer Drupal Steward. Drupal Steward is a web application firewall (WAF) where Drupal Association engineers work with the engineers who wrote the security advisory to develop a rule that blocks the exploit at the request layer that goes live the moment the advisory does. This provides a virtual patch for highly critical, mass-exploitable bugs, but is not a replacement for patching.

The coverage model and its scope

Scope is defined just as clearly. Advisories cover Drupal core, plus contributed projects hosted on Drupal.org that opt into coverage (marked with a shield icon), and only for stable releases. Some things are deliberately out of scope: external libraries a module depends on and bugs requiring high-level administrative permissions. When a maintainer is unreachable, the team can mark a project unsupported.

By design the team is largely reactive: it responds to reports rather than continuously auditing Drupal core and tens of thousands of contributed modules. Members are asked for a few hours a month, a valuable contribution from highly skilled and in-demand individuals. The process is solid, but bandwidth has always been the primary bottleneck.

Scaling our response in the AI Era

Addressing that bottleneck is the whole point of this effort. It's also the founding premise of Alpha-Omega's Security Engineers in Residence program funding: that threat volume and pace are outrunning what volunteer hours can cover. AI has lowered the cost of finding and exploiting vulnerabilities. It enables high-volume report generation and can infer what a quietly worded commit was really fixing. A security process built around scarce attention and a modest head start now faces adversaries operating at machine speed.

Drupal’s security workflows are mature, documented, and trusted. The challenge now is scaling Drupal’s defensive bandwidth and throughput to match that offensive speed. That's what the Drupal AI Security Initiative adds, and it's the subject of the next post in this series.

If you'd like to help in the meantime, the most valuable things any contributor can do are what the team has always relied on: write secure code, report issues responsibly, and, if you have a track record in the community,  consider joining the Security Team.

Tiffany Farriss authored this post and is responsible for its content. Members of the Drupal AI Security Initiative (Greg Knaddison, Tim Lehnen, and Drew Webber) and George DeMet contributed context, editing, and review. AI tools (Claude by Anthropic and Gemini by Google) assisted with research, organization, and editing. All facts were verified by humans against primary sources.

Take Away Marcin Grabias, Senior Drupal Engineer and maintainer of the Drupal LMS module, used Claude Code to merge two near-duplicate activity plugins into a single configurable one in roughly ten minutes of work that would have taken an hour by hand.

The Drupal LMS module lets site builders define quiz-style "activities": question types a learner answers as part of a course. For a while, LMS shipped two separate plugins for selection-based questions: one for single-choice answers, one for multiple-choice. They did almost the same thing internally. The only real difference was the configuration toggle that didn't need to live in two separate classes once Activity - Answer plugins became configurable.

Issue #3546362 merges the two plugins into a single configurable one, writes an update hook so existing sites migrate their configuration automatically without breaking, and updates the QA fixtures and functional tests that reference the old plugin pair. None of this is conceptually hard. Every long-lived module accumulates this kind of work, where touching four or five files consistently is non-negotiable and a missed reference breaks an update path for every site running the module.

That combination, low conceptual difficulty, high mechanical thoroughness, turns out to be exactly where an AI coding tool earns its keep.

The Workflow: Solve It. Then Let the Prompt Become the Issue.

As the module's maintainer, I didn't start by filing an issue and waiting for someone to pick it up. I solved it myself, with Claude Code doing the implementation.

1. I wrote a detailed prompt describing the merge: which two plugin classes to combine, what the resulting configuration should look like, what the update hook needed to handle for existing activity type entities, and which test fixtures and functional tests needed updating.
2. Claude Code implemented the merge, the update hook, and the test updates in one pass.
3. I reviewed the diff and made two or three rounds of corrections (nothing structural, mostly coding-standards and best-practice nits).
4. Once the change was solid, I opened the merge request and filed the drupal.org issue, using the same prompt, lightly trimmed, as the issue's Problem/Motivation and Proposed resolution text.

That last step is worth sitting with. The prompt wasn't a throwaway instruction I deleted once the code worked. It was specific and complete enough that it doubled as the project documentation other contributors would read. Writing a good prompt and writing a good issue summary turned out to be the same task, done once.

The Math: Ten Minutes vs. an Hour

The ten-minute number assumes one more thing, though: a codebase that's giving the agent good examples to work from. Start to finish, including my review and correction passes, this took about ten minutes. Finding every reference to the two old plugin classes, writing the update hook, regenerating the QA fixtures, and adjusting the functional tests by hand would have taken me roughly an hour.

Claude Code isn't faster here because it's "smarter." Repeatable, multi-file, consistency-dependent work is exactly what thoroughness-by-checklist is good at. Checking every reference to a renamed class across five files is something an agent handles in seconds without losing its place, while a human doing the same task fights boredom and the risk of missing the one reference buried in a test fixture. The hour I'd have spent wasn't an hour of hard thinking. It was an hour of careful, repetitive checking, which is the part of the job that's safe to delegate, provided someone still reviews the result.

The Codebase Is Part of the Prompt

It's easy to focus on the prompt and forget the other half of the equation. Claude Code is pattern-matching against whatever code already surrounds the change. A detailed prompt tells it what to build; the existing codebase tells it how things are built here. If that codebase is inconsistent, or full of workarounds and dead patterns, the agent will happily extend the inconsistency, with no way to know that the surrounding code is something to avoid imitating.

The Drupal LMS module's plugin architecture is consistent and modern, including typed properties, constructor-based dependency injection, and configuration schemas that follow Drupal's own conventions throughout. That's exactly the kind of codebase an agent can extend correctly on the first attempt, because the pattern it's matching against is the pattern you actually want repeated. The corrections in this case were minor precisely because there wasn't a backlog of inconsistent legacy code for Claude Code to mistakenly treat as precedent. On a messier, older codebase, the same prompt would likely have needed more correction rounds, not because the agent got worse, but because it had worse examples to learn from in the surrounding files.

This cuts both ways for anyone evaluating how well AI tools will work on their own project. The return on a good prompt is capped by the quality of the code already there. Cleaning up codebase inconsistencies isn't just good practice anymore; it's also an investment in how well an AI agent will be able to work in that code afterward.

What Went Wrong (Briefly) and How to Fix It

Nothing in the first pass was structurally wrong. The corrections across those two or three iterations were about coding standards and Drupal-specific best practice, the kind of thing a thorough code reviewer would flag.

The interesting part isn't that there were corrections; it's what happens to them afterward. Rather than re-explain the same coding-standard preference every time it comes up, I keep a running set of project conventions in CLAUDE.md, the instructions file Claude Code reads at the start of a session. Something like:

## Coding Conventions - Use typed properties and constructor property promotion where the module's minimum PHP version allows it. - Plugin classes depending on services must use dependency injection via `create()`, never `\Drupal::service()` calls inside plugin logic. - Update hooks must be idempotent — check the current state before mutating config, since update hooks can be re-run in some workflows. - New configurable plugins need a corresponding entry in `tests/data/activity_types.yml` before functional tests are updated.

Every correction I make more than once is a candidate for this file. It's a small bit of overhead the first time, and it means the next plugin merge, or the next contributor using Claude Code on this codebase, doesn't relitigate the same coding-standards conversation. The conventions compound; the corrections don't repeat.

Why I Don't Hand Off to Multiple Sessions

It's tempting to treat this kind of repeatable work as something you can queue up and walk away from. Kick off a few sessions, come back when they're done. I don't do that, and I don't think it's the right tradeoff for code quality.

Every session I'm not actively reviewing is a session where Claude Code is making judgment calls without my insight in the loop. Spread across multiple unsupervised sessions, two things happen. The result gets less reliable, because small wrong assumptions compound instead of getting caught at step two; the cost goes up, because more back-and-forth is needed to recover from those assumptions than would have been needed to just confirm them with me directly. A single session where I review every proposed change as it's made costs more of my attention up front, but it costs less overall, and it's the only version of this where I can say with confidence that the result is correct. Not "probably correct, I'll find out in code review."

That's the actual efficiency claim here, and it's worth being precise about it: the time saved comes from delegating mechanical thoroughness, not judgment. The ten minutes still include me reviewing every change.

What Generalizes

This was a small fix to a Drupal module, but the pattern holds for AI-assisted work generally:

• A detailed prompt is documentation, not scaffolding. If you write it with enough care to drive a correct implementation, it's usually already good enough to be the issue, the PR description, or the changelog entry. Writing it twice is wasted effort.
• Mechanical thoroughness is the right thing to delegate; judgment isn't. The hour this would have taken by hand was mostly careful checking, not hard decisions. That's the profile of a task where an agent saves real time without costing you quality.
• Live review beats batched review. Catching a coding-standards issue at the moment it's introduced is cheaper in time, tokens, and correctness than discovering it after several unsupervised sessions have built on top of it.
• Recurring corrections belong in a conventions file, not in your head. A CLAUDE.md (or equivalent instructions file) that accumulates project-specific standards turns "I have to say this again" into "the agent already knows this."
• The codebase is part of the prompt. An agent extends whatever patterns already surround it. A clean, consistent codebase gets clean, consistent output on the first try; a messy one teaches the agent to be messy too. None of this requires exotic tooling. It requires treating the prompt as a real artifact and treating review as something that happens during the work, not after it.

If you're trying to figure out where AI genuinely speeds up your development workflow, and where it doesn't — we'd love to hear about your project.

I've stepped into the role of interim CEO of the Drupal Association for a limited period, expected to last six to twelve months. My job in that time is to help put the Association on a durable footing. As I undertake that task, I want to start by being direct about where we are and where I'd like to see us go next.

The Drupal stewardship the Association provides costs more every year. That includes running Drupal.org, providing the project infrastructure and putting on DrupalCon. For a long time our events paid for most of it. That stopped being enough several years ago, and we have been covering the gap from our reserves. That is not sustainable, and pretending otherwise would not serve anyone. The Drupal Association releases its financials and 990s every year. (The 2025 audit is expected to be released by the board soon.) An analysis of even just the last few years of publicly available financials tells this story plainly. 

And that is only the part we actually fund. Some of the most critical work of all, like responding to security issues and managing releases, still runs entirely on donated volunteer time or corporate underwriting rather than from an ongoing operating budget. 

The answer is not to ask more of the volunteers, agencies and contributors who have carried this project for two decades. The community’s generosity is the heart of Drupal, and it always will be. The real challenge is that the large enterprises and governments that rely on Drupal every day have never had a clear way to understand or pay for the maintenance they use. So the cost has been shouldered by those most engaged in the community and, increasingly, the DA’s cash reserves instead.

Changing that is my priority. Over the coming months I'll be focused on three things.

First, understanding the true cost of the work. I'm modernizing our financial reporting so we can see the full cost of every program and event, including the staff time each one requires, which our current reports don't fully communicate. That will give the board, the staff and the community real transparency into where money goes, which programs deliver the most value and where we’re choosing to invest.

Second, funding each kind of work in the way that fits it. Not every program should look the same. Our utility and infrastructure services can move toward a usage-based model for the enterprises that depend on them. Our ecosystem advocacy needs focused support, because it strengthens Drupal and the Makers who build it.  Our digital-public-good work, the parts that belong to everyone, can be sustained by philanthropy, contribution and as part of the utility and advocacy work. The aim is a regenerative model, where what these utility and advocacy services reinvest into all the ongoing costs that Drupal has as a thriving digital public good, a cycle that can sustain itself rather than a subsidy running down without constant new funding sources.

Third, collaborating with open source colleagues. These challenges aren't ours alone. I want to explore a co-creating shared standard for sustainable use certification with other open source projects facing the same challenges. Working together as a broad open source ecosystem, we can make supporting the open source software that organizations depend on an easy, standardized, normal and expected cost of doing business rather than ad hoc, voluntary and charitable, as it is now. 

This matters beyond our own budget. Stewarded open source is no longer just a code repository. It is critical digital infrastructure. To keep it healthy, all of open source needs reliable ongoing funding from operating budgets as a standard line item. That is how we turn an extractive pattern into a regenerative one, and how Drupal and the community stays strong, open and community-governed for everyone who builds on it. Funding our ongoing work properly is how we protect that.

Those are my thoughts. I’m looking forward to hearing yours. Over the next several weeks I’ll be inviting all parts of the Drupal ecosystem to share what you think, and I'll reflect back what I hear as we go. I intend to earn your trust through what we do over the next several months. Thank you for building this project, and for caring enough to hold the Association to a high standard.

One final note of transparency on my own situation: I own Palantir.net, a Drupal Certified Partner, and I take that conflict seriously. As of July 20, I have stepped back from day-to-day operations there. To prevent any interference and guarantee strictly arm’s-length dealings, we have built a robust and legally-vetted conflict-of-interest framework directly into my interim contract.

Inserting boilerplate text into CKEditor in Drupal Drupal Drupal 11.x Planet Drupal jstrecker 2026.07.21 @ 14:38

Don’t Repeat Yourself. It’s a rule that we learn for writing code. And guess what: it applies just as well to writing content. If you copy and paste the same thing in lots of places, it’s going to be a real hassle if you need to go back and change it later.

I’m building a Drupal website to share info about food pantries in my area. As I began entering data about pantries, I realized that I was copying and pasting text across nodes more than I wanted to.

• Read more about Inserting boilerplate text into CKEditor in Drupal
• Add new comment

Scott Falconer links his board candidacy to a question now facing Drupal: how the project can grow without allowing AI adoption, enterprise influence, or vendor dependence to weaken community control.

It feels like the right moment to share something I have been looking forward to announcing. The holidays are just beginning, and the Enterprise AI Summit (28 September, Rotterdam) is coming together.

We have been reviewing sessions over the past weeks, and three cases in particular stood out, each solving real problems for real organisations.

Here is a first look at three of the sessions we are excited to share.

THE EUROPEAN PERSONNEL SELECTION OFFICE: CANDIDATE SUPPORT IN 24 LANGUAGES

EPSO is the body responsible for selecting staff across EU institutions, and every year, thousands of candidates ask questions in all 24 official EU languages. With a small team, an enormous volume of work, and zero tolerance for wrong answers, EPSO needed a solution that could keep up.

Antonella Picarella will show us what that solution looks like: an AI-powered support tool on Drupal that now handles 93% of incoming questions automatically, across all 24 languages, with no hallucinations detected on manual checking.

Read more about this session: https://summit.enterprisedrupal.eu/epso.html

THE AMERICAN DIABETES ASSOCIATION: FROM PILOT TO PRODUCTION

When the content is about people's health, accuracy is not optional, and neither is speed.

Hemant Gupta will walk through how the American Diabetes Association moved AI from pilot to daily use across their Drupal platform: editorial assistance, bulk alt text generation, in-editor AI tools, and Word-to-Drupal content pipelines. Editorial teams are using it, the results are documented, and so is the process that got them there.

Read more about this session: https://summit.enterprisedrupal.eu/ada.html

WORLD CANCER DAY: MODERATION AT SCALE, WITH A HUMAN HEART

On World Cancer Day, hundreds of thousands of personal cancer stories are shared in a single day, reaching 500,000 requests per hour with just a small team behind it.

Charles Andrew Revkin and Diego Costa will share how the World Cancer Day team uses Drupal and AI to scale a deeply personal campaign without losing the human touch.

Read more about this session: https://summit.enterprisedrupal.eu/wcd.html

JOIN US ON 28 SEPTEMBER IN ROTTERDAM

The full schedule is taking shape. If you want to see what AI actually looks like when it is deployed, trusted, and working, this is where you will find it.

More information and tickets: https://summit.enterprisedrupal.eu

Migrating custom Drupal modules? Learn what breaks, how to audit the damage, and when to port vs. rebuild, with tools that automate the fix.

We take over projects from other agencies and see them through to completion – even if they are stuck, have errors, or require urgent intervention.

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, while others will move to Acquia Source. Drupal CMS played an important role in these decisions by making Drupal more approachable for marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation makes both harder by creating recurring duplication. Integrations, security practices, governance policies, design systems, and technical expertise must all be developed and maintained across multiple platforms.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save tens of millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

Drupal 7 has reached its end of life, and the jump to modern Drupal is in practice a rebuild, not an upgrade – new architecture, a contrib audit, a theme rewritten from scratch. There has always been a calmer answer, and it carries a name this community knows well: Backdrop CMS, the community continuation of the Drupal 7 lineage. What was missing was the road. BOA-5.88.8, the 'Continuity Edition', builds it: Backdrop as a first-class citizen on the Ægir control panel, and a supported upgrade which converts a copy of your Drupal 7 site while the original keeps serving, so you decide at leisure when to hand over the keys. Even Drupal 6 sites can travel D6 to D7 to Backdrop entirely through panel tasks. Here is how the whole road works, and why it never touches your original site.

Visual page builders often arrive with a familiar promise: fewer developer handoffs and more control for editors. Drupal CMS 2.0 makes that promise concrete by using Drupal Canvas as its default editing experience, with drag-and-drop composition, live previews, and editing directly on the page. The change does not remove front-end development. It moves the unit of work from the individual page towards reusable components and the rules surrounding them.

Single-Directory Components make those rules visible in code. Part of Drupal core’s render system since Drupal 10.3, a component can keep its Twig template, metadata, CSS, JavaScript, and related assets together. Props define structured inputs, slots create controlled areas for nested content, and schemas can restrict the values a component accepts. Drupal’s SDC quickstart describes these inputs as an application programming interface, or contract, for the component.

Consider a featured article card. Developers can encode its semantic markup, heading structure, image treatment, responsive behaviour, accessibility requirements, spacing, and permitted visual variants. Editors can choose the article, label, image, and approved presentation without adding arbitrary classes or rebuilding the markup. The editor gains useful control because the developer has already decided where flexibility is safe.

Recent Drupal publications make this division of labour clearer. In the 4 December 2025 blog post “Drupal Canvas 1.0 Released,” Drupal founder Dries Buytaert described reusable components that match a team’s design system. His 23 October 2025 State of Drupal recap presented visual page building for end users alongside component work for front-end developers, while Drupal.org’s 24 March 2026 post “Drupal at 25: Built to Last. Ready for What’s Next.” said Canvas can speed page creation without sacrificing structured content. The pattern is clear: visual tools redistribute development work rather than make technical expertise unnecessary.

Canvas also extends component development beyond traditional Twig-based theming. Its code components contain JavaScript and CSS, can receive page data and custom inputs, and can be created in the browser or maintained in a local codebase. They render through Preact with a React compatibility layer. For teams that need source control, shared files, static assets, or package dependencies, the local workflow supports development outside the Canvas interface and synchronisation with the Drupal site.

Greater component power creates a governance question. A schema can restrict the values a component accepts, but the development team must still decide which choices are meaningful, who owns the component, and how changes will affect pages already using it. Too many exposed options can weaken the design system, while too few can recreate the bottlenecks that visual building is meant to reduce. Reusable components should therefore be reviewed as public interfaces, with clear defaults, accessibility checks, documented variations, and predictable behaviour.

Existing custom themes do not need to adopt this model in one large rewrite. Teams can begin with repeated elements such as cards, teasers, calls to action, and heroes, then move their inputs into documented props and their flexible regions into deliberate slots. Components can be tested within the theme before mature and stable choices are exposed through Drupal Canvas. The future Drupal developer may assemble fewer pages directly, but will carry more responsibility for building the platform on which those pages can be assembled safely.

Readers can follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.

(Kazima Abbas, sub-editor at The DropTimes, writes and curates this week’s Editor’s Pick.)

Chris Kelly links the board candidacy to a question now facing Drupal: how the project can make installation and upgrades easier without weakening security, independence, or open-source safeguards.

Michael Kinnunen and Steve Wirt share how they each got started with Drupal through higher-ed jobs and stayed for the communit. They compare those community values to FIRST Robotics, explaining FIRST's K–12 programs (FRC, FTC, and FIRST LEGO League), kickoff-style challenges, and the "coopertition" culture where teams help competitors with parts and repairs. Both mentor highschool robotics teams in the US.

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

Topics

• Cafe Catch Up
• Drupal Origin Stories
• Why Drupal Community
• What Is FIRST
• Mentoring Journeys
• Team Names Numbers
• Kickoff Build Sprint
• Coopertition In Action
• Awards And Impact
• Drupal for Team Ops
• Trying Recipes and Canvas
• Time Investment and Module Fixes
• Getting Students into Drupal
• Mentor Load and Teaching Java
• Student Run Team Culture
• Robot Ecosystem and Everybot
• Team Roles and Onboarding
• Adversity and Grit Lessons
• FIRST Programs and How to Join
• Wrap Up and Good Luck

Steve Wirt

Drupal Developer for CivicActions by day, FIRST Robotics mentor by night Steve has been a Drupal Developer for 19 years and helps government agencies build tools that help improve their mission. He is founding mentor of FRC team Compass Robotics.

Michael Kinnunen

Backend Engineer for CivicActions Michael has been working with Drupal for about a decade, starting with Drupal 7 in 2016 as a Web Developer at Northern Michigan University. He has also spent the past six years as a mentor for the Negaunee Minerbotics FRC team, where he has helped students build technical skills in programming and engineering.

Guests

Steve Wirt - swirt

Michael Kinnunen - mkinnune

Resources

FIRST Robotics Gracious Professionalism and Coopertition Michael's team

• https://github.com/minerbotics
• https://www.facebook.com/MinerBotics4827/

Steve's team - Compass Robotics

Drupal is not named in the HTML First paper, but the argument lands close to home. It gives Drupal teams a useful test for deciding when server rendering, Twig, components, and JavaScript should each carry the frontend load.

Some thirty years ago we started working with Adgrafix, the American company which shipped the world's first web hosting control panel, written entirely in Perl. This is the story of everything since: our own Perl panel and web store in the nineties, the Perl-to-PHP crossing which taught us to never strand a customer, the years of testing every open source CMS on the planet, the Drupal adventure, the Ægir torch which Bryght left behind, our Barracuda & Octopus (BOA) stack, and the 8 in our name finally tipping over into ∞ this year, when Backdrop CMS joined the family. Written for the anniversary, and for everyone who keeps old sites alive.

LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites. The functionality provided includes content pages, news pages, bus timetables, and waste collection systems. What's more, it's maintained by a vibrant community of people.

The LocalGov Drupal Waste Collection module is a module that allows local bin collection schedules to be displayed to users. This uses a combination of an address lookup and collection data to show users the bins collection schedule for that address for the next few months.

A plugin interface is used to allow different banks of data to be used in the bank end of the module, with CSV and Whitespace API integration coming with the module. Whitespace is a company used across the UK to manage waste collection systems and the Whitespace plugin interfaces with a SOAP API to pull bin collection data into the site.

I've been using the Waste Collection module for a little while now with a few different projects. Whilst the information that the module provides is good, I needed to alter this data in a recent project with Central Bedfordshire. This required the use of a hook to alter the Whitespace plugin class and output more customised waste collection schedules.

In this article I will go through the issue I needed to correct, and how I altered the data coming out of the Whitespace API without creating a new plugin.

The Problem

When you set up Whitespace integration using this module it pulls a set of service names, which is essentially a list of the types of collections that can happen. This will be things like "Refuse (black bin)" or "Recycling" and shows residents what sort of bin they need to put out for collection on that day.

Read more

Canvas Tips&Tricks: Declaring images in SDCs

I've read recently about making SDCs dependent on Drupal Canvas because of needing to reference Canvas in the definition of your prop, so the right media widget is used inside Canvas:

image: $ref: json-schema-definitions://canvas.module/image type: object title: Image description: > Image of the singer examples: - src: 'micro.webp' alt: 'Nice picture of the singer' width: 200 height: 300

That was the case during the alphas. But was fixed long ago, even before the 1.0.0 release. See canvas#3515074.

image: type: object title: Image required: [src] properties: src: type: string format: uri-reference contentMediaType: "image/*" x-allowed-schemes: [http, https] # this is image-uri, itself a nested $ref alt: { type: string } width: { type: integer } height: { type: integer } description: > Image of the singer examples: - src: 'micro.webp' alt: 'Nice picture of the singer' width: 200 height: 300

That's more verbose, but would make your SDC Canvas-independent and re-usable, and it's 100% equivalent. 

If we missed updating some docs, please create an issue on the Canvas issue queue.

penyaskito Sat, 07/18/2026 - 17:43 Tags

• Drupal
• Drupal Canvas
• Drupal Canvas Tips&Tricks
• Single-Directory Components
• Drupal planet

• Read more about Canvas Tips&Tricks: Declaring images in SDCs
• Add new comment