Drupal Planet

Dries Buytaert: AI rewards strict APIs

Every 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.

Magic strings break the loop

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.

A bet made before AI existed

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 was style is now speed

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.

Drupal AI Initiative: Webinar: How Southwark Council is Using AI to Transform PDF Publishing in Drupal

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.

About the webinar

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.

Register for the webinar →

The problem it solves

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.

How it works

Each PDF passes through a three-step pipeline:

  1. Extract - a PDF parser pulls the raw content from the document
  2. Transform - AI converts it to properly structured, accessible HTML with logical pagination
  3. Save - clean HTML pages are ready to review and publish directly in Drupal

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.

Built the right way

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

Why this matters beyond Southwark

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.

Register for the webinar →
 

The Drop Times: Drupal Accessibility Beyond Automation

Accessibility 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.

ORGANIZATION NEWSFREE SOFTWAREDISCOVER DRUPALEVENT

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

Talking Drupal: Talking Drupal #550 - The Future of Site Builders

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

Topics
  • Module of the Week: Password Policy
  • MidCamp 2026 Promo
  • Defining Drupal Site Builders
  • Rod's Training Background
  • Site Builder Role and Skills
  • Comparing Drupal WordPress Joomla
  • Editors vs Site Builders
  • Site Building Changing in Drupal
  • Layout Builder Fallout
  • Canvas and AI Promise
  • Barriers and Bulk Fields
  • Prompt Built Architecture
  • Guardrails and Nuance
  • Playbooks and Context
  • Drupal Must Shift
  • Templates Over CMS
  • Dev and Builder Handoff
  • Two Paths Forward
  • Recipes Upgrade Gotchas
  • Closing and Contacts
Resources

NIST 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

Guests

Rod Martin - DrupalHelps.com imrodmartin

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Avi Schwab- froboy.org froboy

Module of the Week

with 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.

#! code: Drupal 11: Cascading Select Forms With HTMX

Drupal 11: Cascading Select Forms With HTMX

This 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 Sun, 04/26/2026 - 18:58

The Drop Times: DevBranch BootCamp Expands as Entry Pathway for Drupal Talent

DevBranch has developed its in-house Drupal BootCamp into a recurring training pathway aimed at preparing new developers for project work. The programme has run eight cohorts since 2021, training more than 30 participants, with about half receiving job offers. Details shared by Functional Manager Nataliia Khomiuk outline how changes in duration, cohort size, and skill focus reflect practical hiring and onboarding needs within distributed Drupal teams.

Drupal.org blog: GitLab issue migration: a contributor's perspective

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.

What's changed at a glance

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.

What still works the way you're used to

A lot has not changed:

  • You can still create issues without any special role.
  • The contribution credit system is unchanged. Every comment you make on a GitLab issue still syncs to its contribution record automatically. The credit UI itself still lives on drupal.org.
  • Shared issue forks are still the way to collaborate (on code). Drupal still doesn't use personal forks; collaboration on a single fork remains the model. The fork management UI also still lives on drupal.org.
  • The familiar workflow conventions can still apply — Needs work, Needs review, RTBC, priority levels, and so on. They were migrated as scoped labels (more on this below).
  • GitLab CI still runs your tests the same way it has for the past few years.
  • Your Drupal.org login still works. Single sign-on means no extra account to manage.
  • Cross-references and parent/child relationships still exist, just with slightly different syntax (more on that below).
Some things actually got better

It's worth naming a few real wins for contributors:

  • A modern issue editor with proper markdown, real code blocks, syntax highlighting, image paste, and a mobile-friendly UI.
  • Issues and merge requests now live alongside the code, pipelines, and CI logs on git.drupalcode.org — far less context-switching during code review.
  • Much better filtering, search, and saved queries on issue lists.
  • Issue boards (Kanban-style) are available for projects that want them.
Who can edit what

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:

  • Anyone can comment on an issue.
  • Only the original author or project maintainers can edit the issue description. This is a real change — on drupal.org, any logged-in user could edit an issue summary. If you'd like a description updated and you're not the author, leave a comment with the suggested wording so the author or a maintainer can apply it.
  • Labels and other metadata (priority, version, category, component, tags) can only be edited by users with a Planner role or higher on the GitLab project.

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.

Old workflow conventions can still apply

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:

  • Applying these labels yourself currently requires the Planner+ role on the project, until #3559846 ships the contributor label UI. In the meantime, a comment indicating the status you'd assign is the right move.
  • Merge request states are a useful parallel signal: an MR's Draft / Ready toggle and approval status reflect the actual code change being reviewed, which often communicates more clearly than a label on the parent issue. Some projects lean heavily on MR state, some on labels, some use both — there's no single right answer.
Day-to-day: how to do common things Create an issue

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 auto-generated comment

The first comment on every new issue is posted by DrupalBot. It's the bridge to the things that still live on drupal.org:

  • A link to the contribution record (where credit is tracked).
  • A link to the fork management page, where you can create or request access to a shared fork, view existing MRs, and open a new one.
  • Once #3559846 ships, a link to the contributor label management UI.
Forks and merge requests

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.

Linking issues across systems

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:

  • Drupal.org → Drupal.org issue Brackets around the issue number (without spaces): [ #123456 ] (unchanged)
  • GitLab → GitLab issue (same project): #123456 (no brackets)
  • Cross-platform (either direction): paste the full URL

For "related issues" entries on Drupal.org, always use the full URL when pointing at a GitLab issue.

Things you might notice on migrated issues

A few oddities are worth flagging if you're working through historical issues:

  • DrupalBot is listed as the author on every migrated issue. (Issues created after migration correctly show their actual creator.) The GitLab API forced a tradeoff between preserving the original author and preserving the issue ID. We chose to preserve the ID so that #123456 still maps to the same issue. The original author's name is preserved in the first line of the issue description.
  • Old drupal.org issue URLs redirect to their GitLab equivalents, so existing links in commit messages, blog posts, and external references continue to work.
Reporting bugs and getting help

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.

Reference: GitLab documentation

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.

Drupal AI Initiative: From Leuven to Athens: Celebrating One Year Since the Drupal AI Initiative Took Shape

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.

A year of momentum, collaboration, and delivery

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.

What has been delivered?

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. 

Growing numbers of Drupal AI Partners

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.

Delivering capabilities at scale

The initiative also successfully established and executed the delivery management RFP process, putting important operational frameworks in place, including:

  • Partner expectations documentation
  • Onboarding processes
  • Development sprint processes
  • Contribution tracking
  • Team planning sheets
  • Weekly status reporting

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.

Significant rise contribution

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.

Marketing Drupal AI

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.

Building toward Rotterdam

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.

Thank you to the people who made this possible

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.

You can still join

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!
 

File attachments:  54456328639_3949c293a3_k.jpg adoption.png partners.png tagcommunitytop.png tagcommunitybottom.png tagcompanies.png 10team.png events.png rotterdam.png scaling.png

Centarro: How to Know If Your eCommerce Developer is Failing You

A business spends hundreds of thousands of dollars with a developer or agency to build an eCommerce website, endures years of instability and missed deadlines, and then concludes that the platform just doesn’t work. They start eyeing Shopify or whatever choice platform the first consultant they engage recommends, hoping the grass will be greener. Meanwhile, the actual issue—an underqualified or negligent service provider—walks away unexamined.

Developer problems are often disguised as platform problems. We’ve seen this situation many times with Drupal Commerce implementations that aren’t performing as desired. We’ve even solved issues merchants put up with for years in a matter of hours. It’s not that we’re special, though we do know our own platform better than anyone else. We believe any competent Drupal developer would also be able to identify and solve these issues, possibly just as quickly.

So how do you tell the difference? How do you know your issues stem from your developer, and not your platform?

Below, we’ll give you the language and the lens to evaluate whether your developer is actually serving you well, or whether they’re the reason your Drupal Commerce site feels like it's held together with duct tape and bubblegum.

How some developers get in over their heads

A company needs a Drupal website with eCommerce capabilities, so they search for a Drupal developer. Maybe they already have a Drupal website and want to add some commerce features. Either way, they find a freelancer who has built blogs, nonprofit sites, and maybe a university portal with some advanced functionality. That person says, "Sure, I can handle commerce. It’s just another module." For a basic eCommerce website with minimal traffic, maybe they can.

Read more

Freelock Blog: When Views meets Drupal Canvas -- getting dynamic content into your Canvas page

When Views meets Drupal Canvas -- getting dynamic content into your Canvas page John Locke Tue, 04/21/2026 - 08:00

From early days, "views" has been the killer feature of Drupal. Views is a powerful querying tool built into Drupal that allows dynamic lists and displays of content to be created without writing custom code.

Dev Corner

Jacob Rockowitz: Drupal (AI) Playground: Training and practicing building a module using AI

Successes and failures

I am continually experiencing both successes and failures while playing in my Drupal (AI) playground. My failures usually come from expecting too much of an AI, especially when I ask it to do too many things in a single prompt. My successes with AI come when I keep things useful, simple, and achievable.

Building something useful, simple, and achievable with AI

As I've learned about and maintained new ecosystems in Drupal, I like to review all available plugins. For the Webform module, I created reports for elements, handlers, variants, and exporters. For ECA, I developed an ECA Report module. For the Meta Tag module, I contributed a patch to get a Meta Tag plugin report committed. I think having a way to browse a module's or ecosystem's plugins helps developers understand what tools are available. A Drush command for exporting plugin definitions could be used by both humans and AI.

In the past, creating and maintaining a report could be time-consuming. The new reality is that AI makes it easier to build and maintain simple things like reports. One of the most common anecdotes I hear from non-technical people who "vibe code" is that they are building websites or reports to display information.

My goal was to create a report that lists all plugin managers, plugin definitions, and individual plugin details.

There ain’t nothing fancy here

The Plugin Report module I created with AI is nothing special. Claude Code’s only challenge was getting the PHP introspection code to pass PHPStan’s level 6 coding standards. In many ways, this module served as an exercise to reinforce my ability to guide an AI in the right direction. My biggest...Read More

HOOK_DEV_ALTER(): Manage Displays: Canvas vs Display Builder (Part 2)

When building a Drupal site, we want to control how our content looks in different contexts, e.g. the full display for standalone or the card display for overview pages. In Part 2 of this series we compare how Drupal Canvas and Display Builder handle display configuration by building a node display for a blog content type. 

Très Bien Blog: Proposal for an LLM policy for Drupal Core contribution

Proposal for an LLM policy for Drupal Core contribution

I've been following and participating in the conversation about applying AI tools to the Drupal core issue queue, and the broader community. I've been listening, reading, and experimenting quite a bit in and out of Drupal. It's been a wild ride since last December and for the past few weeks a few things started to solidify.

theodore April 21, 2026

Talking Drupal: Talking Drupal #549 - Catching up with the DDEV Team

In Episode 549, Randy Fay and Stas Zhuk join us to discuss what DDEV is, recent improvements, and where it's headed. Module of the week is the DDEV Drupal Contrib add-on. Randy and Stas discuss priorities like reliability, consistent UX, add-ons discoverability, and new features including revamped ddev share with Cloudflare and rootless Podman support. They also cover coder.ddev.com, a cloud-based DDEV environment built on coder.com for easier onboarding and contribution, plus sustainability, community support, and challenges such as AI-driven PR volume and Stas's development constraints in Ukraine.

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

Topics
  • Module of the Week - DDEV Drupal Contrib
  • DDev Drupal Contri Overview
  • Contrib Workflow Q&A
  • Drush in Core Debate
  • Add-on Registry and Contact
  • Drupal AI Summit Plug
  • What Is DDev
  • Stas Origin Story
  • Recent Releases and Priorities
  • DDev Share and Podman
  • Developer Experience Changes
  • Database Upgrade Pain Points
  • Coder DDev Cloud IDE
  • Cloud DDEV Basics
  • VS Code Remote Workflow
  • Pair Programming Training Wins
  • Docker Desktop Alternatives
  • Onboarding Teams Faster
  • Windows Support Reality
  • Building Through War
  • Roadmap Env File Fixes
  • Beyond Drupal Adoption
  • Addons Discovery Tools
  • Funding Community Health
  • AI Pull Requests Pressure
  • AI Agents MCP Plans
  • How To Get Involved
Resources

DDEV - https://ddev.com/ DDEV Add-on Registry - https://addons.ddev.com/ Introducing coder.ddev.com: DDEV in the Cloud - https://ddev.com/blog/coder-ddev-com-announcement/ About Stas Zhuk - https://ddev.com/blog/introducing-maintainer-stas/ Power Through Blackouts: How DDEV Community Helped Me in Ukraine - https://ddev.com/blog/power-through-blackouts-ddev-community-support/ Drush command in core - https://www.drupal.org/project/drupal/issues/3453474 Drush's Final Act - https://weitzman.github.io/blog/drush-final-act coder.com - https://coder.com/ Service hosting coder.ddev.com - https://www.hetzner.com/ Funding DDEV - https://ddev.com/blog/sustainability-for-ddev/ Gen AI DDEV newsletter note - https://ddev.com/blog/ddev-march-2026-newsletter/ Sharing Coder.ddev.com workspaces - https://github.com/ddev/coder-ddev/issues/80

Guests

Stas Zhuk - stasadev Randy Fay - ddev.com rfay

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Rod Martin - DrupalHelps.com imrodmartin

Module of the Week

with Martin Anderson-Clutz - mandclu.com mandclu

DDEV Drupal Contrib - DDEV integration for developing Drupal contrib projects. As a general philosophy, your contributed module/theme is the center of the universe.

Pages