The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source Drupal CMS and enterprise platform. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who’ve submitted responses.
Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association to promote global reach and protect the confidentiality of the information. Moving forward, the Drupal Association will handle the analysis and reporting of the anonymised data from the survey. We're grateful to Janne, Michel, and Imre for their many years of work in shaping and running the survey.
Drupal’s open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal’s market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies.
The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.
The Drupal Business Survey supports Drupal businesses worldwide and is organised by the Drupal Association. The survey was founded by Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (Craftmore), and we're grateful for their years of work in building it into what it is today.
Drupal is the open source Digital Experience Platform used by many organisations worldwide including Nestlé, Lufthansa and World Wildlife Fund (WWF).
Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.
You can take the Drupal Business Survey 2026 anonymously here. The survey closes on 7 September.
The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source Drupal CMS and enterprise platform. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who’ve submitted responses.
Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association to promote global reach and protect the confidentiality of the information. Moving forward, the Drupal Association will handle the analysis and reporting of the anonymised data from the survey. We're grateful to Janne, Michel, and Imre for their many years of work in shaping and running the survey.
Drupal’s open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal’s market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies.
The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.
The Drupal Business Survey supports Drupal businesses worldwide and is organised by the Drupal Association. The survey was founded by Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (Craftmore), and we're grateful for their years of work in building it into what it is today.
Drupal is the open source Digital Experience Platform used by many organisations worldwide including Nestlé, Lufthansa and World Wildlife Fund (WWF).
Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.
You can take the Drupal Business Survey 2026 anonymously here. The survey closes on 7 September.
DDEV v1.25.4 is here: 142 PRs from the entire DDEV community. Your suggestions, bug reports, code, and financial support made it possible.
The theme of this release is doing less by hand. A new project can start with a "seed" database you already have, and image and environment customizations can be set globally instead of in every project.
:::note[Linux and WSL2: new package repositories]
DDEV's apt and rpm packages are now published to Cloudsmith at packages.ddev.com. Gemfury (pkg.ddev.com) keeps working, so switch over whenever it suits you by re-running the Linux installation steps.
Package repository hosting is graciously provided by Cloudsmith. :::
Until now, a fresh project always started with an empty database, and getting your data back in there meant importing a dump or snapshot every time. DDEV can now automatically use a snapshot, which is far quicker than importing a SQL file.
ddev start --seed-snapshot=<name-or-path> fills a brand-new database from a snapshot in .ddev/db_snapshots, or from a path to one anywhere else on your machine. It works with MariaDB, MySQL, and PostgreSQL.seed is a reserved snapshot name. Run ddev snapshot --name=seed once, and from then on any ddev delete followed by ddev start brings that database back, with no flag to remember. You can even check .ddev/db_snapshots/seed* into Git if it's not annoyingly large.ddev start --reset-database throws the current database away and starts over, taking a snapshot first. The flags can be combined (works with both ddev start and ddev restart): ddev start --reset-database --seed-snapshot=large-dataset --omit-snapshot.There's more to snapshots in this release: sizes and database versions in ddev snapshot --list, snapshots shared across Git worktrees, and uncompressed snapshots for faster restores. See Snapshots for all of it.
DDEV now supports MySQL 9.7, the latest LTS release:
# New project
ddev config --database=mysql:9.7
# Existing project
ddev utility migrate-database mysql:9.7
MySQL 8.0 and 8.4 also switched base images, from bitnamilegacy/mysql, which no longer receives updates, to Docker Hardened Images (dhi.io/mysql).
If you've ever added the same company CA certificate, apt package, or API token to every project you work on, this release is for you.
Global Dockerfiles in ~/.ddev/web-build/ and ~/.ddev/db-build/ apply the same image customization everywhere: system tools, extra packages, or container-level SSL trust for curl, Composer, and Node.js, which used to be a per-project chore. A project overrides any of it with the same filename in its own .ddev/web-build/. Thanks to @rmott-littler.
Global env files ~/.ddev/.env and ~/.ddev/.env.<service> set environment variables for every project. Before this, the only global option was web_environment in ~/.ddev/global_config.yaml, which reaches the web container and nothing else. Now you can do it for db, or any other service:
# Set API_URL for the web service of every project
ddev dotenv global set .ddev/.env.web --api-url=https://example.com
Project env files gained two pieces in their names, too. A trailing .local, as in .ddev/.env.local, tells DDEV to gitignore the file, which is where credentials belong. A label, as in .ddev/.env.web.myaddon, keeps files from different sources apart, so an add-on isn't editing the same file you are.
Two project types joined DDEV:
Shopware 6 projects now get shopware-cli right in the web image, along with ddev admin-watch, ddev storefront-watch, and the ports they need. The ddev-shopware-cli add-on isn't needed anymore. Thanks to @vanWittlaer.
ddev add-on update updates the installed add-ons that are behind their latest GitHub release, with --dry-run to preview.ddev utility download-ddev fetches the ddev binaries for a PR, branch, commit, or tag without touching your installed DDEV, which is handy for testing a fix before it ships.ddev utility delete-volume removes one of a project's Docker volumes, for add-ons like ddev-solr that create their own.ddev launch --print-url prints the URL instead of opening a browser, for SSH, containers, and CI, thanks to @steffenmaechtel.ddev tablepro opens the project database in TablePro on macOS, thanks to @datlechin.A wrong docroot used to produce a bare 404/403 page with no hints about why. Now ddev-webserver explains the 403s and 404s it generates itself, and ddev-router does the same for a hostname that doesn't match any project:
The page says where it came from, so you know it isn't your application's own 404, and it lists what to check. A 403 or 404 from your own application is passed through untouched.
It also replaces the old "docroot may be wrong" warning on ddev start, which you never saw in a browser and which sometimes fired when nothing was wrong.
DDEV v1.25.3 introduced a few problems, and the ones you're most likely to have run into are resolved here:
/var/log can do that again, after the directory was locked down to root only./robots.txt works again. An Nginx rule was answering before your site could, and it's gone.ddev wp respects the path in your project's own wp-cli.yml again, falling back to the docroot only when that file doesn't set one. Since v1.24.5 it always added --path=$DDEV_DOCROOT, which broke Bedrock and any layout where WordPress isn't in the docroot.ddev in a subdirectory with its own .ddev/config.yaml, such as a Drupal contrib module or a Git submodule, keeps using the outer project and tells you which one it picked, instead of switching silently and breaking the outer project's custom commands. ddev start there asks first.A nightly benchmark harness now times ddev start, ddev stop, Mutagen sync-settle, and a Drupal install across the platforms and Docker providers DDEV already tests on, and publishes the results to a performance history dashboard, so a regression shows up as a bend in a trend line instead of a bug report months later. A second dashboard tracks CI test runtime.
This release includes many more features and bugfixes. See the full release notes for the complete list.
From the entire team, thanks for using, promoting, contributing, and supporting DDEV!
If you have questions, reach out in any of the support channels.
If you're amazed by how much is in this release, we are too! If you wonder how all this could be done, it's because of generous sponsors who let two of us work on this every day. If you and your team aren't already financially supporting DDEV, consider joining our sponsors.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read moreEmpty alt attributes are an accessibility and SEO killer, and the cost is measurable. Google Lighthouse flags the error on both of its audits: up to 6 points subtracted from the Accessibility score and 8 points from the SEO score.
The impact on real users is worse than the score. A screen reader completely ignores an image with no alt text, so blind users never know the image was there, which makes the experience disruptive and confusing. It also violates WCAG Success Criterion 1.1.1: Non-text Content, the baseline requirement for accessible non-text content.
That is why we had to act when a migration project resulted in thousands of images without an alt attribute.
A Drupal 9 to Drupal 11 migration for a multilingual sports news project surfaced around 12,000 images with missing or incorrect alt attributes, found via Screaming Frog tool. Some images had no alt attribute at all, while others had alt text in the wrong language, with English alt text appearing on the /es version of the site.
The obvious next step was to look for a pattern. Was the issue tied to a specific content type, such as Articles? Was the wrong-language text caused by untranslated Media content? Answering these questions turned out to be surprisingly hard: Drupal provides no default mechanism, no view…
read moreIcons seem like a small implementation detail until a site has a large design system, multiple authoring workflows, and content that changes independently of the theme.
Then a basic question becomes important: who owns the icon?
For some parts of an interface, the answer is clearly the theme. Alert states, event metadata, and other stable UI patterns should remain predictable.
Other icons behave more like content. Authors may need to choose an icon for a navigation item, card, banner, or other component. In those cases, hardcoding the choice in the theme creates a dependency between content and code that becomes difficult to maintain.
The goal is not to move every icon into Drupal. It is to give the right people control over the right decisions.
I generally think about icons in two groups: icons whose meaning belongs to a fixed interface pattern, and icons whose meaning belongs to authored content.
An alert is a good example of the first group. Drupal or an author might determine that an alert has a warning status, but the theme should decide which icon represents “warning.”
Event metadata works the same way. Date, time, and location have stable meanings within an event teaser. Those icons belong to the component, not to an individual event.
Hardcoding those relationships protects consistency.
A site menu is different. Authors add, remove, rename, and reorder menu items. If an icon describes the purpose of a particular link, it should usually travel with that link rather than with its position in a template.
Component-based authoring introduces the same issue. An author might select an icon for a card or a decorative treatment for a banner. If that component moves or is reused, the visual choice should move with the content.
Most interfaces contain both models at once. A card might have an author-selected icon and a hardcoded arrow that communicates that the card is a link. A menu item might have an author-selected icon on the left and a fixed chevron on the right when it has children.The useful boundary is not Drupal versus the theme. It is which part of the system owns each decision.
Menus make the problem especially visible.
A developer can attach an icon to the second menu item with CSS, but that relationship breaks as soon as an author inserts another link above it. Targeting a specific menu item identifier is more stable, but it still creates a developer-maintained connection between content and theme code.
A select list is another common approach:
For a small icon set, this can be perfectly reasonable.
The problem appears as the library grows. Authors are asked to understand the design system through filenames. The distinction between calendar, calendar-outline, and calendar-filled may be obvious to the developer who added them and much less obvious to someone building a page later.
Adding a new option may also require a theme change and deployment.
From the author's perspective, this is a content problem. From the developer's perspective, it is a theme problem.
Drupal already has a better interaction model for choosing visual assets.
When authors choose an image, we do not normally give them a dropdown containing every filename on the site. Drupal's Media Library gives them visual previews, search, filtering, reuse, and asset management.
That interaction makes sense for icons too.
With SVG Image, SVG files can participate in Drupal's image field ecosystem and can be rendered as image elements or inline SVG markup.
Once icons become Media entities, they can also use Drupal's normal content model. They can have useful names, categories, permissions, and usage guidance. Views and reference configuration can limit which assets authors see in a particular context.
That matters because an icon library is rarely one undifferentiated collection.
Graphical UI icons used in menus or calls to action likely aren’t used in the same way more decorative accents are. The overhead of deciding which icon type should be used in which context shouldn’t be left to the author if we can provide clear guardrails.
This is where Media becomes more than a nicer picker. It provides a governance model.
Menus can gain Media reference fields through tools such as Menu Item Extras. Component systems based on Paragraphs can attach icon choices directly to the structured component. Style Options - Media Reference provides another way to expose Media selections in component configuration.
The exact implementation will vary by project. The important part is that once an icon becomes an entity, Drupal's existing fields, permissions, and filtering tools can manage it without requiring a custom icon picker.
Moving icons into Media improves the author experience, but the theme still needs a reliable rendering model.
The rule I use is simple:
HTML chooses the icon. CSS styles it.
Drupal or Twig should determine whether an icon exists and which icon it is. CSS should handle size, spacing, alignment, color, and interaction states.
That separation works particularly well with inline SVG. The SVG can inherit color from the component, respond to interaction states, and remain part of the markup rather than being hidden inside a stylesheet.
It also keeps accessibility decisions closer to the rendered interface. Decorative icons can be hidden from assistive technology, while meaningful controls can rely on appropriate accessible names rather than asking the icon itself to carry all of the meaning.
I previously built a small Twig helper in the Utility Belt module to make theme SVG rendering easier. It solved a practical problem, but Drupal's newer Icon API offers a more standardized direction.
Drupal 11.1 introduced an Icon API that allows themes and modules to expose icon packs through a common rendering system. Contributed projects such as Icon Media Pack are exploring how Media bundles can participate in that model.
That creates an interesting division of responsibility: Media can handle author-facing governance, while the Icon API can provide developers with a predictable rendering path.
There are still exceptions.
Native form controls sometimes need icons as CSS backgrounds or masks because their markup cannot easily contain rendered SVG children. In those cases, keeping a small set of duplicate assets in the theme can be a reasonable tradeoff.
The point is not to eliminate every exception. It is to make the boundary intentional.
An author-friendly icon system is not one where authors can change every icon.
It is one where authored decisions are actually authorable.
If an icon belongs to a stable interface pattern, keep that relationship in the theme. If the icon represents something an author is creating or organizing, consider modeling that choice in Drupal.
Media can provide the visual browsing and governance authors need. The theme can continue to protect rendering and presentation.
That division is more maintainable than treating icons as entirely theme code or entirely content, and it better reflects how complex Drupal sites actually operate.
In the previous post in this series, I described how we rebuilt our ctools page elements as block plugins.
That gave us the new implementations, but not the pages that had already been assembled in Drupal 7. Recreating them manually would have taken a long time and risked losing existing configuration along the way.
We did not want to migrate complete Panels displays. The rebuilt site had its own Layout Builder sections and layouts. We wanted to preserve the page elements, their order and as much of their configuration as the new block plugins could still use.
Publishing one good page is a writing task. Keeping hundreds of pages accurate across products, markets and languages is a systems problem.
Drupal content operations at scale means treating each fact as structured data with relationships, permissions and history, then reusing it across templates, languages, JSON-LD and APIs. Here is how fields, taxonomy, Views and workflows keep large Drupal sites governable when AI-assisted research raises the bar.
read moreThis post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
To the Drupal community,
As northern hemisphere summer winds down, DrupalCon Rotterdam is rapidly approaching — and if you haven't booked yet, today is your last chance at Regular pricing. Late Rate kicks in at midnight CEST, so this is my friendly nudge to save yourself €270 and register now.
Rotterdam isn't the only Con on the horizon. DrupalCon Orlando Early Bird registration opens 14 September, and paid Early Bird tickets come with a limited-edition DrupalCon elePHPant — once they're gone, they're gone.
Elsewhere in this edition: the 2026 Drupal Business Survey is open until 7 September (your answers shape where we focus next), the engineering teamhas completed the migration of Drupal's security issue tracking to GitLab, and we're delighted to welcome Janna Malikova to the Drupal Association Board.
As always, thanks for being part of it. See you in Rotterdam!
Ryan Witcombe, Director, Product Marketing
Your input shapes an anonymized report that helps the whole community. You'll see how your pipelines, win rates, and revenues compare to global peer data, share what's actually working, and directly influence where the Drupal Association focuses next.
Take the survey by 7 September 2026 at 23:59 UTC. Responses are strictly confidential and fully anonymized. Everyone who completes the survey receives the full report by email.
Join Drupal experts and community members to discover what’s next for Drupal and the open web, exchange ideas, and build connections across the ecosystem in Rotterdam from 28 September to 1 October.
The regular rate is now closed, but registration for DrupalCon Rotterdam 2026 is still open. Register here.
The Early Bird registration for DrupalCon Orlando 2027 opens Monday, 14 September 2026 at 8:00 am EST, with tickets available for $650. And Early Bird comes with a special perk. Paid Early Bird DrupalCon tickets include a limited-edition DrupalCon PHP elePHPant named Drupy (Elephpas hypertextus drupalensis primus in Latin), available exclusively during the Early Bird registration period.
Free tickets do not include an elePHPant, but you'll have the option to purchase one during registration while supplies are available.
Kick off DrupalCon Orlando on Monday, 22 March 2027 with a full day of deeper learning and industry-specific discussions, all available as add-ons to your registration.
Choose from six summits tailored to your interests: AI · Government · Higher Education · Nonprofit · Healthcare · Community.
Two summits with special pricing: the Community Summit is free for all DrupalCon registrants, and the Nonprofit Summit is free for Nonprofit ticket holders.
One focused training on offer: AI Inside Drupal: From Smart Editorial Workflows to Canvas Agents That Build Pages, presented by DrupalEasy.
Save the Tuesday night, 23 March 2027, for the DrupalCon Community Party, featuring something brand new for Orlando: the first-ever DrupalCon Talent Show!
It's FREE, and opting in helps us plan for everyone who wants to join us Tuesday night.
More details are coming soon.
There's still time to help shape the DrupalCon Orlando 2027 program! We're accepting speaker submissions through 20 October 2026.
Submit your DrupalCon Orlando session.
Bytes the Gator is making his way around the Drupal community and you can join the fun for a chance to win a free registration to DrupalCon Orlando 2027. Can't attend a Drupal event or find Bytes? Another alligator works too, preferably not a live one!
Meet Bytes and learn how to enter the mascot contest.
This month the team completed the migration of Drupal's security issue tracking to git.drupalcode.org, making the volunteer Security Team faster and easier to grow.
The broader issue migration now covers 90,000+ issues across 7,200+ projects. Release packages were re-signed for 3,200+ projects through Rugged, our new package signing pipeline.
localize.drupal.org and jobs.drupal.org have moved to modern cloud infrastructure, and the Drupal 11 upgrade of the new Drupal.org platform is underway.
Next up: porting community events to new.drupal.org so we can retire groups.drupal.org.
We are excited to announce the winner of 2026 Community At-Large Board Elections. We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat.
We are grateful to Alejandro Moreno for their service and dedication to Drupal and the community, and to all the candidates who applied this year. Read the full announcement here.
This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
To the Drupal community,
As northern hemisphere summer winds down, DrupalCon Rotterdam is rapidly approaching — and if you haven't booked yet, today is your last chance at Regular pricing. Late Rate kicks in at midnight CEST, so this is my friendly nudge to save yourself €270 and register now.
Rotterdam isn't the only Con on the horizon. DrupalCon Orlando Early Bird registration opens 14 September, and paid Early Bird tickets come with a limited-edition DrupalCon elePHPant — once they're gone, they're gone.
Elsewhere in this edition: the 2026 Drupal Business Survey is open until 7 September (your answers shape where we focus next), the engineering teamhas completed the migration of Drupal's security issue tracking to GitLab, and we're delighted to welcome Janna Malikova to the Drupal Association Board.
As always, thanks for being part of it. See you in Rotterdam!
Ryan Witcombe, Director, Product Marketing
Your input shapes an anonymized report that helps the whole community. You'll see how your pipelines, win rates, and revenues compare to global peer data, share what's actually working, and directly influence where the Drupal Association focuses next.
Take the survey by 7 September 2026 at 23:59 UTC. Responses are strictly confidential and fully anonymized. Everyone who completes the survey receives the full report by email.
Join Drupal experts and community members to discover what’s next for Drupal and the open web, exchange ideas, and build connections across the ecosystem in Rotterdam from 28 September to 1 October.
The regular rate is now closed, but registration for DrupalCon Rotterdam 2026 is still open. Register here.
The Early Bird registration for DrupalCon Orlando 2027 opens Monday, 14 September 2026 at 8:00 am EST, with tickets available for $650. And Early Bird comes with a special perk. Paid Early Bird DrupalCon tickets include a limited-edition DrupalCon PHP elePHPant named Drupy (Elephpas hypertextus drupalensis primus in Latin), available exclusively during the Early Bird registration period.
Free tickets do not include an elePHPant, but you'll have the option to purchase one during registration while supplies are available.
Kick off DrupalCon Orlando on Monday, 22 March 2027 with a full day of deeper learning and industry-specific discussions, all available as add-ons to your registration.
Choose from six summits tailored to your interests: AI · Government · Higher Education · Nonprofit · Healthcare · Community.
Two summits with special pricing: the Community Summit is free for all DrupalCon registrants, and the Nonprofit Summit is free for Nonprofit ticket holders.
One focused training on offer: AI Inside Drupal: From Smart Editorial Workflows to Canvas Agents That Build Pages, presented by DrupalEasy.
Save the Tuesday night, 23 March 2027, for the DrupalCon Community Party, featuring something brand new for Orlando: the first-ever DrupalCon Talent Show!
It's FREE, and opting in helps us plan for everyone who wants to join us Tuesday night.
More details are coming soon.
There's still time to help shape the DrupalCon Orlando 2027 program! We're accepting speaker submissions through 20 October 2026.
Submit your DrupalCon Orlando session.
Bytes the Gator is making his way around the Drupal community and you can join the fun for a chance to win a free registration to DrupalCon Orlando 2027. Can't attend a Drupal event or find Bytes? Another alligator works too, preferably not a live one!
Meet Bytes and learn how to enter the mascot contest.
This month the team completed the migration of Drupal's security issue tracking to git.drupalcode.org, making the volunteer Security Team faster and easier to grow.
The broader issue migration now covers 90,000+ issues across 7,200+ projects. Release packages were re-signed for 3,200+ projects through Rugged, our new package signing pipeline.
localize.drupal.org and jobs.drupal.org have moved to modern cloud infrastructure, and the Drupal 11 upgrade of the new Drupal.org platform is underway.
Next up: porting community events to new.drupal.org so we can retire groups.drupal.org.
We are excited to announce the winner of 2026 Community At-Large Board Elections. We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat.
We are grateful to Alejandro Moreno for their service and dedication to Drupal and the community, and to all the candidates who applied this year. Read the full announcement here.
This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.
I've been maintaining the matrix_api module on Drupal.org since 2016, nearly a decade of it doing one thing well: posting Drupal events into a Matrix room. This year that changed.
AI assistants increasingly sit between people and websites, retrieving and interpreting information on their behalf. That shifts the problem beyond whether software can connect to a site at all. The system also has to make clear what information means, what software may access, and which rules govern what happens next.
The Drupal AI Initiative made the first part of that problem explicit on 24 August 2026. Fields, taxonomy, relationships, metadata, and other forms of structured content can give software information that is easier to identify and interpret than meaning conveyed mainly through page design. Permissions and workflows add another layer by distinguishing what is public, restricted, current, or subject to editorial control.
A more concrete access boundary appeared this week in Acquia DAM's MCP Server. Compatible AI assistants can search assets, retrieve metadata, and obtain links through an authenticated connection that follows the user's existing DAM permissions. The initial implementation is read-only: an assistant can retrieve permitted information but cannot edit metadata or upload files. The interface therefore exposes capability without giving the software unrestricted authority over the system behind it.
GovCMS addresses a different machine-readable problem. On 27 August 2026, Rules as Code became a production capability on the platform, allowing policy, legislation, and business rules to be represented as reusable digital assets and embedded in digital services. Its first production implementation is an eligibility checker for agencies considering GovCMS, and the underlying eligibility rules are also published as open source. GovCMS describes the approach as a foundation for future AI-assisted services rather than as an AI-agent implementation today.
These developments are not three versions of the same architecture. They expose three related requirements for systems that software increasingly has to interpret or use: meaning must be explicit, access must be constrained, and important rules should not have to be guessed from prose. For Drupal teams, the agentic web may therefore depend as much on long-standing work around content modelling, permissions, auditability, and governance as it does on new AI capabilities.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
This issue of Editor’s Pick was written and curated by Allen Jason.
read moreThe Drupal Association is excited to announce the winner of 2026 Community At-Large Board Elections.
We extend a sincere thank you to Alejandro Moreno for his service and dedication, not only to Drupal, but to the Drupal community. Your time spent on the board made such a difference to the future of the Drupal project, and we thank you all for participating with grace, thoughtfulness, and insightful contributions.
We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat during our 2026 At-Large Board Elections.
We cannot wait to see all the amazing things Janna will accomplish while on the Drupal Association Board.
There were 8 candidates in this year’s At-Large board member election. 307 voters cast their ballots out of a pool of 1274 eligible voters. Eligible voters are active Drupal Association members, known as Ripple Makers, whose membership must have been active at least 24 hours before voting opened.
Under Approval Voting, each eligible voter can give a vote to one or more candidates.
The final total of votes were as follows:
|
Candidate |
Votes |
|
Scott Falconer |
74 |
|
James Abrahams |
131 |
|
Bert Boerland |
120 |
|
Chris Kelly |
26 |
|
Darren Oh |
57 |
|
Janna Malikova |
141 |
|
Helge Notø |
74 |
|
Matthew Saunders |
128 |
On behalf of all the staff and board of the Drupal Association, a heartfelt Drupal Thanks to all of you who stood for the elections this year. It truly is a big commitment to contribution, the Drupal Association, and the community, and we are so grateful for all of your voices. Thank you for your willingness to serve, and we hope you’ll consider participating again in 2027!
The Drupal Association is excited to announce the winner of 2026 Community At-Large Board Elections.
We extend a sincere thank you to Alejandro Moreno for his service and dedication, not only to Drupal, but to the Drupal community. Your time spent on the board made such a difference to the future of the Drupal project, and we thank you all for participating with grace, thoughtfulness, and insightful contributions.
We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat during our 2026 At-Large Board Elections.
We cannot wait to see all the amazing things Janna will accomplish while on the Drupal Association Board.
There were 8 candidates in this year’s At-Large board member election. 307 voters cast their ballots out of a pool of 1274 eligible voters. Eligible voters are active Drupal Association members, known as Ripple Makers, whose membership must have been active at least 24 hours before voting opened.
Under Approval Voting, each eligible voter can give a vote to one or more candidates.
The final total of votes were as follows:
|
Candidate |
Votes |
|
Scott Falconer |
74 |
|
James Abrahams |
131 |
|
Bert Boerland |
120 |
|
Chris Kelly |
26 |
|
Darren Oh |
57 |
|
Janna Malikova |
141 |
|
Helge Notø |
74 |
|
Matthew Saunders |
128 |
On behalf of all the staff and board of the Drupal Association, a heartfelt Drupal Thanks to all of you who stood for the elections this year. It truly is a big commitment to contribution, the Drupal Association, and the community, and we are so grateful for all of your voices. Thank you for your willingness to serve, and we hope you’ll consider participating again in 2027!
This is the second article in a series looking at migrating from Jadu into a LocalGov Drupal (LGD) site for the Central Bedfordshire site. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.
In the second article we looked at reproducing Jadu URLs to create redirects for migrated content, even though the Jadu API doesn't contain any URL information.
Now that we have a the Jadu connection created and redirects working we can start tackling other aspects of the migration, so let's look at migrating the main content of the site from Jadu. We can pull structured pages of content out of the Jadu API and apply them to the structure of a LGD site, maintaining the same hierarchical structure and order of pages.
Much of the content of a LGD site is built using just a handful of content types, and Central Bedfordshire was built in the same way. LGD comes with a number of content types that allow content editors to add content in different ways, which allows for some decent customisation in the structure and layout of a site. Not only that, but as we are using Drupal it is possible to customise this structure as much as we need to suit the needs of the site.
For Central Bedfordshire, we had the standard structure of the site built with Service Landing pages, which gave editors the ability to link out to other pages that contained all of the content. These inner pages were set up as Guide pages, and the migration of that content is what we will be focusing on in this article. Please note that I will need to gloss over a little bit of the detail in this article, but rest assured that the source code will be available soon.
philipnorton42 read moreToday we are talking about Security, Vulnerabilities, and how to avoid exposure with guest Dave Welch. We'll also cover Security Scanner as our module of the week.
For show notes visit: https://www.talkingDrupal.com/567
TopicsDavid Welch - github: dwelch2344 dwelch2344
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi JD Flynn - dorficus
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Open Source is usually described as a licensing model, a development model, or a production model. All three descriptions are useful, but they leave something out. Every Open Source ecosystem is also a cost-allocation system.
Keeping software relevant and dependable requires people to write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations. Someone always bears those costs.
A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases.
Open Source breaks the link between access and payment. Anyone can redistribute the software at any price, including zero. Payment is therefore not a condition of using or redistributing it, and those rights do not themselves provide a durable mechanism for funding production and maintenance.
But separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users. A maintainer may volunteer their time. An employer may pay a developer to contribute. A foundation may operate infrastructure.
Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund.
Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later.
Drupal's update service recently gave me a good example. Drupal sites periodically contact updates.drupal.org to ask whether new versions of Drupal or any installed add-ons are available. Drupal calls these add-ons "contributed projects", such as modules and themes maintained by members of the community.
The current design sends one request for Drupal itself and one for every contributed project installed on the site. A site with 100 contributed projects therefore makes 101 requests each time it checks for updates, by default, once a day.
There were good reasons for that design. Each project's release history could be stored as a static file and served repeatedly without rebuilding it for every request. The design was straightforward, and it worked.
But Drupal grew. Today, updates.drupal.org serves nearly a billion requests a month. The file containing Drupal Core's release history is roughly half a megabyte by itself. Based on the number of requests for that file, I estimate that Drupal Core update checks alone may account for roughly 50 to 75 TB of data transfer each month. Traffic for contributed projects comes on top of that.
No one chose to make updates.drupal.org transfer tens of terabytes of release data each month. That scale emerged gradually as Drupal grew, from a design that had been reasonable when the ecosystem was smaller.
Part of the challenge is that, in Open Source, the people who benefit, the people who decide, and the people who bear the costs are often different and may have no formal obligations to one another.
Site owners benefit from reliable update notifications, usually without paying the Drupal Association for them. Drupal Association staff operate the update service, while the Association bears its traffic and infrastructure costs. But the code that determines how sites make those requests lives in Drupal Core, where changes require the involvement of Core committers. The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own.
In practice, Drupal Association staff and Core committers collaborate closely. That collaboration is important because decision-making authority and cost-bearing sit with different groups.
The people bearing material costs need a way to make those costs visible and influence the decision, even if they do not control it.
This example shows why every Open Source architecture is also a cost-allocation system. Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable.
Understanding an Open Source system therefore requires more than understanding its code or license. We also need to understand who benefits, who decides, and who bears the costs as the system grows. Once those relationships are visible, a community can decide whether the allocation is sustainable or whether the architecture should change.
read moreThis article introduces six new ECA Guide library recipes that improve the Drupal content editing experience through small, focused changes. They can draft metadata on first save, add access-aware edit links to teasers, prevent invalid dependent select values, offer field-level actions, fill several form fields without saving, and show contextual guidance beside a form. The point is not to apply all six recipes unchanged. They are well-architected starting points for a real editorial irritation. For editors, that means less repeated work and fewer avoidable mistakes. For organisations, it means more consistent content and a practical route to improving the CMS without turning every detail into a custom development project. The article also gives a simple choice: Field Widget Actions for one field, Form API Ajax for several form fields, and HTMX endpoints for nearby content. Production concerns still matter, especially permissions, validation, managed data, and AI review.
In the previous post, I described why we chose Layout Builder and how Layout Builder IPE restored the frontend editing workflow we had used with Panels IPE.
With the editing workflow in place, we still had to rebuild the elements that editors placed on their pages.
The Drupal 7 site used custom ctools content type plugins for maps, charts, figures, lists and tables. Editors placed and configured these plugins, while the plugins retrieved the information and rendered the result. I will call both these ctools plugins and the block plugins that replaced them page elements.
If you use DDEV, a simple way to mention the project is to star the GitHub repository. Head over to github.com/ddev/ddev↗ and click Star. It takes five seconds, and it can help us — a star count is one of the things new users, sponsors, and and AI check before trusting an open source tool. If you're already a star, thank you!
The DDEV Integration plugin for IntelliJ/PhpStorm↗, maintained by @AkibaAT, has been transferred into the ddev GitHub organization. This was on our 2026 plans list, and it's great to see it land. Awesome maintainer AkibaAT has kept the plugin in excellent shape, and this move gives it a permanent home alongside the rest of the DDEV ecosystem.
generic project type, with a custom web image and Azure SQL Edge.Knecht.works Ships Sandbox Rollback — Following up on last month's beta-tester call, the team at knecht.works has added sandbox rollback to their agency dashboard, letting each automated DDEV run boot into its own disposable environment. Read the update↗
TYPO3 Snapshot: Pull and Anonymize Production Data Locally — Ramon Herrmann released Snapshot, an open-source TYPO3 extension that pulls databases and fileadmin from live/staging into a local DDEV environment, with built-in anonymization for GDPR compliance. Read the announcement↗
Quick DDEV Previews: A Self-Hosted Preview Service — Matthias Andrasch built a proof-of-concept service that spins up DDEV preview environments from any branch of a connected GitHub repository, based on Samuel Reichör's technical work. Screencast: Using it on Hetzner VPS↗ • View the repo↗
ddev db-import and ddev db-export, a pair of global DDEV commands for restoring and exporting Drupal databases with drush cache-clear and login-link steps built-in, plus a follow-up set (db-prod-import, ssh-prod, and their preprod equivalents) for pulling a remote database in one step, packaged as the ddev-drupal-tools↗ add-on. Read the first post↗ • Read the follow-up↗ddev checks and ddev checks-fixes commands mirror the Drupal.org GitLab CI template, so code that passes locally passes in CI. Read on kalamuna.com↗Live training is back for the fall, three sessions open to everybody.
September 23, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST — Managing Huge Databases with DDEV, with Moshe Weitzman
Covers the new embedded snapshot and uncompressed snapshot features shipping in the upcoming v1.25.4 DDEV release.
Add to Google Calendar •
Download .ics
October 21, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST — Shopware with DDEV, with Benny Poensgen
A look at running Shopware on DDEV, from Benny's earlier post on the blog.
Add to Google Calendar •
Download .ics
November 11, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CET — Advanced Coder.ddev.com Techniques
Using the coder CLI, local and web-based VS Code, and remote-controlling Claude, including the freeform template.
Add to Google Calendar •
Download .ics
Zoom Join Info:
Link: Join Zoom Meeting
Passcode: 12345
DrupalCamp Tokyo 2026 — ANNAI presented on AI-driven Drupal development and sustainable open-source CMS strategy, including using DDEV with git worktree to run parallel Drupal environments. Read the report↗ (Japanese) — for English coverage of git worktree with DDEV, see Contributor Training: git worktree for Multiple DDEV Projects and Using git worktree with TYPO3.
A steady month — thank you to everyone who contributes!
July 2026: ~$9,931/month (82.8% of goal)
August 2026: ~$10,038/month (83.7% of goal)
If DDEV has helped your team, consider sponsoring. → Become a sponsor↗
Contact us to discuss sponsorship options that work for your organization.
Compiled and edited with assistance from Claude Code.
read moreFor most of the web’s history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.
AI is changing that... dramatically and rapidly!
People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation.
In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.
Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:
Can AI systems understand our organisation, trust our information and interact with our services safely?
To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.
A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website’s audience.
While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.
Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it’s represented clearly in the underlying content structure.
The content management decisions you make today will shape how accurately they are represented by AI tomorrow.
Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.
An AI system also needs to understand:
Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.
Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.
Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.
For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.
You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.
AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?
Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.
The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.
This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it
Put simply, AI makes content governance essential to digital communication.
Making content understandable is the first step. The next is enabling controlled action
Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?
Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.
The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.
The Drupal AI Initiative organises this work through two connected areas:
This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.
Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.
AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.
The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.
Your next website visitor might not be human - will your digital platform know exactly how to help them?
Try Drupal today!
Article by: Martin Anderson-Clutz. Originally posted on the Acquia blog.
Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.
Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful — out to the practitioners who live and breathe headless every day.
The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.
Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.
That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.
When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.
The industry tried to patch around this — bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.
Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.
Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature — an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.
By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.
And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, and Storyblok others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.
Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.
Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.
If you list what a good AI harness needs — structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance — Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.
Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.
Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.
I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.
Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page — every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.
The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface — colors on brand, formatting consistent with the rest of the library — with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.
When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.
I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts — which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.
For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.
Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too — no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines — ECA for event-driven rules, Maestro for durable, multi-step approvals — stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.
It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.
Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.
The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once — a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.
Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.
Making that case in Montréal was a highlight of my year. If you were in the room, thank you — the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.
This is cross-posted from Mike Herchel's blog
A few weeks ago, I met up with some of the DrupalCon Orlando local planning committee at the Hyatt Regency Grand Cypress Resort to check out the venue and finalize a bunch of plans.
We toured the resort, planned events, sampled food and drinks (strictly for quality assurance, of course), floated around the pools, and spent way too much time talking about all the fun stuff we're putting together.
After seeing everything in person, I'm convinced this is going to be the best DrupalCon ever!
If you've been to previous DrupalCons, one thing you'll notice right away is that this one is going to have a different vibe. Normally we're in a downtown convention center where you can walk to bars, restaurants, coffee shops, and whatever else you stumble across.
This isn't that. The Grand Cypress sits in the middle of Orlando's resort area near Disney. If you want to leave the property, you'll probably grab an Uber or Lyft. Disney Springs is only about 10 minutes away, and the parks are just beyond that.
But honestly... I don't think most people are going to want to leave. This resort is awesome.
Instead of everyone scattering around downtown after the sessions end, I think we're going to end up hanging out together around the resort having poolside cocktails, or smores by the fire pits. And after spending the weekend there, I think that's going to make for an even better conference.
Seriously. The pool area is unlike anything we've ever had at a DrupalCon.
The pools wind around faux limestone cliffs with waterfalls pouring down into them. There's a cave that connects two sections of the pool, a grotto, a waterslide, two hot tubs, and tons of places to spread out.
Then you've got a poolside bar serving frozen drinks, beer, and food just a few steps away. I can already picture dozens of Drupal people hanging out there after sessions.
If you're coming from somewhere that's still cold in late March... congratulations. This is probably the nicest time of year to be in Florida.
Expect highs around 80°F (27°C), cool evenings, blue skies, and weather that's pretty much perfect for sitting outside all day. It's warm enough to swim without feeling like you're melting.
One of the nicest surprises is the hotel rate that we have. The Drupal Association was able to lock in an incredible rate of just $259/night, and that includes no resort fee. Considering this is one of the best times of year to visit Florida (and a resort like this!) it's an amazing deal. If you're planning to attend, book sooner rather than later:https://www.hyatt.com/events/en-US/group-booking/VISTA/G-DC27.
This might sound boring compared to waterfalls and waterslides, but trust me, it matters. One thing I loved about the venue is how compact the conference space is. No hiking across giant hotel lobbies or speed-walking half a mile to your next session. No wondering which section your talk is actually in.
Everything is clustered together, which means less walking and more time talking to people in the hallways, which is the best part of every DrupalCon anyway.
I've been trying to make this happen for years. Every DrupalCon I’d pitch the idea of a talent show, and every year something got in the way. Well... this is the year! It’s happening!
We'll be looking for pretty much anything entertaining:
We’re not taking sign-ups just yet, but keep an eye out!
Besides your laptop?
This venue is a little different than what we're used to, but after spending the weekend there, I know it's going to create a totally different kind, and super memorable, DrupalCon.
Instead of everyone disappearing into the city after the sessions end, I think people are going to stick around. Hanging out by the pool. Sitting around the fire pits. Grabbing a drink. Talking Drupal late into the night.
And honestly? I can't wait!
This is a guest post from the team at Zoocha, a Gold Drupal Certified Partner with offices in the United Kingdom, Spain, Brazil, and the United States.
As Drupal agencies, we're fortunate to benefit from a vibrant ecosystem that generates awareness, interest, and opportunities for all of us. At Zoocha we receive inbound enquiries from a variety of sources. Whether they arrive via Drupal AI, Drupal CMS, a community recommendation, a Drupal event, or direct through our site, every enquiry often represents something important: a person taking their first step towards our community.
Not every lead is a project.
Not every lead has a budget.
Not every lead is ready to buy.
But they always deserve a meaningful response.
When someone reaches out to a Drupal agency, they're rarely just evaluating that agency, they’re more often than not seeking to engage with Drupal itself. For many prospective clients, they may not know the difference between Drupal, the Drupal Association, Drupal CMS, an implementation partner, a hosting provider, or the wider open source community. They simply know they've heard about Drupal and are looking for guidance.
The response they receive helps shape their perception of the entire ecosystem. If their first interaction feels dismissive, transactional, or overly focused on qualification, they may walk away believing that's what the Drupal community is like. If their first interaction is friendly and genuine, they leave with a very different impression.
Most agencies have some form of qualification process. It's sensible, and so do we. Time is valuable, and we know not every conversation will become a project.
However, there is a difference between understanding someone's needs and interrogating them. We've all seen responses that immediately ask:
While those questions have their place, they are rarely the most important thing during an initial conversation. Many prospects simply don't know the answers yet.
Some are conducting research. Some are exploring options. Some are trying to understand whether Drupal is even the right fit. At this stage, what they often need most is guidance.
One of the most effective approaches we've found at Zoocha is to assume that the first conversation may never lead to a sale. That does sound counterintuitive for a commercial organisation, but it changes the nature of the interaction. Instead of trying to move the conversation towards a proposal as quickly as possible, we focus on being useful. That might mean:
Sometimes that conversation ends there, and that's ok. The contact doesn't leave empty handed. They leave with a positive impression of who we are in the Drupal community.
Interestingly, some of our most successful client relationships started with conversations that had no immediate commercial outcome. We've had early exchanges that were little more than an idea, with individuals facing a specific challenge and just looking to find out if they're even in the right place with Drupal. After a person-first conversation, they disappeared. But a few months, or even a year, later, they came back, and what began as a casual enquiry became a long-term client partnership.
This didn't happen because we had the best sales team or process. It happened because we prioritised human connection over a fast sale.
Drupal has always been built around principles of collaboration, openness, and knowledge sharing, these values really shouldn't stop at code contributions. They can also shape how we engage with prospective users of the platform. When we answer questions generously, share expertise freely, and help organisations make informed decisions, we're strengthening confidence in Drupal itself.
Even if a particular opportunity never becomes a client engagement, the person on the other end of that conversation is left with a positive impression of the community. That's good for all of us!
The next time a speculative Drupal enquiry lands in your inbox, try viewing it differently. Consider simply asking, "How can we actually help this person?" The answer might only require a short email, a useful link, or a brief conversation, and yes, the immediate commercial return is likely to be zero. But the long-term return, for your agency and for the Drupal ecosystem, can be significant.
Every first interaction is an opportunity to demonstrate what makes the Drupal community different. Let's make sure it's a positive one.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
Dear Drupal community,
Open source hums along on the work that just gets done. As I step into the interim CEO seat, I'm making a point to notice the sheer volume of work powering this ecosystem, from the DA and beyond. Here's some of what has come together in the past month:
My goal as interim CEO is straightforward: make sure the Association's foundation is resilient enough to support all this energy. The first step is helping all of us notice and appreciate the work that already "just happens."
I hope you enjoy this month's newsletter and everything everyone's been building. And one final note: board elections are open. Please vote.
Tiffany Farriss Interim CEO
If you're a Ripple Maker, your ballot arrived by email from Helios Voting on 22 July. Voting closes 14 August 2026 at 23:59 UTC, so there's still time to get to know the candidates: read their profiles and leave questions on the election details page, catch the Open Community Forum recording on our YouTube channel, or revisit the async conversation in #drupal-association on Drupal Slack. Every vote counts — make yours matter.
DrupalCon Rotterdam 2026 is ready. Join the global Drupal community for four days of learning, collaboration, and connection — explore the program, meet the speakers, and start planning your experience. Secure your ticket now.
The DrupalCon Orlando 2027 Call for Speakers opened 4 August and closes 20 October 2026, with some notable changes this year:
A more focused program with fewer concurrent sessions and an emphasis on high-quality, impactful content. Updated session tracks reflecting the evolving Drupal ecosystem. And a new pathway for first-time speakers: if you've never spoken at a DrupalCon, DrupalCamp, or other Drupal event, you can submit to the new Poster Session — selected presenters showcase their work at the Monday Welcome Reception and present a 10-minute session on the Lightning Stage.
And keep an eye out for Bytes the Gator, the DrupalCon Orlando mascot, who'll be visiting Drupal events around the world between now and March 2027 — with a chance to win a free registration to DrupalCon Orlando 2027 along the way.
Nominations are open for the Women in Drupal Award, sponsored by Jakala, recognising women whose work strengthens the Drupal community — in the projects they build, the teams they support, the ideas they bring forward, and the space they create for others to grow. Know someone whose contribution deserves recognition? Submit a nomination.
When highly critical vulnerabilities emerge — like SA-CORE-2026-004, a SQL injection in Drupal core that anonymous users can trigger — every minute matters. Drupal Steward is a security service from the Drupal Association that gives you extra time to respond before vulnerabilities can be widely exploited: early notification of highly critical issues, recommended WAF mitigation rules, and access to security expertise, in coordinated collaboration with the Drupal Security Team. It's available in a Community Tier for smaller site portfolios, plus Small, Mid-Size & Enterprise tiers for organisations that want full control. Referral incentives are available for Drupal Certified Partners.
The migration of projects to GitLab issues continues — including security issues and hundreds of Ripple Maker projects — with GitLab soon to be enabled by default for all new projects, alongside updated contribution docs and a new custom commands reference. The team has also kicked off a collaboration with Alpha-Omega through their Security Engineer in Residence program to triage and respond to the growing wave of AI-generated security reports. And an RFP is under way for the Drupal Site Template Marketplace, focused on closing the last mile from template selection to live hosted site.
We're building a dedicated product marketing site for Drupal — a purpose-built, marketing-led site designed to reach the people who haven't heard of Drupal yet: marketers, IT directors, and enterprise decision-makers evaluating CMS platforms.
High-priority tasks are being added to the promote_drupal project on GitLab — real, scoped pieces of design, content, video, and strategy work with significant contribution credits attached, with more added on a rolling basis. If something catches your eye, reach out to Ryan Witcombe at ryan.witcombe@association.drupal.org or @RyanWitcombe on Drupal Slack.
On 15 July, the Drupal Burkina Faso Association, led by its president Seferiba Salif Soulama, met with Burkina Faso's Minister of Digital Transition, Dr. Aminata Zerbo/Sabane, to explore how Drupal can support the country's digital future. The meeting marks a significant step toward a formal partnership between the Ministry and the Drupal Burkina Faso Association, with Drupal at the heart of Burkina Faso's digital modernisation agenda.
This is what open source looks like in action: communities, governments, and technology coming together to build something that belongs to everyone. Read the full story.
The Drupal AI Initiative team has launched The AI Byte, a monthly LinkedIn newsletter curating the best content across the web about Drupal AI — new capabilities, case studies, events, and webinars. Subscribe on LinkedIn.
This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.
AI was used to help adapt this newsletter into a blog post. It was reviewed and edited by Drupal Association staff before publishing.
When I took on the role of Interim CEO, I committed to being direct about our finances and noted that our earlier audits already told much of the story. The board has now released our 2025 audit report, which was provided to the Board of Directors of the Drupal Association on 8 July 2026 and approved on 25 July 2026. It provides additional context and detail, but does not change the overall picture or our path forward.
To be clear, nothing in this audit means any of the services the project depends on are at risk. What this audit does is help us to understand the status quo so that we can take appropriate action moving forward.
The DA spent about $451,000 more on operations than we brought in last year (2025), and that followed a larger shortfall the year before ($923,000).
Those two years are not cleanly comparable, because the 2025 audit also restates our previously audited 2024 results. Our auditors determined that about $353,000 of membership revenue had been recognized in 2024 that should instead have been allocated to 2025, when it was actually earned. This was a non-cash correction to our books: no money changed hands, and nothing was lost or misspent.
Together, 2024 and 2025 produced a combined shortfall of about $1.15M, which averages roughly $573,000 a year. Our current forecast puts 2026 on the same path.
Our cash reserves (the unrestricted funds we can actually spend on operations) have decreased by about 60% since the end of 2022, to roughly $960,000, which represents 2.3 months of operating expenses. Board policy sets a six-month target and a three-month reserve minimum. 2025 is the first year since 2019 that the DA has failed to meet the minimum. The DA remains a going concern and is not in danger of becoming insolvent, but it is time for action.
Coming out of 2022 with strong reserves, the board approved a three-year strategic plan on 6 June 2023 and chose to put some of its surplus toward ambitious, community-requested investments in marketing and project support. Funding strategic growth is how excess reserves are best leveraged.
These investments have had a measurable impact:
Contributions to Drupal strategic product innovation tripled, reaching 211,037 organizational credits in 2025, a 54% increase over 2024.
We reached 106 Drupal Certified Partners under enhanced "maker" requirements, roughly double the 2022 figure.
43 people were brought into Drupal leadership roles for the first time, against a goal of 38.
We adopted and executed a go-to-market plan for the launch of Drupal CMS, and built marketing capacity inside the DA for the first time.
However, the sustainability of these efforts long-term was tied to a goal which we did not meet:
Increase Drupal Association total revenues by 3X, from $3.49M in 2022 to $10.5M in 2026 to better support mission-driven activities.
Our reported revenue did grow about 25% between 2022 and 2025. While 2025 is one of our largest revenue years on record, this figure is misleading, because most of the growth is in non-monetary services provided in trade (described in more detail below). Putting that aside, the Association’s cash revenue grew 5% over three years while out-of-pocket costs grew 27%.
The gap is paid for out of our reserves. Reserves are the right instrument for starting something and the wrong instrument for running it. Funding our strategic initiatives from reserves was the right decision for the duration of the strategic plan, but while that plan ended last year, the work has continued without a viable funding plan.
Marketing and project support are precisely the kind of mission-aligned work the DA should be doing. So the task in front of us is to fund it properly: each program examined discretely, with its own revenue plan, and held to revenue neutrality now that it has moved out of pilot and into operations.
In 2022 we spent $1.3M running Drupal.org (the Web site, composer endpoints, GitLab, CI, authentication, and the global CDN), and in 2025 we spent $2.1M. That is up 61% in three years. It is the Drupal Association's single largest cost, and it has no direct funding mechanism. Every organization that uses Drupal relies on this infrastructure, but none of them are asked to pay for it, because we have never built a way for them to.
For most of Drupal's history that did not matter, because the surplus revenue from DrupalCon covered the costs of Drupal.org. However, since 2022 the DrupalCon surplus has fallen from about $994,000 to about $227,000. While event costs have continued to increase since we resumed in-person events, event revenue has gone down.
This means that we are increasingly relying on the generosity of a handful of vendors and partners who provide services for free or in trade for sponsorship placements. That generosity has grown from $249,249 in 2022 to $1,011,995 in 2025 and now covers nearly half of what we spend on Drupal.org. These services in trade and donated services have not reported in our monthly reports because they were “non-cash”; they appeared only at audit.
|
Share of what we spend on Drupal.org |
2022 |
2025 |
|
Covered by DrupalCon surplus |
76% |
11%↓ |
|
Covered by services in trade, gratis |
19% |
48%↑ |
|
Covered by general operating revenue |
4% |
41%↑ |
The remainder of the infrastructure spending gap must be paid for out of general operating revenue, and failing that, out of reserves. These costs increased from $56,825 in 2022 to $859,384 in 2025.
It is also important to note that these numbers do not account for work that is deferred because the funding is not there to pay for it. This technical debt does not appear on any of our financial statements, but is a growing liability that will need to be paid for at some point.
The bottom line is that while our cash spending on infrastructure has remained steady, we have a rising essential cost that currently has no funding model attached to it yet.
The fiscal year 2024 closed 31 December 2024. The initial audit for 2024 was released in July 2025 showing $570,000 of deficit. Then in July 2026, it was restated downward to a $923,000 deficit as part of the 2025 audit.
While the Drupal Association CEO is accountable for the organization’s day-to-day operations, the board provides oversight over the organization’s budget and finances. This oversight requires timely, accurate, and consistent financial reporting.
The monthly reports that the board’s Finance Committee reviewed and the audited statements published 6 months after the year close were prepared on different bases, with nothing reconciling the two. The Finance Committee struggled to get consistent answers or clarity about what individual figures included. In April 2026, Finance Committee asked our auditors to examine the reporting revenue recognition practices directly. That request is what produced the restatement of 2024 as part of the 2025 audit. This also explains how long it took to know where we stood in 2024.
The responsible approach is to act now, while we can still make changes on our own terms rather than in a crisis. Some of this is already underway and the rest has dates attached to it.
As Interim CEO, I am operationally accountable to make sure that the board has access to an annual budget that is actively managed with variances mitigated; receives consistent, contextualized and timely financial reports; and that robust internal controls and workflows are in place. This clarity will give the Finance Committee and the board what they need to exercise proper oversight within the policy guardrails they have set.
Our internal reporting will be reconciled to audit-basis accounting, so that the figures the board governs against during the year are as close as possible to the ones we publish after it; non-cash arrangements will be recorded as they occur rather than at year end; and our reserve position will be reported on a single defined basis, against both policy thresholds, every period.
Drupal.org will be presented as a program with a cost that the Drupal Association is accountable for funding. The Association needs a durable way to fund Drupal.org rather than the patchwork indirect one we have now. These issues are not unique to Drupal, and I am looking forward to hearing others' thoughts, but be assured that I do not intend to solve a funding problem by reducing the services the community relies on.
Within the coming months, I will publish:
What each part of our work actually costs and how it is funded
The full costs of Drupal.org as a measurable figure, which will be the first time anyone, including the board, will have seen that number
An updated 2026 forecast and preliminary mitigation plan
This fall, I will prepare a two-year 2027-2028 Operating Budget with the Finance Committee that the board will be able to review and approve before the end of the year.
Nothing about the 2025 audit changes our commitment, our mission or the direction we need to go. It just adds a little urgency. I am focused on co-creating a financial model where the work sustaining Drupal rests on a foundation that is resilient and sustainable for the next long-term CEO.
Author: Will Huggins
In our previous blog posts, we’ve talked about how our growing ecosystem — now backed by 32 global partner organisations and a dedicated delivery team — is structured to build a secure, stable, and highly integrable AI-native digital experience platform.
So what does this mean for your day-to-day digital communications and marketing operations? How do you translate this into improved experiences for your audience, higher conversion rates, and reduced cost?
To win in the age of AI, digital leaders don’t just need faster ways to generate content or build great digital experiences. They need a platform that helps them move at maximum speed, while still maintaining the highest quality and content standards.
Here is an inside look at the key features on the Drupal AI 2026 roadmap, focused on the outcomes that matter most to digital communications and marketing teams: speed, brand safety, and measurable ROI.
Many AI-powered page builders on the market suffer from what digital leaders call "AI Slop": random, messy, raw HTML blocks based on generic AI models. These pages can break your site's layout, look wildly off-brand, fail accessibility standards, and create the dreaded ‘technical debt’ for your developers to clean up.
Drupal AI’s upcoming Canvas AI Page Builder operates under a completely different paradigm. It is natively component-aware.
A major anxiety for marketing teams is brand dilution. If your team is using disconnected AI tools, your brand voice can quickly fragment, sounding professional on one page and generic on another.
Drupal AI solves this by embedding a centralised Context Control Centre directly into the CMS. This serves as the single source of truth for your brand's identity and governance rules.
You can scale your global content footprint across multiple regions and channels, confident that every single piece of copy, everywhere, sounds exactly like you.
Today, your content lives in the CMS, but your performance data is trapped inside a web analytics dashboard (like Google Analytics or Matomo), and the two systems rarely talk to each other. As a result, marketing teams often miss trends, fail to optimise low-performing pages, and struggle to scale what actually works.
Drupal AI is built to close this loop by bringing performance intelligence directly into the content creation interface.
No more digging through dashboards to find what's not working. Your website becomes a living, self-optimising engine, learning what works best for your audience and handing ready-to-publish optimisations directly to your content editors, bridging the gap between data and action.
Speed is meaningless if your IT department or compliance team vetoes your tools due to security risks. To build an AI platform organisations can trust, Drupal AI treats security and governance as structural priorities, not afterthought add-ons.
Unlike lightweight SaaS tools that operate outside of your corporate governance, Drupal AI operates entirely within your existing approval workflows and editorial permissions.
This means you get the agility of generative AI backed by enterprise-grade, auditable, secure workflows: the kind of governance IT teams look for.
The future of digital experience is being built on open-source, model-agnostic foundations. By giving your marketing team visual page building, centralised brand context, and performance-driven optimisation within an enterprise-grade secure environment, Drupal AI is paving the way for digital teams to operate at maximum velocity with zero brand risk.
The future of open-source digital experience is being built right now. If your digital product or content marketing teams are ready to experience what is possible today, explore our progress and try the live demo.