Government CMS census of all 16,999 .gov domains: WordPress and CivicPlus run half of 8,827 live sites, and Drupal leads federal sites at 33%.

I used to cringe if a potential customer wanted a demo, thinking about how to mitigate the damage rather than how to impress them. Now demos are pivotal for sales: I want to get Drupal, and Canvas, in front of customers as soon as possible.

A new Canvas module for the times when team managing the site grows: decide who edits which pages and uses which components.

This is the second post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covered our testing infrastructure. Part three will cover the AI era and what we're exploring next.

When people talk about open source infrastructure, they usually mean git repositories and CI runners, and that's what our first post covered. But Drupal is a 25-year-old project with a global community, and the infrastructure that holds that community together goes well beyond code.

This post is about the rest of it: our translation platform, the contribution credit system, the tools for organizing events, and the community archives that AWS credits help keep online. We build the tools that enable our community to build Drupal, and many of those tools have nothing to do with merge requests.

Translating Drupal

Localize.drupal.org is our community translation platform, where more than 8,500 contributors work across 119 language groups. Together they have recorded nearly 1.8 million translations of more than 1.4 million source strings, across more than 33,000 projects.

Behind those numbers is a crucial pipeline: every time a maintainer ships a release, the platform parses it and extracts the translatable strings automatically. So far it has parsed more than 211,000 releases and scanned more than 15.8 million files. Translators then do the part that needs people: deciding how Drupal should read in their own language. In August, localize.drupal.org was one of the last services we moved off the old hardware at the Oregon State University Open Source Lab and onto AWS. Coming very soon, we'll be deploying an upgrade of localize.drupal.org to modern Drupal, thanks to an important group of community contributors.

Localization is how open source reaches people beyond the English-speaking developer world, and for many contributors, translating Drupal into their own language is the first contribution that leads to a greater contribution journey.

Recognizing the work that doesn't show up in git

Drupal does something rare among major open source projects: we record contribution, including work that isn't code, and credit both the people who do it and the organizations that sponsor them. Documentation, event organizing, mentoring, marketing, and accessibility work can all earn credit in our Contribution Records system, alongside code. In the three years to this September, it recorded more than 217,000 credits for more than 14,000 people.

Most of that credit still goes to code, because code is the easiest work to see, and we're working to change that. This fall we launched the Advocacy Program pilot, which awards credit for work that helps people discover and understand Drupal, and organizations can now see the events they sponsor in their Owner Tools on Drupal.org.

The reason we do this is practical: organizations choosing a Drupal partner can see who contributes, which gives companies a reason to sponsor their people's time, including for work that never touches the codebase. We've written about the limits of any credit system, and we adjust ours as we learn, most recently by raising the weight of core and core security work.

The community's calendar, and its memory

Communities organize, and organizing takes tooling. We run events.drupal.org for DrupalCon, and the community events calendar on Drupal.org holds the record of more than 1,700 past events going back to 2004, from local meetups to volunteer-run DrupalCamps around the world, with dozens more on the calendar now.

Why we think this matters beyond Drupal

Most of the conversation about open source sustainability focuses on paying maintainers, and for good reason. But there is a second gap that gets less attention: infrastructure for everyone around the maintainers, like the translators, event organizers, documentation writers, and the people who mentor new contributors. Many of the people who come to Drupal.org never open a merge request, and they need tools too.

Most projects never build this layer because nobody funds it. Fortunately, cloud credits are a practical way to close this gap: they pay for the servers under the translation platform and the events calendar just as they pay for CI. When AWS supports our infrastructure, it supports the community around the code as well as the code itself.

What's next in this series

In our final post: what the AI era is doing to demand on open source infrastructure, where our community's contribution numbers stand today, and how we're thinking about AI tooling for contributors who want it, not only those whose employers pay for it.

The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.

AI-Assisted Drupal Migrations: Better Discovery, Faster QA Joel Steidl Tue, 11/10/2026 - 10:49 Drupal

I've always been a big advocate of Drupal's Migrate API. It's incredibly flexible, allowing developers to pull data from just about anywhere. With contributed modules like Migrate Plus and Migrate Source CSV, that includes CSV files, SQL databases, JSON APIs, and other content management systems.

But migrations can be time-consuming. The process usually looks something like this:

1. Discover the existing data and define the new content structures.
2. Map source data to destination fields.
3. Write migration configurations and transformations.
4. Run migrations, QA the results, fix problems, and repeat.

That final step is often the most frustrating. Complex relationships, inconsistent legacy data, and unexpected edge cases can turn migration QA into a lengthy process of trial and error.

Drupal migrations are a particularly good fit for AI-assisted development. There's a lot of structured data to analyze, custom code to write, and repetitive testing to work through. I've found it especially valuable for data discovery, transformations, and QA.

Understanding the source data

Before writing migration configurations, we often need to spend considerable time understanding the source data, especially when working with unfamiliar databases or legacy content structures.

With a local, container-based development environment, an AI coding assistant can be given controlled access to a copy of the source database. This allows it to inspect tables, write SQL queries, identify patterns, and produce reports without manually investigating every relationship.

Consider rich-text fields in Drupal. They might contain embedded images, media references, links to PDFs, or other files that aren't immediately obvious from the content structure.

On a recent project, we wanted to migrate only media assets that were actually referenced in content. Rather than migrating every file from the legacy system, I used AI to analyze rich-text fields and generate temporary database tables containing unique references to images and documents.

This gave us a clearer picture of which files needed to be migrated and where they were being used.

A prompt might be as straightforward as:

Analyze the rich-text fields in the source database. Identify unique references to images, embedded media, and linked documents. Create a temporary table containing each referenced asset and the source content that uses it. Report any references that cannot be resolved.

Tasks like this previously required writing exploratory SQL, custom scripts, and repeatedly inspecting results. AI can significantly reduce that effort.

Custom transformations

Drupal's migration process plugins are powerful. They allow us to transform incoming data, manipulate values, look up related entities, and handle project-specific requirements.

Core and contributed modules cover many common scenarios, but some migrations require custom process plugins.

Recently, I used AI to help write a custom process plugin that validated existing addresses using Google's Address Validation API.

The site contained approximately 4,500 address entities, many referenced by other content. We suspected there were duplicates and inconsistencies, but determining which addresses could be safely removed wasn't straightforward.

The validation results helped us identify potential duplicates and flag existing address entities for review. This gave us a path toward reducing approximately 4,500 address entities to around 3,000, while accounting for their existing references.

Google's API doesn't perform deduplication. Instead, it gave us more consistent information to inform decisions about which entities should be retained or removed.

This is the kind of improvement I'd considered on previous projects but often couldn't justify because of the development effort involved.

AI makes it much more practical to explore these opportunities. A process plugin that might have required hours of research and development can often be drafted quickly, then reviewed, tested, and refined.

Not every transformation needs to be permanent, reusable code. Some are highly specific to a single migration. That's perfectly fine.

A migration is also an excellent opportunity to improve legacy data rather than simply reproduce its problems in a new system.

Making migration QA more effective

This is where I've found some of the biggest benefits.

Traditional migration QA involves reviewing imported content, identifying issues, adjusting migration scripts, and running everything again.

AI can help automate much of that investigative cycle.

For example, after running a migration, I might ask:

Select 10 migrated entities that collectively represent the most important edge cases, including complex field values, media references, and entity relationships. Compare the source and destination data, identify discrepancies, and explain why each example was selected.

An AI coding assistant with access to both databases can inspect records, compare values, and identify inconsistencies that might otherwise take considerable time to uncover.

It can also help investigate failures, propose fixes to migration configurations or process plugins, and rerun targeted migrations for verification.

Of course, reviewing 10 records doesn't prove an entire migration is correct. Automated checks for record counts, missing references, failed imports, and unexpected field values remain important.

But AI makes it easier to develop those checks and identify meaningful samples.

There's a client-facing benefit here, too. Instead of manually searching for representative content to include in a QA handoff, we can generate a curated set of examples covering different content types, relationships, and transformations.

That gives clients a more useful starting point for reviewing migrated content.

Keep developers in control

AI-assisted migrations still require an understanding of Drupal's data structures, the Migrate API, and the intended destination architecture.

Generated migration code needs review. Data transformations should be deterministic and testable. Complex relationships and potentially destructive cleanup operations require particular care.

It's also important to be deliberate about data access. A local container provides a controlled database environment, but that doesn't automatically mean data shared with an AI service stays local. Use approved tools, minimize access, and avoid exposing sensitive production data. The same considerations apply to third-party APIs, including restrictions on storing or reusing their response data.

The goal isn't to let AI independently decide how data should be migrated. It's to give experienced developers a faster way to investigate problems, test solutions, and verify results.

More time for the work that matters

Drupal's Migrate API was already one of my favorite parts of the platform. AI-assisted development makes it even more useful.

What excites me most isn't necessarily generating migration configurations faster. It's the ability to explore source data more thoroughly, tackle transformations that previously seemed too expensive, and make the QA process considerably more efficient.

Migrations will always require careful planning and validation. But spending less time tracking down obscure data issues means more time improving the quality of the migration itself.

Joel Steidl

The owner of a 3D printing workshop could no longer keep up with client requests. Printing took little of that time. Most of it went into retyping an address on the GLS portal, digging through WhatsApp for a measurement sent days earlier, and opening the slicer just to learn how long a print takes. That is the problem the owner brought to me.

I analysed the workshop's workflow, from the client's first message to the delivered parcel, and split it into twelve operations. I started with the ones that repeat on every order and picked a fitting technology for each: a deterministic agent (no AI), an AI agent, or a Mac app.

The owner is left with three operations: designing the part, starting the print and checking the result. That is the craft of the job.

At the center sits Drupal 11, the CMS the workshop already used with its clients, and it stays the only source of orders and statuses. Anything that reaches a client or the public goes out after the owner's yes.

Drupal runs an unusual kind of e-commerce here: it gathers requirements more than it sells from a catalog. The client describes what they need, and many parts are made to measure for them and stay private. On their page they follow the steps of the job: which parts are already printed, what is missing, the payment and the shipment tracking.

Read more

A company’s contribution ranking can depend heavily on one maintainer. What else does the public record reveal?

The HTTP method is half of your API's contract. The status code is the other half. Here are the codes that get misused most, and why it matters more now that AI agents are calling your API.

Five NEDCamp speakers examine how AI-assisted coding, native browser features, software review, reusable Drupal templates and user research are changing web development.

I’m writing about my NedCamp presentation because I’m excited about my AI-generated slide deck. Ironically, the entire presentation is about using AI to explore, build, maintain, and secure Drupal, based on my previous blog posts. Yet this post is about using AI to generate the presentation's visual narrative. Before we go further, I should share some background information.

Background

My undergraduate degree is in fine arts, with a focus on painting and some sculpture. I don’t make much art these days, but I appreciate the history, craft, and process behind making art, which helped me teach myself programming. With art and programming, AI is changing how works of art or programs are created. The reality is that AI isn't creating new things. It is generating code and images based on prior work and knowledge. Artists and developers can nudge or feed AI ideas that could generate something creative and new. I am starting to go down the rabbit hole of thoughts on AI and how I’ve integrated AI into my Drupal development workflow, which is the topic of my presentation. This post is about my presentation’s slide deck.

Past presentations

I’ve been presenting at Drupal events and recording demos for over a decade on the Webform module and my other Drupal projects. I’ve become comfortable with public speaking and organizing my thoughts. My slide decks have been simple, with me speaking off the cuff, without a script but with extensive practice beforehand.

Several times, I felt my presentation had a theme or narrative I could see visually portrayed in the slides. Still, I didn't have the bandwidth or resources to take dozens of photographs, find illustrations, or pay someone to create the imagery.

If you've seen any of my Webform presentations, which use a free comic-based template called Read More

In the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. In this episode: what the Drupal Association team took away from its first all-staff retreat in three years, how the Drupal certification program is evolving, and what’s coming up with the Rosetta Sprint and DrupalCon Orlando 2027.

“There are some things and some conversations that can only seem to happen when we’re all together."

The following is a transcript of Tiffany’s remarks, lightly edited for readability.

Being in one room

I’m Tiffany Farriss, the Interim CEO of the Drupal Association, and this is In the Open, my regular update on what’s happening at the Association as we navigate a year of change.

Top of mind for me is just how important and accelerating being together in person is. For the first time in three years, the entire Drupal Association staff was in one room. Drupal and the DA collaborate across global time zones every day. That’s just how it works. But there are some things and some conversations that can only seem to happen when we’re all together in the same place at the same time.

Why we exist

In our DA retreat, we spent a lot of time talking about why we exist. I know you know this, but a handful of companies now run most of the web, whether it’s cloud or search or browsers, and increasingly AI. Whoever runs your infrastructure gets a say in whether or how you get to use it. Using open source and Drupal offers a different, more sovereign option, a different future, if you will.

Drupal is a registered digital public good that enterprises and governments, the UN, and humanitarian and academic organizations rely on. So all of us at the DA traced a piece of our work to someone that it helps specifically, and then we mapped it to how it serves, whether it’s the makers who build Drupal, the advocates who share the message about what Drupal is and what it could do, or the patrons who fund it.

Every single role at the Drupal Association is essential to how we steward our open source project, how Drupal is actually able to manage the commons that we have. And a lot of that work is stuff that folks in the community may not ever really see or notice.

Evolving Drupal certification

This led us to our biggest strategic conversation of the week: the Drupal certification program.

I talked about this a little bit at Rotterdam. I feel like it’s the only thing I talk about these days. But for the last 25 years of Drupal, a really small group, mostly agencies and individuals, have been buying the round for millions of people around the world who use and run Drupal. And we’re super deeply grateful for that.

But as we all know, the agency landscape is changing, and it’s time for everyone who benefits from Drupal to buy a round too. As a 501(c)(3) program, we need to make sure that our mission serves the public interest. We’re not a trade association. We can’t give advantage to anyone or even just a few companies.

Those are real guardrails that we talked a lot about at the DA. The revamped Drupal certification is not a partner program. It’s not a trade association. We’re evolving it to be a public registry about those who engage with the Drupal ecosystem in a net neutral or a net positive way, and we’re going to build it on facts that we can verify about how organizations contribute.

By designing Drupal certification, it will include the entire ecosystem. Agencies, yes, of course. Hosting and platform providers, definitely, but also infrastructure providers, technology and third-party integrations, and global systems integrators. People who have been using Drupal, and we see them occasionally contributing in small ways, but we want to encourage them to be able to participate more.

AI has made code cheap, and what we’ve realized is that trust is precious. So you’re going to hear more about this idea of trust and Drupal trust over the coming months.

How we work together

We also talked a lot about how we work. Individuals here at the DA have worked side by side, some of them for many, many years. What we’re shifting to, though, is actually working together cross-functionally on things that relate to all of us.

So that’s really exciting, and I think that just reminded me that the DA needs to get together regularly and think about what it does and how we serve the Drupal community. I’m coming out of that very energized, and I also know that we’re not the only ones who need to get together regularly.

The Rosetta Sprint

Dries has proposed an in-person Rosetta Sprint for early January, and I think that’s coming together now. The idea with Rosetta is that Drupal modules describe what they can do once, so that AI assistants, front ends, and workflow tools can all use that same description, with no custom integration work for each kind of task you might want to do.

So if you maintain a module, Dries’ post explains how to start now, and I’ve put the link below.

DrupalCon Orlando 2027

Obviously, the biggest place we all come together as a Drupal community, and where that energy is really palpable, is DrupalCon. If you haven’t yet, please check out our DrupalCon Orlando site. Registration is open now for 2027.

This will be the first time since the absolutely epic DrupalCon Australia, which I missed sadly, that we’re going to be at a resort, an 1,100-acre resort, the Hyatt Regency Grand Cypress in Orlando, Florida. It’s in the Disney Springs area, right near Disney.

So you won’t want to miss it. Obviously, there will be sessions and contribution and the hallway track all in one place. But I do want to make sure that you know it is spring break week. So if staying on site with everyone really matters to you, I do encourage you to both register for DrupalCon and book your hotel now. We may be able to add more rooms, but not until the ones we already have are gone.

So you’re not going to want to miss it. The local team is deep in planning amazing things, and I know that they’ve started to recruit for the new Drupal’s Got Talent. So whatever your act is, we want to see it, so please do apply.

I’m putting links below to everything. So thank you to the DA team for a really great week together. Thank you to everyone who builds, champions, and funds Drupal, and I hope to see you in Orlando, if not before.

Follow the conversation

New episodes of In the Open publish each week. Subscribe on the Drupal Association YouTube channel to follow along.

With thanks to Stephen Cross of Second Signal Media for producing this series.

UX research, UX design, and UX audits answer different questions. Read this blog to learn what each one delivers and which one your project needs.

Choosing open-source software can free an organisation from a vendor's restrictions. It cannot free that organisation from the responsibility of maintaining what it uses. The distinction became harder to ignore when the Drupal Security Team and core release managers announced a shorter security-support window for standard minor releases. Beginning in 2027, coverage will fall from twelve months to eight, leaving site owners roughly two months to upgrade after a new minor version arrives. The decision reduces the workload for maintainers, but also leaves organisations less time to complete their own testing and approvals.

The pressure behind that decision is substantial. Between June and October 2026, Drupal published 256 security advisories across core and contributed projects, exceeding the 250 published during the preceding thirty months. The Drupal Association links the surge in reports to the growing use of AI-assisted vulnerability discovery, while funding from Alpha-Omega has supported efforts to manage the increased volume. Core release management, however, faces a separate funding problem, with experienced maintainers reporting significant reductions in sponsored hours. The result is an uncomfortable imbalance: more vulnerabilities are being discovered, but the resources needed to maintain and distribute secure software remain uncertain.

Public institutions face a similar challenge when pursuing digital sovereignty. Following DrupalCon Rotterdam's Government Summit, Bert Boerland, chair of Stichting Drupal Nederland, argued that public procurement should reward contributions to the software communities supporting government services, rather than paying only for finished applications. Governments may have the legal freedom to modify or replace their software, yet remain dependent on suppliers for the expertise to maintain it. Europe's Digital Commons EDIC strategy, which includes a maintenance funding pilot, offers one possible response to that dependency. Whether such commitments produce lasting support will depend on their implementation.

What connects these developments is the growing distance between those who benefit from open-source infrastructure and those responsible for sustaining it. Drupal's security commitments rely on maintainers whose time and expertise are finite, while public institutions depend on software communities that their procurement systems may do little to support. Neither problem can be resolved simply by choosing an open-source licence. As governments and businesses place more essential services on shared software, the question becomes less about whether they have the freedom to control it and more about whether they are prepared to share the responsibility that makes such freedom possible.

Follow The DropTimes on LinkedIn and Bluesky, or join #thedroptimes on Drupal Slack. 

Allen Jason wrote and curated this issue of Editor’s Pick.

Real-time Drupal with Drupack

One reason I want Drupal to standardize on FrankenPHP is so we can build on top of the built-in mercure server and unlock a whole new range of applications for Drupal. Of course we can do all this today, provided you maintain a separate server (most likely a nodejs server of some kind), write the integration code and make sure everything keeps working… I'm all about reducing the cost of ownership, it's not ideal to have to deal with that.

theodore November 9, 2026

Turn repetitive editorial work into reviewable drafts. Learn how to configure Drupal AI tasks, protect accepted content, control spending, and measure completed fields.

Which Drupal Canvas starter includes Workbench, how do the adapters differ, and what can prevent draft previews? A tested Next.js setup provides a practical reference.

A public contract can finance a new government website while leaving the software beneath it underfunded. That gap raises questions about who should pay for future fixes and improvements.

School website design lessons from the 100 largest US districts: what their homepages ship, what most miss, and the April 2027 accessibility deadline.

Drupal Paradigms

I've been using Drupal for a number of years now, and I've built up a set of paradigms (or heuristics) that help me with building Drupal sites. These are based around both using Drupal as well as developing and maintaining Drupal sites, and even web development in general.

When putting together content types or building Drupal modules I have these rules at the back of my mind, guiding my actions. They've even been used in more than one sales document where I talk about how we work.

In this article I will look into a set of Drupal paradigms, with some explanation about each one. I'll also add example where possible to illustrate my thoughts.

First, let's start with a classic.

Don’t Hack Core

You've probably heard this one before, but I thought I'd start with it as it is just as important now as it ever was.

Back in the Drupal 6 + 7 days, when I first started using Drupal, it was quite difficult to update the site when a new version came out. It was mostly a case of copy/pasting from a download into the correct directories to override any existing code already in your site.

This was before composer was introduced to Drupal and whilst tools like Drush Make existed to automate this, they weren't widely used in the community. At least, I rarely saw them used outside of projects I was building.

Because updating code was so manual the phrase "don't hack core" became quickly adopted as it became quite difficult or time consuming to update the versions and make sure that your overrides were still in place. Altering Drupal core files (or even module files) also meant that the site could experience bugs that weren't in the original code base and that the maintainers couldn't possibly assist with.

philipnorton42 Sun, 08/11/2026 - 18:55

This Drupal AI modules overview maps release maturity, dependencies, and run costs so your team can shortlist editorial, automation, search, and agent integrations.