Drupal Planet
The Drop Times: DrevOps Releases Vortex 1.38.0 “Prism” with Testing, Mail Controls, and Security Hardening
Specbee: How bad tracking affects your data (and what can Google Tag Manager fix)?
amazee.io: Drupal Dev Days Athens 2026: Vibe Coding, Ancient Hospitality, and the Future of Drupal
DDEV Blog: From a Single Chat to a Live Sponsorship Feed: DDEV's Sponsorship Data Story
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.
The ChallengeDDEV'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.
The sponsorship-data RepositoryAnoop'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's Web ComponentMark 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.
Integration into DDEV Web PropertiesWith 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:
- ddev.com SponsorsBanner.astro
- addons.ddev.com sponsors-banner.html
- docs.ddev.com sponsors-banner.html
Now, when sponsors join or leave, the banner updates automatically. No manual edits, no stale lists.
What 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.
Why This MattersThe 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.
Thanks to Anoop, The Drop Times, and Mark ConroyMore 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!
Join inIf 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!
Community Working Group posts: Before the Incident Report: How We Are Collaborative
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?
Consulting our Code of ConductI 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:
- The Conflict Resolution Team handles incidents after they happen. If you file an incident report, they’re the ones who review it.
- The Community Health Team works on everything that happens before an incident report, such as workshops, resources, and other preventive work. Our goal is to help the community build the kind of culture where fewer situations reach the reporting stage in the first place.
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.
The middle ground of community healthIf 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.
Some ways we work things outHere 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.
- Late at night at a DrupalCon, after hours of sprinting and drinks in the hotel lobby, someone says something about another contributor that turns a few heads. That person might realize it the next day. The generous move, the one the Code asks for, is to find that person and say “I said something last night I want to walk back.” Not a grand apology. Just a small, honest correction. Most of the time, that’s the whole fix.
- Someone drops a comment in an issue queue without reading the full thread above. Their comment reads as dismissive of work that’s already been done, or repeats a point that was already addressed, and it comes off as rude. They might not know that’s how it came across. A direct message from someone in the thread (“hey, I think you may have missed a few comments, here’s where we landed”) can turn that into nothing. A pile-on in the issue turns it into something else.
- You witness an exchange between two people at DrupalCon that makes you wince. Maybe it’s cultural. The Drupal community spans continents, and directness that comes across as rude in one country seems normal in another. Maybe it’s a power dynamic, or a bad day, or both. Checking in with the person on the receiving end, just between the two of you (“I could not help but notice your conversation and I wanted to ask, are you doing okay?”), doesn’t escalate anything. It lets them know they weren’t invisible.
- Someone keeps doing something that just doesn’t feel right. Not harmful, but grating. You can do your best to describe how it made you feel before it becomes a grudge you carry into every future interaction. “Hey, can I mention something? The way we’re doing X did not sit well with me, and I want to figure out how to talk about it.”
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.
When it isn’t practicalThe 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.
The three-pillar framingReturning 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.
File attachments: pillars-of-drupal.pngTalking Drupal: Talking Drupal #551 - Drupal Recording Initiative
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
Topics- Module of the Week TFA
- Why Recording Matters
- Early Events and Growing Pains
- Post Production and Gear Limits
- Recording DrupalCon vs Camps
- Costs and Value Breakdown
- Pittsburgh Turning Point
- Hubs and Mentoring New Recordists
- Beyond Drupal Events
- Hands Off Goals
- Impact and Adoption
- Workflow Pain Points
- Content First Recording
- Maintainers and Volunteers
- Volunteer Stress Factors
- Funding and Platforms
- Drupal TV Origins
- Roadmap and Growth
- Wrap Up and Contacts
MOTW - 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.
UI Suite Initiative website: Video series - #03 Display Builder for Drupal: Entity View Display Explained
The Drop Times: Who Will Inherit the Code?
Dear 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.
- Drupal GitLab Issue Migration Update Details Contributor Workflow Changes
- Dries Buytaert Explains Why Strict APIs Matter for AI Development
- Drupal.org Updates Maintainer Role Sync With GitLab to Two-Way Mapping
- Drupal AI Initiative Update Details Growth, Architecture, and 2026 Roadmap
- Drupal 11.3.6 Regression Linked to Potential Data Loss During Config Imports
- Mautic API Library 4.0.0 Released With Modern HTTP Support and New Features
- LocalGov Drupal Community Advances Committee Management Proposal with Project Quorum
- BinaryWorks Schedules Drupal Webinar on AI Search and Personalization
- Webhaven Adds Drupal Canvas Support and Launches Demo Site
- For Community, By Community: Stanford WebCamp 2026 Opens Today
- Frederik Wouters Keynote Frames AI as Response to Drupal Decline
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
Sitback Solutions: Helping NSW households and businesses unlock energy savings
Drupal AI Initiative: Drupal AI Learners Club Is Here. And You're Invited.
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.
Where it startedAngie 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.
Just show upThe 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.
Aten Design Group: Introducing Entity Webhook: Config-Driven Webhook Integration for Drupal
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.
What Is Entity Webhook?Entity Webhook gives Drupal a complete webhook toolkit built around three capabilities:
- Inbound (core module): Receive JSON payloads from external services and automatically create or update Drupal entities
- Outbound (entity_webhook_broadcast submodule): Notify external systems when Drupal entities are created, updated, or deleted
- Polling (entity_webhook_polling submodule): Actively fetch data from external APIs on a schedule, as a fallback for systems that don't push webhooks
The key design decision: all three are driven by the admin UI. No custom module code is required to get a working integration.
Receiving Webhooks and Upserting EntitiesThe 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.
Flexible Field ExtractionField 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.
Deduplication and UpdatesTo 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.
Verification Built InThree 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.
Developer ExtensibilityWhen 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.
Broadcasting Outbound WebhooksThe 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.
Polling for APIs That Don't PushNot 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.
How It Compares to Other Webhook ModulesThere 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.
Featureentity_webhookwebhookswebhook_receiversymfony_webhook_receiverInbound webhooks✓✓✓✓Entity upsert — config-driven, no code✓———Field mapping UI✓———Outbound broadcastingSubmodule✓——PollingSubmodule———HMAC verification✓✓Token-in-URL onlySymfony-nativeAPI 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.
Getting Startedcomposer require drupal/entity_webhook drush en entity_webhook # Enable submodules as needed: drush en entity_webhook_broadcast entity_webhook_pollingThen navigate to Administration > Configuration > Services > Entity Webhook to create your first endpoint. Full documentation is on the project page.
Let's Build SomethingIf 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.
Read This Next Joel SteidlThe Drop Times: LocalGov Drupal Community Advances Committee Management Proposal with Project Quorum
The Drop Times: For Community, By Community: Stanford WebCamp 2026 Opens Today
DDEV Blog: DDEV April 2026: Talking Drupal, Ubuntu 26.04, coder.ddev.com, Intel Macs fade away, Add-ons as delivery mechanism
- Ubuntu 26.04 and Fedora 44 were released this week. We checked, and we're proud to say that DDEV works great on both. We have one small docs change for the Ubuntu 26.04 native install. The Windows Installer did fail with an Ubuntu 26.04 distro because the wslu package has been removed, but we fixed that in PR, and it has an easy workaround anyway.
- coder.ddev.com Updates → More work is ongoing with Coder.ddev.com, we're hoping to make it fulfil even more of your ambitions. 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.
- Intel Macs have run their course → We'll be retiring our three macOS AMD64 test runners. There's not much more for them to do, so we're going to turn them off. Only 7.3% of you are still using Intel Macs and it's been a very long time since we saw a regression or problem on the Intel test runners that wasn't also caught by the Apple Silicon runners. See the stats.
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↗
DrupalDevDays Athens 2026Community 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!
Community HighlightsA 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.
Contributor TrainingAdd-on Creation and Maintenance Contributor Training: Watch it↗
TYPO3 Update for DDEVThe TYPO3 community published a post on what's new in DDEV for TYPO3 developers. Read on TYPO3 News↗
Community Tutorials from Around the Web- Getting Started with Search API in Drupal → WebWash covers how to set up and use the Search API module in Drupal — useful alongside a DDEV local environment. Read on WebWash↗
- DDEV AI Workspace: Full Drupal AI Development Setup → Read on menetray.com↗
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.
Note: Randy on Vacation May 19–June 9Randy will be away May 19 through approximately June 9, on a bike trip in Sicily. The community will carry on!
Sponsorship UpdateSponsorship 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.
Statistical Tidbits of the Month- About 19,000 users report using DDEV each week, live graph.
- SO MANY macOS Docker Providers, live graph.
Compiled and edited with assistance from Claude Code.
Drupal.org blog: Improvements to Drupal.org project maintainers syncing with GitLab project members
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:
- “Write to VCS” on Drupal.org grants the GitLab project developer role.
- Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role.
- “Maintain issues” grants the GitLab project planner role.
- Other Drupal project maintainership roles are not synced.
Syncing is two-way, so that saving maintainers in Drupal will keep choices made in GitLab.
- Maintainer in GitLab grants “Write to VCS” and “Administer maintainers,” matching GitLab’s “Administer maintainers” permission on Drupal.org.
- Developer grants “Write to VCS” and removes “Administer maintainers.”
- Planner grants “Maintain issues” and removes both “Write to VCS” and “Administer maintainers.”
- Reporter and Guest remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”
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
- If they were the project node author on Drupal.org, assign authorship to another person with “Administer maintainers,” or fall back to Unsupported projects.
- Remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”
- Not change access to “Edit project” or “Administer releases.”
- If they have no remaining Drupal.org project maintainership roles, completely remove them as a maintainer.
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.
The Drop Times: DrupalCamp Ottawa 2026 to Highlight Drupal 11, AI Workflows, and Accessibility Practices
Jacob Rockowitz: Drupal (AI) Playground: Using the AI Schema.org JSON-LD module to "feed the machines"
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
The Drop Times: Fast Code, Faster Debt: Why Eduardo Telaya Built Drupal AI
HOOK_DEV_ALTER(): Build a Feature-Rich Frontpage in Drupal: Canvas vs Display Builder (Part 3)
Building 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.