Drupal feeds

Tag1 Insights: Using AI to Move a 10-Year-Old Drupal Core Issue Forward

Drupal Planet -

Take Away

At Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Charles Tanton (Software Engineer) explores how AI supported his improvements to the Optional Field Widget Ordering issue in Drupal core by accelerating progress on a long-stalled 10-year old problem.

Project Summary

This project focused on using AI to help resolve a long-standing Drupal core issue: Allow multiple field widgets to not use tabledrag (#2264739). The goal was simple but impactful: make it possible to disable drag-and-drop ordering for specific multi-value field widgets, instead of forcing all of them to be orderable. For years, the only practical option was a brittle patch that touched many core files and often broke on core updates, creating recurring maintenance work that nobody enjoyed. By pushing this core fix forward with AI as a coding partner, the aim is to remove that maintenance burden for good and give site builders more control over the form UX.

The Challenge

The core problem was that Drupal automatically renders multi-value fields in a table with tabledrag behavior, even when reordering is not needed. That table-based structure makes theming harder, complicates responsive layouts, and adds JavaScript overhead for no real benefit in many use cases. Our only workaround was a large, fragile patch from this very issue that had to be kept in sync across Drupal core releases by hand.

This AI Applied project set out to change that by getting a clean, configurable solution into core. The work included writing an improved merge request, updating the issue summary, and adding thorough test coverage, all geared toward making the change easy to understand, review, and eventually commit.

The Technical Overview

The first step was using AI to explore alternatives to the existing proposed fix and to see if there was a better architectural direction. After looking at the options together with AI, we confirmed that the original "orderable" setting approach was still the best fit, and then focused on strengthening it, especially around configuration schema. A key enhancement was the introduction of a shared field.widget.settings.base config schema so widgets could inherit the new orderable boolean cleanly instead of each re-defining it.

Across the project, AI helped with:

  • Drafting a clearer, more complete issue summary that explains the problem, motivation, and proposed resolution.
  • Building out comprehensive test coverage for affected multi-value widgets so regressions are caught automatically.
  • Updating Twig templates and styling for the new non-orderable rendering path, including a simplified field-multiple-value-without-order-form template.
  • Getting unstuck on Git and GitLab workflows specific to Drupal core contributions, including issue forks and merge requests.

AI also sped up UI work by letting me paste screenshots into the coding environment so it could adjust CSS more accurately, instead of iterating blindly. Here’s an example:

Figure 1: Screenshot with instructions uploaded to Claude to speed up UI work

Figure 2: The new UI provided by Claude

Over time, I shifted from an earlier extension to a smoother Claude Code setup, supported by installing the ddev-claude-code integration so the assistant could run directly inside the DDEV container with GitLab CLI access.

AI Workflow

A few workflow patterns turned out to be especially helpful on this project:

Dedicated context folder
I added a .claude folder in the repo to hold plans, reference snippets, and docs like the Drupal config schema guide. This let me carry context between sessions and ask the AI to "open and update" specific plan files instead of re-explaining everything.

Plan-driven development
For larger theming or testing tasks, I asked the AI to first write a plan to a file (for example, @.claude/theming-plan-22-nov.md), then execute it step by step, pausing after each item for review. That structure made it much easier to course-correct early rather than cleaning up after a big batch of code.

Voice prompts for speed
Using dictation for prompts in the terminal helped reduce friction for small, repetitive questions or instructions. It was surprisingly effective for "talking through" next steps in a more natural way.

Deep reasoning prompts
Adding a keyword like "ultrathink" in key prompts encouraged the AI to reason more thoroughly before proposing code, which was particularly useful for tricky config and test design work.

On top of that, the ddev-claude-code installation was straightforward and lives right alongside normal Drupal tooling:

composer config extra.drupal-scaffold.allowed-packages --json --merge '["drupal/claude_code"]' composer require --dev drupal/claude_code ddev add-on get FreelyGive/ddev-claude-code ddev restart ddev claude Results and Lessons Learned

The issue is still open, but the state of the work is very different from when this effort began. The implementation now uses a clean configuration schema pattern, has broad widget coverage, and includes extensive tests and documentation in the issue summary. Remaining tasks are mostly about theming and documentation polish before the merge request is ready for final review and potential commit.

This was my first serious use of AI for coding, so it naturally took longer than it would now that I have more experience. The upside is that it gave me a strong foundation for using AI as a regular programming tool, and it has since become part of my daily workflow.

If I were starting this same issue again today, I would:

  • Ask the AI to generate full test coverage first, across all relevant widgets, to surface edge cases earlier.
  • Lean heavily on a "plan mode" flow, approving each step in advance before code is written.
  • Independently run and verify tests instead of trusting automated "all tests passed" claims.
  • Keep prompts short and focused, especially around test generation, to avoid bloated code that is slow to review.
Real-World Applications

Contributions to Drupal core like this one tend to benefit every Drupal site over time. In this case, having an "Orderable" toggle for multi-value widgets will simplify maintenance by removing the need for a large, fragile patch and will improve form UX options for site builders. It's the kind of change that quietly pays off for years through cleaner upgrades and more flexible theming.

More broadly, this project is a concrete example of how teams can use AI to move long-standing open-source issues forward. It is especially valuable where the work involves a mix of architecture decisions, broad test coverage, and tedious but important updates across multiple components.

Expert Oversight Is Non-Negotiable

One of the most important lessons from this project is that expert oversight is essential. I saw multiple cases where the AI made questionable choices or leaned on weak assumptions in the code, which I only caught because I was reading closely and testing manually. Without that attention, the "help" would have turned into extra rework later.

Used well, AI acts as a powerful accelerator: it drafts, refactors, and suggests, while you stay accountable for direction, quality, and correctness. This project helped me build that mindset and gave me the confidence to make AI a normal part of my engineering toolkit. It also reaffirmed how valuable it is to practice with AI on internal or infrastructure-oriented work like this before applying it in higher-risk contexts.

This post is part of Tag1’s AI Applied series, where we share how we're using AI inside our own work before bringing it to clients. Our goal is to be transparent about what works, what doesn’t, and what we are still figuring out, so that together, we can build a more practical, responsible path for AI adoption.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

Image by FranFrank96 from Shutterstock

Très Bien Blog: The Algorithmic Bias Against Drupal Community Values

Drupal Planet -

The Algorithmic Bias Against Drupal Community Values

I don't usually fail at making my life easier, but hey, it's a whole new world lately. To try my hand at LLM during my trial of AI-assisted coding, I wanted to see if I could customize an LLM for a specific task: assigning user credit on Drupal Core issues. Depending on the complexity, activity, and number of contributors involved it can take me anywhere between 30 seconds and 30 minutes to assign credit when I commit an issue to Drupal Core. Maybe I could automate some of it?

theodore February 4, 2026

Centarro: Any Drupal Commerce Site Can Have a B2B Portal

Drupal Planet -

Drupal Commerce lets you serve both retail customers and business buyers from a single installation. Same products. Shared checkout flow. Same user experience—just adapted to the relationship. Different users can see different prices, payment options, and catalogs.

You don’t need a separate platform. You don’t need a different domain. You don’t need another way to manage content. Drupal Commerce already has the tools to support both B2C and B2B on the same website, using the same codebase, delivering a unified experience to all of your customers.

Even better, you can build a B2B portal in Drupal without any code. The capabilities are already there in existing features and modules.

On February 26th, I’ll show you how to do it. We’ll walk through building a B2B purchasing portal using Commerce Kickstart as a base. Sign up now.

Read more

Gbyte blog: Mail Composer: Sending multilingual HTML emails with Drupal

Drupal Planet -

A new solution to Drupal's messy mailing approach

Drupal core's mail module has been a mess for a long time and has seemingly not kept up with the modernization of the rest of the stack. Using the hook system to send emails feels archaic; therefore, a while ago, we started developing a module that:

  • Allows for defining emails in code via a clean and powerful (chaining) object-oriented interface
  • Supports sending HTML emails without any fuss
  • Optionally allows for defining (HTML) emails as Twig templates
  • Allows for translating said emails by simply adding more Twig templates in different languages (multilingual capabilities)
  • Integrates with Drupal's default framework for email manipulation, which handles the transporting and formatting of outgoing emails
  • Can be used as the backend for bespoke UI-driven mailing solutions

We have been using and improving Mail Composer and would love for that work to be reused and further built upon.

Let's talk codeJust sending an inline email

... is as simple as:

/** @var \Drupal\mail_composer\Manager $manager */ $manager = \Drupal::service('mail_composer.manager'); $manager ->compose() ->setFrom('foobar@foo.bar') ->setTo('foo@bar.bar') ->setSubject('Test subject') ->setBody(['This is the body of the email.']) ->send();

Neat, isn't it?

Dripyard Premium Drupal Themes: Meridian, the Latest Dripyard Theme

Drupal Planet -

Meet Meridian, the newest Dripyard theme. We’re really excited about this release, as many hours went into Meridian along with updates to our other themes.

Flexibility

My favorite “feature” of Dripyard themes is flexibility. We market each theme toward a specific vertical, but in practice they are highly versatile. You can easily change the look and feel of an entire site by adjusting color schemes, border radiuses, and imagery.

Pictures are worth a thousand words, so we built our site to showcase multiple demos.

Drupal blog: Inside Drupal CMS 2.0: Q&A with Product Owner Pam Barone

Drupal Planet -

Drupal CMS 2.0 launched January 28. We asked Pam Barone—CTO of Technocrat and Product Owner of Drupal CMS—to talk about what's new and what she's most excited for people to try.

What makes Drupal CMS 2.0 different from version 1.0?

Drupal CMS 1.0 was really a proof of concept, to show that we could create a version of Drupal that bundled all of the best practices that many sites were using, and that the community would come together to make it happen in a short amount of time. We did prove the concept, but the 1.0 release did not represent any major innovations, because we were mostly just packaging functionality and tools that we already had and were familiar with. That is not to downplay the accomplishment at all, because it was a huge leap forward for the project, and it provided the foundation for the next steps.

With 2.0, we are introducing two big new concepts: Drupal Canvas and site templates. These represent another huge leap for the project, each in different ways, as we continue with the strategy to empower marketers to create exceptional digital experiences without relying on developers.

What are you personally most excited about for people to try in 2.0?

Drupal Canvas! I am so excited about Canvas and can’t wait to get it into the hands of our end users. There were times during the development of 2.0 when I was working in the Canvas editor and I thought, ‘Wow, I’m actually having fun!’ I can’t say I remember thinking that with previous Drupal page building tools.

And it’s not just about end users; one of the goals of 2.0 is to introduce Canvas within the community and showcase its potential. It’s a paradigm shift, and this level of change is always challenging, but after trying it out and getting familiar with the concepts, I think it’ll be clear that it’s worth it.

Site templates are a big part of this release. Can you explain what they are and why they matter?

Site templates are near-feature-complete starting points for Drupal sites based on specific use cases. They provide a content model, some example content, a polished look and feel, as well as the functionality you would expect based on the use case. The first site template – Byte, which is included in Drupal CMS 2.0 – is for a SaaS-based product marketing site. It includes all of the baseline functionality from 1.0, plus Canvas-powered landing pages, a blog, a newsletter signup and contact form, and a new theme with a dark style. 

During the development of 1.0, we realized that we couldn’t build something that was both generic and useful. Either we would have to build something simple that would be widely applicable, or we would be making a lot of assumptions about the site’s content model and functionality, and providing things that many users wouldn't want.

We decided that in order to really make it easy to launch sites, we had to provide many different starting points, across many use cases. By identifying the use case and being opinionated about how to solve it, site templates can start you off with 95 percent of what you need to launch.

Of course, that assumes there is a site template for your use case – which means we’re going to need a lot of them. We’re currently working with a group of Drupal agencies who have signed up for a pilot to develop new site templates for the launch of the site template Marketplace.

Let's talk about Canvas—how will this change the way marketers can build with Drupal?

The most obvious thing is just that it provides marketers with a modern, intuitive visual page builder of the kind that any competitive platform needs to have. Up until now, adopting Drupal meant getting its many benefits but compromising on the user experience, because the page building tools were clunky. With Canvas, that compromise is gone. We can provide the experience that marketers have come to expect.

In some ways it feels like we are playing catch-up, especially since it’s still early (the first release was in December) and there are some big gaps. But it also feels like a new era for Drupal, and the enthusiasm and pace of adoption so far is really encouraging. So I think we don’t really even know yet what changes will come, because when the community is presented with a new way to build cool things, the possibilities are endless.

You've mentioned making integrations easier with recipes. What does that look like in practice?

One of the benefits of using Drupal is that it can be integrated with pretty much anything, and all of the common integrations have modules to make it easier. But they always require some configuration, and it can be tricky to figure out. With recipes, we can add default configuration, and we can prompt for the necessary details, so you don’t have to go hunting around for where to add them.

Drupal CMS 1.0 included two integrations that use the recipe prompt already, for Google Analytics and the AI Assistant. They’re pretty simple in that you are just adding an ID or an API key, but they still are a big improvement over the manual setup. 

For 2.0, with site templates, we have the opportunity to include additional integrations that are relevant to the use case and wanted to tackle something a bit more complicated. Byte ships with a newsletter signup that uses a webform out of the box, and has an optional “Recommended add-on” to integrate with Mailchimp. The Mailchimp module already did most of the heavy lifting, but we worked with the maintainers to develop a recipe that configures the module (and its submodules), and once you authenticate your site with Mailchimp, will automatically create signup blocks for each of your audiences. From there, you can add them to any page via the Canvas editor.

We think that easy integrations are going to be really critical to making site templates attractive as an offering, so we are planning to continue working on that. 

In your recent presentations, you've talked about "making easy things less hard" versus "making easy things easy." Where does 2.0 fall on that spectrum?

The initial site templates are very intentionally on the “making easy things less hard” side. Not only is it a totally new concept, but they are leveraging Canvas, which is also new. So we thought that the best chance for success would be to keep it simple and try to really nail the use cases. Once we’ve all built a few, and we’ve gotten feedback from real users, we can move into the more complex sites where Drupal thrives.

Drupal CMS 2.0 is available now.

Try it now: drupal.org/drupal-cms/trial 

Download: drupal.org/download

Learn more: drupal.org/drupal-cms

Twenty-five years in. Still building.

Pages

Subscribe to www.hazelbecker.com aggregator - Drupal feeds