In January 2025, Anoop John of TheDropTimes sent a LinkedIn message that set things in motion:
"Happy New Year. I was thinking we could put a live sponsorship tracker for DDEV on TDT. We should ask for people for $5 per month and we need 1000 people to hit the target right? What do you think?"
That message led to live, auto-updating DDEV sponsorship displays on multiple web properties, a public data repository, and a reusable web component—all feeding from a single source of truth.
DDEV's financial sustainability depends entirely on sponsorships (we have no other income). Communicating that need—and showing progress toward goals—requires getting accurate, up-to-date data in front of people where they already spend time. We wouldn't really expect to be successful with manual updates across multiple web and CLI properties.
What we needed was a data feed that could be consumed anywhere, updated (mostly) automatically, and displayed consistently.
Anoop's request spurred the creation of ddev/sponsorship-data, a public repository that aggregates sponsorship information from GitHub Sponsors and other sources, updated automatically. The data is published as structured JSON—for example, all-sponsorships.json—that any site or tool can consume.
Mark Conroy stepped up with a reusable web component that reads from the sponsorship-data feed and renders live sponsorship information. The component lives at web-components.mark.ie and is open source at markconroy/web-components. (DDEV has forked the original in order to maintain it for our particular uses.)
The component makes it trivial to embed a live sponsor list on any site—no backend required, no manual updates.
With the data feed and component in place, we integrated the live sponsor display into ddev.com. Since then, it has been added to addons.ddev.com and docs.ddev.com. Source for each:
Now, when sponsors join or leave, the banner updates automatically. No manual edits, no stale lists.
ddev start ShowsMost dedicated DDEV users aren't spending time on websites—they're in the terminal. ddev start has long provided a tip of the day, so we integrated the sponsorship feed into that output as well:
Some people report watching the numbers change day to day, cheering the project toward its goal.
The sponsorship situation for DDEV is something we take seriously and we know you do also: the project needs ongoing financial support to continue development and be maintained over the long term. Getting that message in front of people—accurately and consistently—helps. We're all a community working together to make this work.
The path from Anoop's January 2025 LinkedIn message to live sponsor feeds across multiple properties took a few months of work by community members who cared.
More than a year later, The Drop Times is still featuring the DDEV sponsorship banner!
Thank you for your support, and thank you for your encouragement to go down this path. It has resulted in better communication with our community and a shared sense of ownership around DDEV's future.
Mark, your packaging of a nice banner made things so much easier!
If you use DDEV and find it valuable, consider sponsoring at github.com/sponsors/ddev. Every bit that you and your organization can contribute helps all of us. Thank you!
read moreAt DrupalCon Chicago, the Driesnote included a visualization with “community” as one of the three pillars of Drupal, along with “platform” and “agencies.” That framing felt memorable, and worth exploring further.
If you attended DrupalCon Chicago, you might have experienced a slightly differently shaped triangle. I don’t know the attendance numbers, but I saw technical sessions with packed rooms, while community-focused sessions had plenty of empty seats. That’s not new. It’s been true for years. People care about community, but when the schedule forces a choice between a session on AI integration and one on community health, most folks choose the technical session. I understand why. Technical work feels concrete. Community work is generally not why employers send folks to a DrupalCon.
This raises a question: how can all of us work together to close that gap without having to attend community sessions at DrupalCon?
I serve on the Community Working Group (CWG), specifically on the Community Health Team. A lot of people don’t know there are two teams inside the CWG, so here’s the short version:
Both teams matter. And beyond the CWG, the DrupalCon Code of Conduct offers advice for all of us. It includes a section titled “We are collaborative,” which says:
If and when misunderstandings occur, we encourage people to work things out between themselves where this is practical. Where support is beneficial to achieve this, participants agree to ask for help. People are encouraged to take responsibility for their words and actions and listen to constructively-presented criticism with an open mind, courtesy, and respect.
I suspect that many people read the harassment list and the reporting email and stop there. That’s understandable. Those parts exist for a reason. But the passage above describes the wide middle ground where most friction in our community occurs.
If the only two options we envision are “this is fine” and “file a report,” we end up with a lot of buried resentment, a few dramatic blowups, and not much in between. Most day-to-day friction doesn’t rise to the level of a Code of Conduct violation. It’s tone. Assumption. Misread intent. A comment in an issue queue from someone who didn’t scroll up to read what had already been said. A joke that came off differently than it was intended.
The Community Health Team’s work is to strengthen the middle. That means helping people develop the habits and skills to address friction directly, kindly, and early, so it doesn’t compound into something that needs the Conflict Resolution Team. The Code of Conduct invites everyone to do this work. Not just CWG members. Everyone.
Here are four situations I’ve seen in the community, and in some cases been part of. None of these are scripts. They’re illustrations. The point is that the Code of Conduct invites you to try, and that you’re allowed to. You don’t need permission.
If you need help figuring out the best way to handle a situation like this, the Community Health Team is available. We can help you talk through a situation, decide whether a direct conversation is possible, or offer a second perspective. You can reach out at any time. We don’t investigate, and we don’t take sides. We think with you.
The Code says “where this is practical.” Sometimes it isn’t.
We live in a world with power differences. If the person on the other side holds significant authority over your ability to contribute, a direct conversation may not be safe for you. Ongoing patterns of behavior are different from single incidents. Safety concerns are different from style concerns. And if the other person has shown they aren’t willing to engage in good faith, you are not obligated to keep trying.
Those are incidents for the Conflict Resolution Team. Those are the situations the people on that team signed up for, and you can reach them through the incident report form. Filing a report is not escalation for its own sake. It’s using the right tool for the situation.
Returning to the Driesnote, if community is one of three pillars holding up Drupal, then the pillar can’t only be carried by the folks who show up to CWG sessions. The math doesn’t work. Community health has to happen in the rooms with the technical sessions, on the Slack channels where the code review happens, or at the dinner table where someone just got interrupted for the third time.
Most of the work the Community Health Team cares about isn’t work you need a whole session to learn. It’s work you’re already in a position to do. The next time something said in an issue queue doesn’t feel right, you catch yourself venting about someone, or you see a newcomer get talked over, you have a chance to support Drupal’s community.
Community is a pillar, which means it doesn't get held up by a small group of people with CWG in their session title. It gets held up, or it doesn't, by how we talk to each other on a Tuesday afternoon when no one's watching.
Drupal’s Code of Conduct doesn’t just give you a way to report harm. It also asks you to do the smaller, harder thing first. That’s where most community health happens.
At DrupalCon Chicago, the Driesnote included a visualization with “community” as one of the three pillars of Drupal, along with “platform” and “agencies.” That framing felt memorable, and worth exploring further.
If you attended DrupalCon Chicago, you might have experienced a slightly differently shaped triangle. I don’t know the attendance numbers, but I saw technical sessions with packed rooms, while community-focused sessions had plenty of empty seats. That’s not new. It’s been true for years. People care about community, but when the schedule forces a choice between a session on AI integration and one on community health, most folks choose the technical session. I understand why. Technical work feels concrete. Community work is generally not why employers send folks to a DrupalCon.
This raises a question: how can all of us work together to close that gap without having to attend community sessions at DrupalCon?
I serve on the Community Working Group (CWG), specifically on the Community Health Team. A lot of people don’t know there are two teams inside the CWG, so here’s the short version:
Both teams matter. And beyond the CWG, the DrupalCon Code of Conduct offers advice for all of us. It includes a section titled “We are collaborative,” which says:
If and when misunderstandings occur, we encourage people to work things out between themselves where this is practical. Where support is beneficial to achieve this, participants agree to ask for help. People are encouraged to take responsibility for their words and actions and listen to constructively-presented criticism with an open mind, courtesy, and respect.
I suspect that many people read the harassment list and the reporting email and stop there. That’s understandable. Those parts exist for a reason. But the passage above describes the wide middle ground where most friction in our community occurs.
If the only two options we envision are “this is fine” and “file a report,” we end up with a lot of buried resentment, a few dramatic blowups, and not much in between. Most day-to-day friction doesn’t rise to the level of a Code of Conduct violation. It’s tone. Assumption. Misread intent. A comment in an issue queue from someone who didn’t scroll up to read what had already been said. A joke that came off differently than it was intended.
The Community Health Team’s work is to strengthen the middle. That means helping people develop the habits and skills to address friction directly, kindly, and early, so it doesn’t compound into something that needs the Conflict Resolution Team. The Code of Conduct invites everyone to do this work. Not just CWG members. Everyone.
Here are four situations I’ve seen in the community, and in some cases been part of. None of these are scripts. They’re illustrations. The point is that the Code of Conduct invites you to try, and that you’re allowed to. You don’t need permission.
If you need help figuring out the best way to handle a situation like this, the Community Health Team is available. We can help you talk through a situation, decide whether a direct conversation is possible, or offer a second perspective. You can reach out at any time. We don’t investigate, and we don’t take sides. We think with you.
The Code says “where this is practical.” Sometimes it isn’t.
We live in a world with power differences. If the person on the other side holds significant authority over your ability to contribute, a direct conversation may not be safe for you. Ongoing patterns of behavior are different from single incidents. Safety concerns are different from style concerns. And if the other person has shown they aren’t willing to engage in good faith, you are not obligated to keep trying.
Those are incidents for the Conflict Resolution Team. Those are the situations the people on that team signed up for, and you can reach them through the incident report form. Filing a report is not escalation for its own sake. It’s using the right tool for the situation.
Returning to the Driesnote, if community is one of three pillars holding up Drupal, then the pillar can’t only be carried by the folks who show up to CWG sessions. The math doesn’t work. Community health has to happen in the rooms with the technical sessions, on the Slack channels where the code review happens, or at the dinner table where someone just got interrupted for the third time.
Most of the work the Community Health Team cares about isn’t work you need a whole session to learn. It’s work you’re already in a position to do. The next time something said in an issue queue doesn’t feel right, you catch yourself venting about someone, or you see a newcomer get talked over, you have a chance to support Drupal’s community.
Community is a pillar, which means it doesn't get held up by a small group of people with CWG in their session title. It gets held up, or it doesn't, by how we talk to each other on a Tuesday afternoon when no one's watching.
Drupal’s Code of Conduct doesn’t just give you a way to report harm. It also asks you to do the smaller, harder thing first. That’s where most community health happens.
Kevin Thull, who leads the Drupal Recording Initiative (DRI), joins us to discuss why DRI started, how it scaled from Kevin recording local camps to supporting many events, the hub-and-mentorship model for maintainers, differences between shipping kits vs onsite support, costs compared with traditional AV vendors, and challenges like aging capture hardware, audio/video troubleshooting, and sustainable funding.
For show notes visit: https://www.talkingDrupal.com/551
TopicsMOTW - Two-factor Authentication (TFA) - https://www.drupal.org/project/tfa TFA Email OTP Plugin - https://www.drupal.org/project/tfa_email_otp National Institute for Standards and Technology's Special Publication 800-63B section 3.1.1.2 "Password Verifiers" - https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver Drupal Recording Initiative - https://www.drupal.org/project/dri DrupalCon Chicago Playlist - https://www.youtube.com/playlist?list=PLpeDXSh4nHjQpb2cHv9rgQv4lvq1-ZkC3
GuestsKevin Thull - Drupal Recording Initiative kthull
Guest HostBernardo Martinez - bernardm28
HostsNic Laflin - nLighteneddevelopment.com nicxvan
Avi Schwab - froboy.org froboy
Module of the Weekwith Avi Schwab- froboy.org froboy
Two Factor Authentication - Two-factor authentication for Drupal sites. Drupal provides authentication via something you know – a username and password while TFA module adds a second step of authentication with a check for something you have – such as a code sent to (or generated by) your mobile phone.
TFA is a base module for providing two-factor authentication for your Drupal site. As a base module, TFA handles the work of integrating with Drupal, providing flexible and well tested interfaces to enable your choice of various two-factor authentication solutions like Time-based One-Time Passwords (TOTP), SMS-delivered codes, pre-generated codes, or integrations with third-party services like Authy, Duo and others.
read moreDear readers,
There is a quiet crisis unfolding in the Drupal ecosystem, and the community has yet to fully reckon with it. Beginner training programs, once the pipeline through which new developers discovered and committed to Drupal, are drying up one by one. DrupalEasy has sunset its flagship 15-year-old Drupal Career Online program. Drupalize.me has had to let staff go. DrupalTutor reports his student count has collapsed to roughly a quarter of what it was three years ago. These are not isolated setbacks; they are symptoms of a structural problem that cuts to the heart of Drupal's long-term viability.
What makes this moment especially sobering is that no single villain is to blame. The increasing complexity of post-Drupal 8, the rise of AI-assisted learning that lets developers skip foundational training, and a community that has historically leaned on technical excellence over outreach have all converged at once. Meanwhile, DrupalCon survey data hints at another uncomfortable truth: the community's flagship gathering risks becoming an insider circuit, where veterans feel at home and newcomers feel invisible. A closed loop, no matter how vibrant, eventually runs out of energy.
The path forward demands more than awareness; it demands coordinated will. Nascent initiatives like Drupal Open University, the IXP hiring incentive, and the Promote Drupal campaign are promising, but they cannot succeed as isolated efforts. The Drupal Association, its Certified Partners, and community leaders at every level must align behind a single, urgent mission: making Drupal the place where the next generation of developers begins, not just where the current generation convenes.
On a personal note,as I script my final newsletter as the sub-editor of The DropTimes, I extend my heartfelt gratitude to my teammates at TDT and the whole of Drupal Community for the amazing work they are doing and letting me be a part of it. Thank you!
Let's move on to the story highlights from past week.
Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.
Alka Elizabeth
Sub-editor
The Drop Times
Article by: María Fernanda Silva
If you’ve spent any time around Drupal lately, you’ve probably noticed that AI is everywhere — in the keynotes, in the hallway conversations, in the issue queues. You may also have noticed that everyone else seems to know what they're doing, while you're still trying to figure out where to start.
You are not. Not even close.
Those questions — what is actually going on, and where do I even start? — are exactly what the Drupal AI Learners Club was built for.
Angie Byron (webchick) has been part of the Drupal community since 2005: core committer, one of the driving forces behind Drupal 8, and one of those people everyone seems to know. She did not come to DrupalCon Chicago 2026 planning to start anything. She came to celebrate Drupal's 25th anniversary and catch up with old friends.
But somewhere between the hallway conversations and the late-night tables, she started picking up on something: a lot of people were anxious about AI, unsure what it meant for their work, their identity as Drupal developers, their community — and quietly terrified to admit they did not have it figured out.
"I don't know what is going on, and neither do you," she would later describe as the feeling she wanted to create space for. "It's fine. Nobody knows. It's changing too fast."
That feeling stuck with her. And the Drupal AI Learners Club was born. Not as a space to hype AI, and not as a space to condemn it, but as a place to cut through the noise and talk honestly about what these tools actually do, how people are using them, and where they fall short.
The club runs on a simple premise: come as you are. Sessions are low-pressure, informal, and require no prepared presentation. Participants share their setups, their workflows, what is working, and what is not.
The first session launched on April 8, 2026, with the topic "Share Your Setup!" and brought together community members to walk through the models, modules, agents, IDEs, and tools they were actually using day-to-day.
Sessions happen whenever someone steps up to talk about something (currently, ~weekly) and are recorded, so anyone who cannot attend live can catch up afterward. And as Angie puts it, there are no stupid questions. Everyone is here to learn, including the people who have been doing this the longest.
The Drupal AI Learners Club is not here to tell you AI is the future. It’s here to make sure that wherever this is going, the Drupal community goes together — developers, site builders, contributors, and everyone in between.
There are many ways to join the club: attend a session, suggest a topic, volunteer to present, or join the organizing team. Sessions are published to a playlist on the Drupal Association YouTube channel so you can catch up anytime, and the conversation keeps going in the #ai-learners channel on Drupal Slack.
And remember, as the Spanish proverb says: there is no silly question — only silly people who do not ask.
Article by: María Fernanda Silva
If you’ve spent any time around Drupal lately, you’ve probably noticed that AI is everywhere — in the keynotes, in the hallway conversations, in the issue queues. You may also have noticed that everyone else seems to know what they're doing, while you're still trying to figure out where to start.
You are not. Not even close.
Those questions — what is actually going on, and where do I even start? — are exactly what the Drupal AI Learners Club was built for.
Angie Byron (webchick) has been part of the Drupal community since 2005: core committer, one of the driving forces behind Drupal 8, and one of those people everyone seems to know. She did not come to DrupalCon Chicago 2026 planning to start anything. She came to celebrate Drupal's 25th anniversary and catch up with old friends. But somewhere between the hallway conversations and the late-night tables, she started picking up on something: a lot of people were anxious about AI, unsure what it meant for their work, their identity as Drupal developers, their community — and quietly terrified to admit they did not have it figured out.
"I don't know what is going on, and neither do you," she would later describe as the feeling she wanted to create space for. "It's fine. Nobody knows. It's changing too fast."
That feeling stuck with her. And the Drupal AI Learners Club was born. Not as a space to hype AI, and not as a space to condemn it, but as a place to cut through the noise and talk honestly about what these tools actually do, how people are using them, and where they fall short.
The club runs on a simple premise: come as you are. Sessions are low-pressure, informal, and require no prepared presentation. Participants share their setups, their workflows, what is working, and what is not. The first session launched on April 8, 2025, with the topic "Share Your Setup!" and brought together community members to walk through the models, modules, agents, IDEs, and tools they were actually using day-to-day.
Sessions happen whenever someone steps up to talk about something (currently, ~weekly) and are recorded, so anyone who cannot attend live can catch up afterward. And as Angie puts it, there are no stupid questions. Everyone is here to learn, including the people who have been doing this the longest.
The Drupal AI Learners Club is not here to tell you AI is the future. It’s here to make sure that wherever this is going, the Drupal community goes together — developers, site builders, contributors, and everyone in between.
There are many ways to join the club: attend a session, suggest a topic, volunteer to present, or join the organizing team. Sessions are published to a playlist on the Drupal Association YouTube channel so you can catch up anytime, and the conversation keeps going in the #ai-learners channel on Drupal Slack.
And remember, as the Spanish proverb says: there is no silly question — only silly people who do not ask.
Webhooks are one of the most useful tools in a modern integration toolkit. Instead of your Drupal site repeatedly asking "anything new?" on a schedule, an external system taps your shoulder the moment something changes. The result is faster data, fewer redundant requests, and integrations that actually behave like real-time systems.
At Aten, we build a lot of integrations. A recent project made the need for a more complete webhook solution clear: a client needed a centralized hub that could aggregate order data from Shopify and multiple Drupal Commerce sites, and keep customer addresses synchronized across all of them. Data was flowing in multiple directions, from multiple sources, with different payload formats. The existing options in the Drupal ecosystem either required significant custom code or handled one direction well but not the other. So we built something.
We're excited to introduce Entity Webhook, now available as a contributed module on drupal.org.
Entity Webhook gives Drupal a complete webhook toolkit built around three capabilities:
entity_webhook_broadcast submodule): Notify external systems when Drupal entities are created, updated, or deletedentity_webhook_polling submodule): Actively fetch data from external APIs on a schedule, as a fallback for systems that don't push webhooksThe key design decision: all three are driven by the admin UI. No custom module code is required to get a working integration.
The core module handles inbound webhooks through a three-tier configuration structure: endpoints, source types, and field mappings.
An endpoint defines the target entity type — a Commerce Order, a taxonomy term, a user, or any custom entity. A source type represents a particular payload format from a particular service (Shopify, Stripe, another Drupal site), along with its verification method. A field mapping connects a JSON value in the payload to a Drupal entity field.
Once configured, external services POST to:
/webhook/{endpoint_name}/{source_type}
The module responds immediately with a 200, queues the payload, and processes it asynchronously during cron — keeping your endpoint fast and your site stable under load.
Field values are extracted from the JSON payload using JSONPath expressions. A mapping like $.order.billing_address.first_name can reach deep into a nested payload structure. You can also combine multiple expressions or use hardcoded static values.
Before a value is written to an entity field, you can optionally run it through a mutation plugin to transform it: convert an ISO date string to a Unix timestamp, map a source status to a Drupal equivalent (paid → completed), convert a cents integer to a decimal price, apply a regex substitution, and more.
To keep entities in sync rather than creating duplicates, you mark one or more field mappings as identifiers. Before saving, the module performs a lookup — if an entity with those field values already exists, it updates it instead of creating a new one. Multiple identifier fields form a composite key.
Three verification plugins are included: HMAC-SHA256 signature validation (with configurable header name and encoding), API Key validation from a header or query parameter, and an IP/CIDR whitelist. All verification runs synchronously before any processing begins.
When configuration isn't enough, the module dispatches Symfony events before and after entity saves. A PreSaveEvent subscriber can modify the entity or cancel the save entirely. A PostSaveEvent subscriber can trigger downstream workflows or notifications — without touching core module code.
The entity_webhook_broadcast submodule monitors entity CRUD events and delivers signed JSON payloads to external endpoints. You configure outbound field mappings to define the payload shape, set a shared secret for HMAC-SHA256 signing, and optionally define conditions that filter which events trigger a broadcast.
Delivery is queue-based and asynchronous. If a delivery fails, the module retries with exponential backoff up to a configurable number of attempts. Every attempt — successful or not — is written to an audit log, which makes debugging integrations considerably less painful.
Not every external service supports webhooks. The entity_webhook_polling submodule handles those cases. You configure a schedule using a standard cron expression (e.g., */15 * * * *), implement a polling provider plugin for your API, and it feeds results into the same entity upsert pipeline used by inbound webhooks.
To avoid unnecessary processing, each fetched record is hashed with SHA-256. Only records whose hash has changed since the last run are queued for processing.
There are a few other maintained, Drupal 11-compatible webhook modules worth knowing about. Here's how they differ, based on reviewing each module's source code.
| Feature | entity_webhook | webhooks | webhook_receiver | symfony_webhook_receiver |
|---|---|---|---|---|
| Inbound webhooks | ✓ | ✓ | ✓ | ✓ |
| Entity upsert — config-driven, no code | ✓ | — | — | — |
| Field mapping UI | ✓ | — | — | — |
| Outbound broadcasting | Submodule | ✓ | — | — |
| Polling | Submodule | — | — | — |
| HMAC verification | ✓ | ✓ | Token-in-URL only | Symfony-native |
| API Key / IP whitelist verification | ✓ | — | — | — |
| Admin UI | ✓ | ✓ | — | — |
| Custom code required to process inbound | — | ✓ | ✓ | ✓ |
| Drupal 11 compatible | ✓ | ✓ | ✓ | ✓ |
Webhooks is the most established option and works well for outbound use cases. When it receives a webhook, it fires a webhook.receive Drupal event — your code handles what happens next. That flexibility is useful, but it means every inbound integration requires a custom event subscriber and no entity upsert comes for free.
Webhook Receiver is a code-first plugin framework. Its README is straightforward about this: "This module does not contain any graphical user interface." You extend a plugin base class, implement validatePayload() and processPayload(), and wire everything together in code. It's a solid foundation for developers building bespoke integrations, but every integration is custom work from scratch.
Symfony Webhook Receiver brings Symfony's Webhook component into Drupal. If your team is comfortable with Symfony's ConsumerInterface and service container conventions, it's a clean approach. Like the others, it has no admin UI, and each integration requires custom service definitions and consumer classes.
Entity Webhook is designed for the scenario where you want integrations to live in configuration — deployable, exportable via Drupal's config management, and maintainable without a developer on call every time a payload format changes.
composer require drupal/entity_webhook drush en entity_webhook # Enable submodules as needed: drush en entity_webhook_broadcast entity_webhook_polling
Then navigate to Administration > Configuration > Services > Entity Webhook to create your first endpoint. Full documentation is on the project page.
If you're working on a Drupal integration — connecting an e-commerce platform, a CRM, a payment processor, or another Drupal site — we'd love to help. Get in touch with the Aten team.
wslu package has been removed, but we fixed that in PR, and it has an easy workaround anyway.drush works again for Drupal's main branch, and there are lots of other updates. Lots of other updates. Visit coder.ddev.com and start.coder.ddev.com for more, and we'd love to hear your suggestions and experiences at coder-ddev repository or in the DDEV Discord. We've deployed a staging server, and have plans for automated testing of changes so we don't just deploy and try them out.Stas and Randy appeared on episode 549 of the Talking Drupal podcast. Get the inside scoop on latest DDEV updates, the DDEV Drupal Contrib add-on, coder.ddev.com, and more. Listen to episode 549↗
Community member bserem presented "From Chaos to Consistency" at DrupalDevDays Athens 2026, a DevOps session covering how DDEV brings order to local development environments. View the presentation slides↗. His correct and well-explained thesis is that DDEV add-ons are just a file/feature delivery mechanism that can be used to systematize your team's projects. Watch here for a blog from him!
A new book on DDEV! Set Up Drupal in 10 Minutes: A Practical DDEV & Composer Guide for Developers. English on Amazon, Italian on Amazon Italy.
Who remembers Mike Anello's 2018 book Local Web Development With DDEV Explained: Your Step-by-Step Guide to Local Web Development With DDEV? 4.6 stars! (Mike is now Treasurer and Board Member of DDEV Foundation, this is how you move up in the world!) My bet is that most of what he described there still works, although many things probably work better now.
Add-on Creation and Maintenance Contributor Training: Watch it↗
The TYPO3 community published a post on what's new in DDEV for TYPO3 developers. Read on TYPO3 News↗
The next DDEV board and advisory group meeting is May 6, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST. Add to Google Calendar • See the agenda.
Randy will be away May 19 through approximately June 9, on a bike trip in Sicily. The community will carry on!
Sponsorship is at 79% of the goal — thank you to everyone who has contributed!
March 2026: ~$9,294/month (77% of goal)
April 2026: ~$9421/month (79% of goal), making progress, thanks!
If DDEV has helped your team, consider sponsoring. Whether you're an individual developer, an agency, or an organization, your contribution makes a difference. → Become a sponsor↗
Contact us to discuss sponsorship options that work for your organization.
Compiled and edited with assistance from Claude Code.
read moreAs we migrate more projects to GitLab on git.drupalcode.org, we have discovered improvements to make in the mapping of Drupal.org project maintainers to GitLab’s project members, ensuring that it is a 2-way synchronization.
The next time you update maintainers for your project on Drupal.org, this will update all maintainers’ access in GitLab. Please review project members in GitLab, and under Activity, the Team events. Syncing is now more thorough, so there might be more maintainership and member changes than you expect.
In the next few days we plan to bulk update GitLab project members for all projects that have maintainers with “Maintain issues” on Drupal.org, granting them the project planner role in GitLab. This will enable more access for them to manage issues and merge requests in GitLab.
We reviewed all the mappings and have settled on:
Syncing is two-way, so that saving maintainers in Drupal will keep choices made in GitLab.
Reporter is very similar to planner, however it acts the same as guest for maintainership mapping. This preserves access when flipping between setting permissions in GitLab or Drupal. Access to “Maintain issues” in Drupal is mostly irrelevant with issues migrating.
Maintainer in GitLab previously did not grant “Administer maintainers.” It should because in GitLab, it allows the Manage project members permission, so it is a direct mapping.
Removing a maintainer in GitLab will
In addition to filling the gaps in the mappings, updates to maintainership in GitLab were missed, we hadn’t implemented a listener for the user_update_for_team webhook. So updating maintainers on Drupal.org will catch up all project member roles in GitLab.
Once all issues are migrated, “Maintain issues” will be removed from Drupal, and GitLab itself will be the only way to manage access below developer.
You can find the full details in the issue at #3586519: Migrate maintainers from Drupal.org projects as GitLab members
For any specific implementation questions, please comment on the issue. For general feedback, post to Drupal Slack's #gitlab-issue-feedback channel.
As we migrate more projects to GitLab on git.drupalcode.org, we have discovered improvements to make in the mapping of Drupal.org project maintainers to GitLab’s project members, ensuring that it is a 2-way synchronization.
The next time you update maintainers for your project on Drupal.org, this will update all maintainers’ access in GitLab. Please review project members in GitLab, and under Activity, the Team events. Syncing is now more thorough, so there might be more maintainership and member changes than you expect.
In the next few days we plan to bulk update GitLab project members for all projects that have maintainers with “Maintain issues” on Drupal.org, granting them the project planner role in GitLab. This will enable more access for them to manage issues and merge requests in GitLab.
We reviewed all the mappings and have settled on:
Syncing is two-way, so that saving maintainers in Drupal will keep choices made in GitLab.
Reporter is very similar to planner, however it acts the same as guest for maintainership mapping. This preserves access when flipping between setting permissions in GitLab or Drupal. Access to “Maintain issues” in Drupal is mostly irrelevant with issues migrating.
Maintainer in GitLab previously did not grant “Administer maintainers.” It should because in GitLab, it allows the Manage project members permission, so it is a direct mapping.
Removing a maintainer in GitLab will
In addition to filling the gaps in the mappings, updates to maintainership in GitLab were missed, we hadn’t implemented a listener for the user_update_for_team webhook. So updating maintainers on Drupal.org will catch up all project member roles in GitLab.
Once all issues are migrated, “Maintain issues” will be removed from Drupal, and GitLab itself will be the only way to manage access below developer.
You can find the full details in the issue at #3586519: Migrate maintainers from Drupal.org projects as GitLab members
For any specific implementation questions, please comment on the issue. For general feedback, post to Drupal Slack's #gitlab-issue-feedback channel.
Preamble
I've been discussing and committed to a Schema.org-first approach to building content models in Drupal for several years. Along the way, someone described Schema.org as "food for machines."
Originally, for Schema.org "machines" meant search engines; now it definitely means AIs and LLMs. Defining and generating accurate, well-structured Schema.org JSON-LD for a website is challenging and often treated as an afterthought. Even if you use my Schema.org Blueprints to create a Schema.org-first content model, it still requires significant work to set up and maintain.
AI can analyze vast amounts of information and provide instant answers to complex questions, or complete challenging tasks within minutes. Last year, I began to see how one could prompt an AI to recommend the ideal Schema.org JSON-LD markup by providing URLs to example content and linking to the appropriate Schema.org types and properties. Keep in mind that the LLMs behind AIs understand every public webpage and actively examine every piece of Schema.org markup on the web.
This realization led me to the notion that in Drupal, we can leverage our existing AI modules and tools to have AIs generate Schema.org JSON-LD markup for content with as little as a well-thought-out prompt.
Before I introduce you to my AI Schema.org JSON-LD module, three things need to be stated immediately and will be addressed in this post and a follow-up.
The remainder of this post is directly copied from the module's project page, with the understanding that additional posts are needed to cover the implications of this module for developers, such as myself, and for site builders and owners.
About this module
The AI Schema.org JSON-LD module provides a...Read More
read moreBuilding a flexible Frontpage has historically been a challenge in Drupal. Often, there is no fixed data model, and editors need the ability to quickly add, remove, or rearrange content. In this article, we compare how Canvas and Display Builder handle this scenario without relying on predefined fields, using only components. After all this will allows us to build all kinds of flexible pages, not just the Frontpage.
read moreEvery framework's API surface sits on a spectrum, from strict (typed interfaces, schemas, service containers) to loose (string keys, naming conventions, untyped hooks). Strict APIs cost more upfront: more boilerplate, more to learn before writing code. Loose APIs shift that cost later: more ambiguity, more reliance on naming conventions, and more bugs that are harder to detect and fix.
AI changes who pays. Boilerplate and learning curves don't slow agents down. What slows them down is missing feedback: code that runs but does the wrong thing, errors that don't point to the cause, conventions that have to be guessed. Magic-name binding, untyped hooks, unvalidated configuration, and conventions the code doesn't enforce produce exactly those failure modes.
For example, both Drupal and WordPress have long used magic-string hooks. In Drupal, you write a function like mymodule_user_login. WordPress uses a related pattern: a string action name passed to add_action(). In both cases, the binding is a string the language can't validate.
Get the name wrong and the system silently skips your code: no error, no warning, nothing in the logs. The function just sits there, unloved.
The signature is a convention, not a contract: the documentation says the user_login hook receives a $user object, but nothing enforces it. To your IDE or a static analyzer like PHPStan, it's just a function. They don't know it's wired into the platform's login flow, so they can't warn you when it's wrong.
A typed alternative makes the binding explicit. With a PHP attribute like #[Hook('user_login')] on a registered service, the class must exist, the method signature is type-checked, and the container wires the dependencies. IDEs, static analyzers, and AI coding agents can follow the chain from the attribute to the implementation.
For AI agents, this keeps the feedback loop tight instead of turning it into trial and error. That means they can move faster, spend less time debugging, and use fewer tokens.
At DrupalCon Chicago this March, AI coding tools migrated a Lovable-generated site into Drupal in hours. The strict APIs kept the agent on track.
This didn't start with AI. Drupal 8, which we shipped in 2015, introduced Symfony's routing, services, and event dispatcher, replacing large parts of the procedural hook system. Since then, we've kept reducing magic hooks. The attribute-based approach (#[Hook('user_login')]) landed in Drupal 11.1 and helps remove more of the remaining procedural-only paths.
Hooks aren't the only place Drupal has been getting stricter. Drupal stores a lot of configuration in YAML, which was one of the loosest parts of the system. A multi-year validation effort has been tightening that.
When an agent generates a content type definition or editor configuration, validation catches missing keys, invalid values, and broken references before anything is saved. The agent gets a precise error pointing to the exact field, instead of a runtime failure. That tight feedback loop is what makes Drupal a strong CMS for AI-assisted development.
Drupal made this bet early, and it was painful. The Drupal 7 to Drupal 8 transition broke backward compatibility and took years to recover from. But it left the platform much stricter. More than ten years in, we're still making Drupal stricter.
Meanwhile, WordPress made a different bet, prioritizing backward compatibility over stricter APIs. That kept the platform stable for a long time. It also kept the looseness.
Those trade-offs now determine how efficiently AI agents can work with each platform.
What used to be a stylistic choice is now a speed and cost problem. Loose APIs mean more debugging and guesswork. Strict APIs mean faster, more precise feedback. This was always true for humans. It's now also true for AI agents. But today that cost shows up in tokens.
read moreJoin us to hear directly from the team behind an award-winning AI solution built for local government. What does genuinely useful AI in public services look like? Not a concept, not a pilot, but a working solution that saves hours of manual work, improves accessibility, and puts better content in front of citizens faster.
Southwark Council's AI-powered PDF importer for Drupal is exactly that, and it won the prestigious Digital Leaders AI Impact Award 2026.
We are delighted to invite you to a webinar where you can hear the story first-hand.
Date: Tuesday 16th June | 16:00 BST
Guest: Angie Forson, Web and Digital Programme Lead, Southwark Council
Host: James Hall, Product Lead, Websites at Everyone TV
This is a rare opportunity to hear directly from a senior stakeholder about how Drupal and AI are delivering real, measurable value in an area that truly matters: public services for the citizens of Southwark.
Angie will walk through the journey, the challenges, the outcomes, and what it means for the wider local government sector.
Manual PDF conversion has long been one of the most time-consuming tasks facing council web teams. Converting a single document can take hours. Multiply that across thousands of PDFs and the burden becomes significant, both in staff time and in the delay it creates before citizens can access accurate, accessible information.
The Southwark team, working with their partners at Chicken, built an AI-powered importer for the LocalGov Drupal Publication Module that reduces that process to minutes, often under one minute.
Each PDF passes through a three-step pipeline:
The result is an HTML representation of the PDF content, saved into a Drupal Publication and ready for review before going live. Every import is logged, so errors can be identified and resolved efficiently.
The module uses a plugin architecture, meaning each step in the pipeline can be swapped out. Councils can use different extractors, AI models, or output to different Drupal content types, making the solution adaptable to a wide range of content and operational requirements.
The team delivered this project with an agile, user-centred approach, continuously refining requirements to ensure the tool meets real user needs rather than simply ticking a technical specification.
"This project is a great example of AI working alongside and empowering content creators, and Drupal as a platform supports this really well." - Farez Rahman, Drupal Developer
"I'm excited about the impact this product will have, not just for our users, but also in transforming how we design, build, and create content internally. We're shaping a future where services start with HTML-first thinking." - Evelyn Francourt, User Experience Lead
Local government teams across the country face the same challenge. This solution, built on open source Drupal and the LocalGov Drupal ecosystem, is designed to be shared, not kept in one place.
If your organisation publishes PDFs, manages large volumes of content, or is exploring where AI can deliver practical value without unnecessary complexity, this webinar is for you. Tuesday 16th June | 16:00 BST | Online.
Join us to hear directly from the team behind an award-winning AI solution built for local government. What does genuinely useful AI in public services look like? Not a concept, not a pilot, but a working solution that saves hours of manual work, improves accessibility, and puts better content in front of citizens faster.
Southwark Council's AI-powered PDF importer for Drupal is exactly that, and it won the prestigious Digital Leaders AI Impact Award 2026.
We are delighted to invite you to a webinar where you can hear the story first-hand.
Date: Tuesday 16th June | 16:00 BST
Guest: Angie Forson, Web and Digital Programme Lead, Southwark Council
Host: James Hall, Product Lead, Websites at Everyone TV
This is a rare opportunity to hear directly from a senior stakeholder about how Drupal and AI are delivering real, measurable value in an area that truly matters: public services for the citizens of Southwark.
Angie will walk through the journey, the challenges, the outcomes, and what it means for the wider local government sector.
Manual PDF conversion has long been one of the most time-consuming tasks facing council web teams. Converting a single document can take hours. Multiply that across thousands of PDFs and the burden becomes significant, both in staff time and in the delay it creates before citizens can access accurate, accessible information.
The Southwark team, working with their partners at Chicken, built an AI-powered importer for the LocalGov Drupal Publication Module that reduces that process to minutes, often under one minute.
Each PDF passes through a three-step pipeline:
The result is an HTML representation of the PDF content, saved into a Drupal Publication and ready for review before going live. Every import is logged, so errors can be identified and resolved efficiently.
The module uses a plugin architecture, meaning each step in the pipeline can be swapped out. Councils can use different extractors, AI models, or output to different Drupal content types, making the solution adaptable to a wide range of content and operational requirements.
The team delivered this project with an agile, user-centred approach, continuously refining requirements to ensure the tool meets real user needs rather than simply ticking a technical specification.
"This project is a great example of AI working alongside and empowering content creators, and Drupal as a platform supports this really well." - Farez Rahman, Drupal Developer
"I'm excited about the impact this product will have, not just for our users, but also in transforming how we design, build, and create content internally. We're shaping a future where services start with HTML-first thinking." - Evelyn Francourt, User Experience Lead
Local government teams across the country face the same challenge. This solution, built on open source Drupal and the LocalGov Drupal ecosystem, is designed to be shared, not kept in one place.
If your organisation publishes PDFs, manages large volumes of content, or is exploring where AI can deliver practical value without unnecessary complexity, this webinar is for you. Tuesday 16th June | 16:00 BST | Online.
Stas Zhuk and I covered the full add-on lifecycle in this Contributor Training session: bootstrapping from the ddev-addon-template, writing Bats tests, testing locally and against branches or open PRs, and publishing to the registry. The session also covers use cases beyond service providers — custom commands, DDEV hooks, and distributing team workflows across projects.
The slides are available online (source).
Most people first encounter add-ons as service providers — Redis, Elasticsearch, Solr, Mailpit — but Bill Seremetis (bserem) put it well in his DrupalDevDays Athens 2026 talk: "an add-on is a set of files: hooks + commands + scripts + config — it's a distribution mechanism." His agency uses a single custom add-on across 100+ Drupal projects to encode institutional knowledge, enforce quality gates, and deliver the team's workflows to the terminal. One update to the add-on propagates improvements to every project. That framing opens up a lot: custom commands that automate your team's processes, DDEV hooks that fire at key checkpoints (sanitize the database on import, install Git hooks on project start), and boilerplate configs or scripts distributed automatically to wherever they're needed.
The heart of every add-on is an install.yaml, which defines what files get placed at the project-level or globally, plus pre_install_actions and post_install_actions that can run shell or PHP scripts during install.
Getting started with a new add-on is straightforward: use the ddev-addon-template, which wires up GitHub Actions CI and a tests/test.bats Bats test suite from the start. You can test locally before publishing with ddev add-on get /path/to/your/addon, against a branch with --version branch-name, or against an open PR with --pr 54. When ready to publish to the world (if you want to), add the ddev-get topic to your GitHub repository and it will appear in addons.ddev.com within about 24 hours.
Your suggestions to improve this blog are welcome. You can do a PR to this blog adding your techniques. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.
Follow the DDEV Newsletter for information about upcoming user and contributor training sessions.
read moreAccessibility requirements for websites are increasingly being enforced across public and private sectors, affecting Drupal-based systems used by governments, universities, and businesses. Compliance with WCAG standards is no longer treated as a one-time milestone but as an ongoing responsibility that spans both system configuration and everyday content publishing.
In a recent LinkedIn post, John Harris highlights how reliance on automated scans often leaves significant gaps in accessibility compliance, particularly in areas that require manual validation and editorial oversight.
At the same time, accessibility in Drupal environments continues to depend on both technical systems and publishing practices, with emerging risks from AI-generated content further complicating matters. These factors point to accessibility as a continuous, shared responsibility rather than a fixed checkpoint.
Here is a selection of Drupal stories published over the past week.
Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.
Kazima Abbas
Sub-editor
The Drop Times
In episode 550 of Talking Drupal, Rod Martin joins us to discuss how Drupal site builders are defined, how their role has changed across Drupal versions, and what the future may look like with Drupal CMS, Canvas, and Drupal AI. The show's module of the week is Password Policy, presented by Avi Schwab, covering customizable password constraints and password expiration/reset features, along with supporting modules Password Policy Extras and Password Policy Pwned, which checks passwords against the Have I Been Pwned database. The conversation also explores the challenges site builders face around layout, theming, and configuration management, and the need for better templates, workflows, and guardrails as AI-assisted site building evolves.
For show notes visit: https://www.talkingDrupal.com/550
TopicsNIST Password Guidelines - https://specopssoft.com/blog/nist-password-guidelines/ Password Recipe -
Emdash - https://blog.cloudflare.com/emdash-wordpress/ Talking Drupal #122 - Taxonomy or Entity Reference https://talkingdrupal.com/122
GuestsRod Martin - DrupalHelps.com imrodmartin
HostsNic Laflin - nLighteneddevelopment.com nicxvan Avi Schwab- froboy.org froboy
Module of the Weekwith Avi Schwab- froboy.org froboy
Password Policy - A password policy can be defined with a set of constraints which must be met before a user password change will be accepted. Each constraint has a parameter allowing for the minimum number of valid conditions which must be met before the constraint is satisfied.
read moreThis is part four of a series of articles looking at HTMX in Drupal. In the last two articles we looked at using HTMX with controllers in different ways. This time I'll be venturing into the world of HTMX and forms.
Years ago on this site I wrote an article about Cascading ajax select forms in Drupal, which I often refer back to when I'm trying to figure out something to do with select forms and ajax. In that article I take a year, month, and day select field and tie them together so that they influence each other during the selection process.
I've been writing Drupal sites for quite a number of years and I still need to take a deep breath before attempting to embark on implementing ajax in Drupal forms. I end up with form fields that have wrapper elements or custom attributes in an attempt to get things working. It always seems to be a painful experience.
When I was learning about HTMX and Drupal I sat down to re-implement this cascading select form and had something working in about half an hour. Most of that time was spend adding the form elements to the build form method. A stark difference between the old and the new ways of adding ajax to forms in Drupal.
In this article we will look at creating a form that contains multiple select elements and then use HTMX (and a little bit of the form states API) to tie them together so that selecting one element updates the others.
All of the code contained in this article can be found in the Drupal HTMX examples project on GitHub, but here we will go through what the code does and what actions it performs to generate content.
Just like the other articles on HTMX, I'm going to start with the basics and define the route.
philipnorton42 read moreThis is the fourth post in our GitLab issue migration series. The earlier posts focused on what is changing and how maintainers should set up their projects. This one is for the rest of us — the people who file bugs, review code, push fixes, and triage queues without wearing a maintainer hat. If your favorite contrib project has just moved its issues to git.drupalcode.org, here's what you need to know.
When a project's issues are migrated, they move from www.drupal.org/project/{name}/issues to git.drupalcode.org/project/{name}/-/work_items. Old URLs redirect to the new ones, and issue numbers (NIDs) are preserved as GitLab IIDs — so an #3409678: Opt-in GitLab issues you find in a commit message will still resolve to the same issue.
In GitLab, "issues" are technically a subtype of "work items," but the term issue still applies, and you'll see it throughout the UI. If you've worked on any GitHub or GitLab project before, the experience will feel familiar.
A lot has not changed:
It's worth naming a few real wins for contributors:
A few permission details are worth knowing up front, because they're tighter than what you may be used to on the old issue queue:
That last point is real friction for contributors who triage and label issues, and we're addressing it directly. #3559846: Allow changing GitLab issues labels for all contributors is building a label-management UI that will live on drupal.org, alongside the existing contribution credit and issue fork management screens. Once it ships, any contributor will be able to manage labels on any issue without needing a project role on GitLab. This is also an upstream issue, but it doesn't seem to be worked on.
Until then, if metadata needs updating, leave a comment noting what should change. Maintainers and other contributors with the role can apply it.
Good news for anyone with muscle memory for Drupal's NW / NR / RTBC dance: the conventions weren't dropped in the migration. They were preserved as scoped labels on GitLab issues — state::rtbc, the equivalent state labels for needs-work and needs-review, priority labels, and so on. Each project's setup may vary, but the familiar conventions carried over, and contributors can keep using them.
| Convention | Now |
|---|---|
| Needs work | state::needsWork label (alternative: MR set to Draft) |
| Needs review | state::needsReview label (alternative: MR set to Ready) |
| RTBC | state::rtbc label (alternative: MR approval) |
| Needs reroll | Push a rebase to the issue fork branch |
Two notes:
Navigate to the project, click Work items in the left sidebar, then New item. The form is just a title and description; labels and metadata are added afterwards by users with the appropriate role. If a project has set up issue templates (markdown files in the repo), you'll see them in a dropdown.
The first comment on every new issue is posted by DrupalBot. It's the bridge to the things that still live on drupal.org:
The fork management screen on drupal.org works the same way for GitLab issues as it has for Drupal.org issues. From there, you can create a shared issue fork, request access if one already exists, push a branch, and open an MR. Branching and merging happen in GitLab's native UI, where they're already optimized.
During the transition, contributors will be working with both Drupal.org issues and GitLab issues, sometimes in the same comment. The syntax differs by direction:
[ #123456 ] (unchanged)#123456 (no brackets)For "related issues" entries on Drupal.org, always use the full URL when pointing at a GitLab issue.
A few oddities are worth flagging if you're working through historical issues:
#123456 still maps to the same issue. The original author's name is preserved in the first line of the issue description.Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.
Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.
We're actively iterating on this transition based on what we hear from contributors and maintainers in opted-in projects. The more feedback we get now — while we're still in the opt-in phase — the better the experience will be when the rest of contrib gets batch-migrated.
For more detail on any of the GitLab features mentioned in this post, the official GitLab documentation is the canonical source.
Issues and work items
Labels and permissions
Merge requests
Markdown
Related blog posts in this series:
Related issues
* We used Claude AI to refine our first draft and help link related materials like the GitLab documentation.
This is the fourth post in our GitLab issue migration series. The earlier posts focused on what is changing and how maintainers should set up their projects. This one is for the rest of us — the people who file bugs, review code, push fixes, and triage queues without wearing a maintainer hat. If your favorite contrib project has just moved its issues to git.drupalcode.org, here's what you need to know.
When a project's issues are migrated, they move from www.drupal.org/project/{name}/issues to git.drupalcode.org/project/{name}/-/work_items. Old URLs redirect to the new ones, and issue numbers (NIDs) are preserved as GitLab IIDs — so an #3409678: Opt-in GitLab issues you find in a commit message will still resolve to the same issue.
In GitLab, "issues" are technically a subtype of "work items," but the term issue still applies, and you'll see it throughout the UI. If you've worked on any GitHub or GitLab project before, the experience will feel familiar.
A lot has not changed:
It's worth naming a few real wins for contributors:
A few permission details are worth knowing up front, because they're tighter than what you may be used to on the old issue queue:
That last point is real friction for contributors who triage and label issues, and we're addressing it directly. #3559846: Allow changing GitLab issues labels for all contributors is building a label-management UI that will live on drupal.org, alongside the existing contribution credit and issue fork management screens. Once it ships, any contributor will be able to manage labels on any issue without needing a project role on GitLab. This is also an upstream issue, but it doesn't seem to be worked on.
Until then, if metadata needs updating, leave a comment noting what should change. Maintainers and other contributors with the role can apply it.
Good news for anyone with muscle memory for Drupal's NW / NR / RTBC dance: the conventions weren't dropped in the migration. They were preserved as scoped labels on GitLab issues — state::rtbc, the equivalent state labels for needs-work and needs-review, priority labels, and so on. Each project's setup may vary, but the familiar conventions carried over, and contributors can keep using them.
| Convention | Now |
|---|---|
| Needs work | state::needsWork label (alternative: MR set to Draft) |
| Needs review | state::needsReview label (alternative: MR set to Ready) |
| RTBC | state::rtbc label (alternative: MR approval) |
| Needs reroll | Push a rebase to the issue fork branch |
Two notes:
Navigate to the project, click Issues in the left sidebar, then New issue. The form is just a title and description; labels and metadata are added afterwards by users with the appropriate role. If a project has set up issue templates (markdown files in the repo), you'll see them in a dropdown.
The first comment on every new issue is posted by DrupalBot. It's the bridge to the things that still live on drupal.org:
The fork management screen on drupal.org works the same way for GitLab issues as it has for Drupal.org issues. From there, you can create a shared issue fork, request access if one already exists, push a branch, and open an MR. Branching and merging happen in GitLab's native UI, where they're already optimized.
During the transition, contributors will be working with both Drupal.org issues and GitLab issues, sometimes in the same comment. The syntax differs by direction:
[ #123456 ] (unchanged)#123456 (no brackets)For "related issues" entries on Drupal.org, always use the full URL when pointing at a GitLab issue.
A few oddities are worth flagging if you're working through historical issues:
#123456 still maps to the same issue. The original author's name is preserved in the first line of the issue description.Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.
Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.
We're actively iterating on this transition based on what we hear from contributors and maintainers in opted-in projects. The more feedback we get now — while we're still in the opt-in phase — the better the experience will be when the rest of contrib gets batch-migrated.
For more detail on any of the GitLab features mentioned in this post, the official GitLab documentation is the canonical source.
Issues and work items
Labels and permissions
Merge requests
Markdown
Related blog posts in this series:
Related issues
* We used Claude AI to refine our first draft and help link related materials like the GitLab documentation.
One year ago, at Drupal Developer Days in Leuven, something special happened.
The Drupal AI Initiative was not officially launched yet. That would happen later, in June. But Leuven was where the spark happened. It was where the first real momentum came together. Where conversations turned into commitment. Where a shared belief became a shared plan.
Five companies stepped up to kickstart the initiative: Dropsolid, Acquia, 1xINTERNET, FreelyGive, and Salsa Digital. Together, they helped turn an ambitious idea into the beginning of a movement.
Now, one year later, as we gather again at Drupal Developer Days in Athens, we celebrate one year since that moment of conception.
Leuven was where the initiative was kickstarted. June was when it officially went live. Athens is where we celebrate how far it has come.
The Drupal AI Initiative was created with a bold ambition: to help Drupal become the leading open source CMS for AI-powered digital experiences.
But from the beginning, this was never just about adding AI features.
It was about building AI into Drupal in a way that reflects the values of the Drupal community: open, flexible, responsible, transparent, and collaborative. It was about giving organizations the tools to innovate with AI while keeping control over governance, content, security, editorial workflows, and long-term digital strategy.
Over the past year, the initiative has grown from a spark in Leuven into one of the most ambitious collaborative efforts in Drupal’s history.
Since the official launch of the Drupal AI Initiative, the team has made major progress. The amount of installs is growing significantly, 13980 at the time of writing. Adoption is accelerating. According to shared data we’re growing at about 260 sites per week and accelerating.
This is only the sites that share numbers, the real share is much higher.
Between Drupal Con Vienna and Chicago, the initiative added 12 new partners, a total of 34, representing a 50% increase in participation. We are on track to match this growth in support between now and DrupalCon Rotterdam, a key goal for this year.
The initiative also successfully established and executed the delivery management RFP process, putting important operational frameworks in place, including:
These may sound like operational details, but they are what make collaboration at scale possible. They help turn enthusiasm into structure, and structure into delivery.
The Drupal AI Initiative has become the largest multi-company collaboration in Drupal community history.
- Dries Buytaert
The initiative is now actively funding critical roles across multiple organizations, including product management, innovation management, technical leadership, and program management. This marks a major milestone: the Drupal AI Initiative has become the largest multi-company collaboration in Drupal community history.
The 2026 roadmap was finalised earlier this year, informed by customer demand and industry insight. Delivery is actively underway.
At the same time, marketing efforts have been elevated to position Drupal as the leading AI-powered open source CMS globally, supported by ongoing storytelling and visibility through the Drupal AI Initiative blog.
Focused effort on strategically important features, combined with a growing number of partners committing resources and strong community participation, has driven a significant increase in momentum and impact.
The tag clouds below visually represent the many Drupal community members who in the past 12 months have contributed to the AI Initiative (sized according to number of fixed issues worked on). Includes code and non code contributions.
The following organizations have also contributed to the Drupal AI Initiative in the past year.
From small beginnings with Paul Johnson and Frederik Wouters taking on marketing, we now have a cross disciplinary high performing team with 10 leads across areas of specialization.
Focussing on introducing Drupal to new audiences the emphasis has been on webinars, participating in external events and organising major new customer facing events of our own. These include Drupal AI Summit Paris and New York City (14th May 2026), The AI Summit London (10-11 June 2026) and the latest Enterprise AI Summit Rotterdam (28 September 2026).
Our work has included facilitating Southwark Council, London, winning Digital Leaders AI Impact Award 2026, producing video case studies and highlighting major new AI features announced during the DriesNote with social video content. All these activities have substantially raised Drupal’s profile to a wider audience.
The next major milestone is already taking shape.
In Rotterdam, the initiative will launch an exclusive Drupal Enterprise AI event, available only to Drupal AI Initiative partners. The event will bring together European decision-makers aboard the SS Rotterdam for peer networking, customer case studies, and strategic conversations about building AI-powered content management solutions with Drupal.
Participation in this event is limited to partners who join the Drupal AI Initiative by June 30.
That creates a powerful moment for companies that want to be part of Drupal’s AI future. The initiative is scaling, the roadmap is active, the team is growing, and the opportunity to help shape what comes next is open now.
A strong foundation for what comes next
The Drupal AI Initiative is in a strong position.
With $380,000 in cash and $1.5 million in in-kind contributions, more than 50 contributors from partners, the initiative has the resources and commitment needed to continue scaling. The plan is to onboard an additional 12 partners by Rotterdam, further strengthening the team and accelerating delivery.
The message is clear: You counted on Drupal AI, and we delivered. Now we want to create more efficiency and scale.
That is what this next phase is about. More delivery. More visibility. More impact.
This milestone belongs to many people.
It belongs to everyone who joined those early conversations in Leuven.
It belongs to Frederik Wouters, who brought the right people together at the right moment and helped create the spark that started it all.
It belongs to the five companies that kickstarted the initiative: Dropsolid, Acquia, 1xINTERNET, FreelyGive, and Salsa Digital.
It belongs to every partner, contributor, sponsor, strategist, developer, product thinker, marketer, and community member who has helped move this initiative forward.
And it belongs to the wider Drupal community, whose openness and willingness to collaborate make initiatives like this possible.
The Drupal AI Initiative is growing, and companies can still become part of it.
If your organization believes in the future of Drupal, if you want to help shape responsible AI in open source, or if you want to be part of the group building the next generation of AI-powered content management, now is the time to join.
Become part of the 34 makers already helping to build Drupal’s AI future.
To join the Drupal AI Initiative as an organization and become a partner, contact Dominique at dominique@dropsolid.com.
From Leuven to Athens, this has been an incredible first year.
And the best part? We are only just getting started!
Original article posted by Christoph Breidert on 1xINTERNET website
Over a decade ago, I co-founded 1xINTERNET on the conviction that Drupal was the best platform for ambitious web applications. That bet paid off. But recently, as AI began disrupting our industry, I found myself facing an unfamiliar feeling: uncertainty. For the first time in my career, the path forward wasn't entirely clear.
If you are a decision-maker navigating this shift, you likely feel the same way. We are all trying to figure out how to leverage AI's huge potential without compromising enterprise security, compliance, or content quality.
The good news is that while the broader AI landscape remains turbulent, the direction for content management systems is becoming clear.
- Christoph Breidert
Christoph Breidert facilitating a Drupal AI workshop at DrupalCon Chicago 2026.
When the Drupal AI Initiative was founded in June 2025 by 1xINTERNET, Acquia, DropSolid, FreelyGive, and Salsa Digital, our mission was to chart that exact path. Today, alongside Niels Aers, my role is to manage the AI product direction so that organizations can confidently bring AI into production.
Since the founding, over 30 leading companies have joined the initiative. But a defining moment happened recently at DrupalCon Chicago 2026. During his keynote - the "Driesnote" - Drupal founder Dries Buytaert bluntly asked the community regarding the AI shift: Are you in or are you out?
The undeniable energy from the community and the rapidly intensifying momentum proved one thing: Drupal is all in on AI.
But what does "all in" actually mean? We aren't just talking about adding superficial features like chatbots or simple text generators. We have built a powerful agentic infrastructure natively into Drupal. This provides us with a robust foundation, allowing organizations to build complex AI applications and deploy autonomous agents capable of executing multi-step workflows on their behalf.
Let’s be clear: Agentic AI delivers incredible velocity, and every organization from SMEs to global enterprises needs that speed. But deploying autonomous agents without control is a liability. You need AI infrastructure that accelerates your workflows while ensuring that this speed doesn't destroy your content quality or violate your compliance rules.
This requires a robust governance foundation to run the infrastructure safely. The Drupal AI Initiative has spent the past months building exactly that. These are the final pieces we have built to complete the production-ready foundation:
Let’s separate the hype from reality: The core foundation of Drupal AI is production-ready today. With a secure governance infrastructure now in place, we are shifting from building the engine to delivering the applications. We are shipping out-of-the-box features so organizations can immediately benefit without building complex workflows from scratch.
The first major capability rolling out is AI Content Reviews. This is not a future roadmap concept, it is a real, tangible feature designed to close the quality gap for large websites by acting as a continuous, background quality assurance partner.
It provides scalable, AI-assisted content governance that integrates naturally into how editors already work. The system evaluates content against your organization's specific rules, such as brand voice, legal compliance, SEO, and accessibility. It flags issues, explains them in plain language, and proposes concrete fixes. Crucially, human oversight remains the starting point: an editor simply reviews the flagged issues and can apply the suggested fixes with a single click.
AI Review Management Overview
AI Content Reviews is just the first application of our agentic infrastructure. Following close behind is AI-powered semantic search with synthesized summaries. This allows visitors to find what they need through meaning rather than keywords, enabling the site to surface direct answers instead of just a list of results.
We are also actively packaging AI assistants embedded natively across editorial workflows, site-building, and end-user interfaces. These capabilities have been thoroughly explored and validated in our innovation workstream and are now being readied for production use.
Want to see the full picture of what we are building? You can explore the complete Drupal AI Roadmap to see exactly where the initiative is heading next.
Overview Drupal AI Roadmap 2026.
Why build this directly into Drupal instead of relying on external AI services or other CMS platforms? It comes down to a fundamental technological advantage. Many modern CMS platforms, especially closed SaaS products and pure headless systems, force you to rely on disconnected external API wrappers to communicate with AI. This architectural limitation means your developers have to manually rebuild your existing user permissions, workflows, and access rules in a separate middleware layer just to keep the AI secure.
Drupal AI has a distinct head start because of its deep internal architecture:
The uncertainty of the AI era remains, no one knows exactly what the landscape will look like in three years. I'm being honest about that. But what I do know is that the architecture we are building is solid, the foundation is ready, the community driving it is fully committed and has the resources.
If you are evaluating whether Drupal is the right foundation for AI-powered content management, you don't have to figure that out alone. The Drupal AI Partners network brings together specialized agencies with deep experience deploying exactly these capabilities. If you are ready to move from evaluation to implementation, that is the right place to start.
We are all building in conditions none of us have navigated before.
The difference is what we are building on.
Site templates are available through two distinct pathways, each serving different needs within the community.
The official Drupal.org Marketplace provides a curated collection of site templates that meet certain quality standards, and are built on top of Drupal CMS as a foundation.
Community templates offer an alternative pathway for innovation and experimentation without the constraints of the curation process, by publishing the template as a general project on Drupal.org.
The Drupal.org Marketplace are built on top of Drupal CMS, and curated to provide new users with confidence that they're starting with a consistent, solid and professionally built foundation that follows established best practices.
Templates undergo a review processes
Must follow Drupal CMS best practices for security, accessibility (WCAG 2.2 AA), performance, and code quality
In the beginning, focus is solely on growing Drupal CMS adoption; site templates accelerate adoption of Drupal CMS by providing context relevant demo content and Drupal Canvas-compatible theme
Clear documentation, maintenance commitments, and user support expectations
Currently open to Drupal Certified Partners (for organizations) and Ripplemakers (for individuals or very small companies). Apply to become a creator here.
Consistency for users who need reliable, production-ready starting points
Quality assurance through professional review processes
Support and maintenance commitments for long-term sustainability
Revenue opportunities for professional template creators
Sustainability for the Drupal Association through revenue sharing
Anyone interested in contributing a template can do so now, by publishing it as a general project on Drupal.org. All free site templates, including marketplace templates, are general projects for packaging and distribution purposes. Community site templates will be considered for inclusion in the Drupal.org Marketplace based on their compatibility with the outlined criteria.
Can be published without formal review or approval
Not bound by the same standards as Marketplace templates
Can be built using Drupal CMS or Drupal Core
Available to all community members
Can take risks and explore directions that might not fit Marketplace criteria
Innovation by removing barriers to experimentation
Diversity of approaches and implementations
Learning opportunities for the community to explore what's possible
Stepping stones that might eventually evolve into Marketplace templates
Lower barriers to entry for community contribution
Written by members of the DrupalCon Chicago Steering Committee.
Contributors: Stephen Mustgrave, Avi Schwab, Nikki Flores, and Rosie Gladden.
DrupalCon Chicago 2026 brought together leading experts in digital experience development, open source innovation, and enterprise technology.
The event provided a unique opportunity to connect with decision-makers, technical leaders, and innovators shaping the future of digital experiences. More than 1,300 tech leaders, CEOs, developers, marketing executives, agencies, and enterprise decision-makers gathered to help define the future of the Open Web.
Participants from 26 separate countries brought with them an estimated 15+ languages, reflecting the rich linguistic and cultural diversity of the Drupal ecosystem. The United States (82.4%), Canada (6%), India (2%), Germany (1.2%) and Costa Rica (1.1%) were topping the list in terms of attendee numbers, with Brazil (1%), Colombia (0.8%) and the United Kingdom (0.8%) close behind.
This global span not only highlights Drupal’s widespread adoption, but also underscores the strength of a community shaped by varied perspectives, experiences, and ideas from around the world. Next year we’d love to add more blue!
A total of 1,316 participants attended in Chicago, an increase from 1,288 for Atlanta 2025. Of these we saw 394 first-time attendees, marking a 10.67% increase from those new to the event in 2025.
539 of 1,316 also chose to extend their learning at the Summits & Trainings, with the AI Summit seeing the largest turnout in its first year, with 104 attendees joining to learn about the latest insights connected to Drupal AI.
Outside of the main conference, and following the successful Drupal in a Day organized ahead of DrupalCon Vienna by Hilmar Kári Hallbjörnsson, DrupalCon Chicago saw the North America inaugural program take place alongside the contribution day.
The training session, organized and staffed by ten volunteers, welcomed 55 learners of high school and college age to interact with Drupal CMS for the first time, helping to expand the reach of the community to new users of all ages. We thank the mentors and supporters who made this event a welcoming place for students, and particularly thank all the individual donors who made this happen, as well as Acquia for sponsoring, and Martin Anderson-Clutz and Jordan Thompson for instructing.
Building on the momentum of 2025, the local community ticket-sharing initiative (1 complimentary ticket for every 5th sold through participating organizations) resulted in an increase of 77.5% of ticket purchases which were affiliated with a local group at registration. This initiative continued to grow in both reach and impact, what began as a strong show of grassroots participation has evolved into a more connected and collaborative global network of local camps and meetups celebrating together at DrupalCon.
Participation has expanded beyond the initial groups, with 61 communities engaging through shared resources, cross-promotion, and increased visibility at the 2026 conference. This growth reflects not just higher numbers, but a deeper alignment across the community, where local leaders feel empowered, recognized, and increasingly integrated into the broader Drupal ecosystem.
DrupalCon Chicago 2026 showcased a well-balanced and highly skilled community, with attendees representing every stage of the Drupal journey. Experienced professionals made up the majority, including 348 advanced practitioners (32%) and 301 self-identified Drupal experts (27.7%), creating a strong foundation for in-depth technical exchange and innovation.
Intermediate attendees accounted for 297 participants (27.3%), playing a key role in connecting emerging talent with seasoned leaders. At the same time, the event remained welcoming to newcomers, with 117 beginners (10.8%) and 25 individuals completely new to Drupal (2.3%) joining the community.
The Drupal Association formerly required sponsors, who provided programming support for community interest luncheons. These were folded into general programming this year, and we’d like to acknowledge that not all programs had an assigned, designated host. In the next year, our focus is on strengthening local, regional, topical, and community interest groups, so please reach out to us on how to get connected.
| Breakfast & Luncheons | Registered |
| Black in Drupal Luncheon | 68 |
| Ripple Makers Breakfast | 200 |
| Women in Drupal Luncheon | 200 |
| Total | 468 |
DrupalCon Orlando will see vision meet execution. Whether you're architecting enterprise platforms, launching your next big project, or scaling what you've already built in Drupal, this is the event that meets you where you are and pushes you further.
We're excited to announce updates to the Drupal CMS leadership team, with the addition of Bálint Kléri as our new Frontend Lead.
Bálint Kléri has been named Frontend Lead, a new leadership role created to oversee the frontend architecture for Drupal CMS, Mercury and Mercury-based themes. Bálint is a full-time contributor to Drupal Canvas, leading the development of Code Components for Acquia and a key contributor to Mercury, the Drupal CMS design system.
During development of Mercury, Bálint stepped in to guide the Tailwind CSS implementation and advocate for the use of best practices. We are grateful for his contributions already, and are excited to have him formally join the team. The addition of this frontend role is critical as we refine the Drupal CMS design system, providing users with a modern and adaptable foundation for Drupal sites and site templates.
Pamela Barone is now Drupal CMS Product Lead, overseeing product direction, roadmap, prioritization, and delivery. Serving as Product Owner previously, this shift recognizes the product management responsibilities that Pamela has taken on during the evolution of Drupal CMS.
She will continue to work closely with me as I lead the Drupal CMS initiative. I’ll continue to set direction, align teams, and ensure we have the support and momentum to achieve our goals.
We appreciate the ongoing support from Technocrat support in giving Pamela the time to contribute to Drupal CMS.
Tim Plunkett is transitioning out of his role as Drupal CMS Technical Lead to dedicate his full focus to the development of Drupal Canvas. We thank Tim for his leadership and his employer Acquia for all of his contributions.
Adam Hoenich, Lead Architect for Drupal CMS, has been ably overseeing all things technical in the meantime and he will remain in that role. Adam's contribution to Drupal CMS is generously supported by Acquia.
During DrupalCon Chicago, our leadership team met to discuss the future of Drupal CMS. The first question we asked was 'Do we still think this initiative is important for Drupal's future?' We think it is. We're proud of what we have delivered so far in version 2, with Canvas enablement and site templates as the highlights, but we know there is a lot more to do to meet our objective: To enable marketing teams to launch fully-branded, professional websites in hours, not weeks.
The leadership team is currently working to define the product roadmap for the next 6-12 months, with a strategic focus on launching sites faster with Drupal. We'd love to see new site templates in the marketplace and want to promote easier pathways from installation to going live with a range of hosting options. Other areas we are looking to pursue are: onboarding, better AI tooling, multilingual support for Canvas and site templates, and better support for common third-party integrations.