fidzu : Drupal

How should development teams adopt AI without sacrificing code quality or collaboration? In this Talking Drupal Cafe, Stephen Cross is joined by Mike Miles and Jim Birch to discuss practical strategies for integrating AI into Drupal development teams. They explore AI coding assistants, team policies, code review, agent workflows, governance, and real-world lessons from using tools like Claude Code and GitHub Copilot in production environments.

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

Topics

• Why AI Matters Now
• Team Introductions
• From Experiments to Workflows
• Standards and Guardrails
• Skills and Automation Examples
• Taming Verbose AI Code
• Adoption and Tool Choices
• Governance and Training
• Measuring Productivity Gains
• Keeping Up Without FOMO
• AI for Editors and Site Features
• Red Teaming and AI Security

Jim Birch

Jim Birch is Director of Engineering and AI Practice Lead at Kanopi Studios, where he leads engineering teams and oversees the company's responsible adoption of AI. Jim is also a Drupal CMS committer, and Recipes Initiative Coordinator, and is a Google Cloud Certified Generative AI Leader.

Michael Miles

Mike Miles is a technical leader and speaker with more than 20 years of experience in web engineering, open-source development, and digital platform delivery. As the Director of Web Development at MIT Sloan, he leads the team responsible for the development, maintenance, and growth of the school's public digital properties.

Mike regularly speaks at technical conferences on topics including modern web development, Drupal, technical leadership, testing, delivery practices, and practical AI adoption. He is also one of the organizers of New England Drupal Camp.

Stephen Cross

Stephen Cross has been a Drupal developer for over 20 years and founded Talking Drupal in 2013. As founder of Second Signal Media, he combines his passion for open source and media production to share conversations that help the Drupal community learn and grow.

Guests

Michael Miles - mikemiles86

Jim Birch - thejimbirch

Stephen Cross - stephencross

Resources

Courses https://anthropic.skilljar.com/ https://academy.openai.com/pages/courses

Skills https://kanopi.github.io/cms-cultivator/ https://kanopi.github.io/delivery-record/

03 Aug 2026 4:05am GMT

Drupal 11: Migrating From Jadu Into LocalGov Drupal: Part 1

This is the first post in a series of posts looking at migrating content from a Jadu site into a Drupal site running the LocalGov Drupal (LGD) distribution. The site I was migrating content into was the new site for Central Bedfordshire, and whilst other implementations of Jadu may differ from what I describe here, it should be enough information for you to understand the process.

Jadu is a proprietary CMS application that is mostly written in PHP. Back in 2011 I went to a talk by one of the developers from Jadu at the PHPNW11 conference, so I was aware of the system. That talk, by the way, was interesting as they built a system called Phalanger that allowed PHP (and Jadu) to be run on a .NET environment. That project is now called PeachPie and it looks like it is still under active development.

LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites. The functionality provided includes content pages, news pages, bus timetables, and waste collection systems. What's more, it's maintained by a vibrant community of people.

In this article we look at how the Jadu API is used to get hold of site content, and what we can do in Drupal to facilitate the migration of this content. We then look at a simple part of the migration as an introduction to the whole process. This won't be an introduction to the migration API as I will skip over some of the fine details of the API to keep things brief.

First, let's look at the Jadu API.

philipnorton42 Sun, 08/02/2026 - 18:04

02 Aug 2026 5:04pm GMT

Zero to new Drupal site in 133 seconds

John Locke Sat, 08/01/2026 - 15:00

Dev Corner

01 Aug 2026 10:00pm GMT

sku,name,category
1001,Rope leash,Animals > Dogs > Accessories
1002,Dry food 3kg,Animals > Dogs > Food
1003,Dry food 1kg,Animals > Cats > Food

Animals
├── Dogs
│   ├── Accessories
│   └── Food
└── Cats
    └── Food

$parent = 0;

foreach ($names as $name) {
  $terms = $storage->loadByProperties([
    'name' => $name,
    'vid' => $vocabulary,
    'parent' => $parent,
  ]);

  $term = $terms ? reset($terms) : $this->createTerm($name, $vocabulary, $parent);

  // The term just resolved becomes the parent of the next lookup.
  $parent = (int) $term->id();
}

return $parent;

sku,name,categories
1001,Rope leash,"Animals > Dogs > Accessories, Animals > Cats > Toys"

composer require drupal/feeds_tamper_term_hierarchy

01 Aug 2026 6:40pm GMT

Drupal's automation tools solve different problems. The harder question is how they can exchange work without weakening their execution models, permissions, or auditability.

31 Jul 2026 1:51pm GMT

31 Jul 2026 10:03am GMT

Reusable Drupal components become awkward when each placement needs a different presentation. ERFO adds controlled variation without duplicating or altering the referenced content.

31 Jul 2026 5:35am GMT

The Drupal AI module provides everything needed for a RAG chatbot: AI Search embeds your content into a vector database, AI Assistant API wraps an LLM with a grounded search prompt, and AI Chatbot puts a Deep Chat block on the page. We cover setup, provider selection, module stability, troubleshooting tools, and the data flow considerations that government sites need to get right.

31 Jul 2026 4:35am GMT

Custom Formatters is old. I started it in 2009, my first year building seriously for Drupal, and shipped it through Drupal 6 and 7. Then in late 2016, not long after the first Drupal 8 alpha, I stepped away (work, life, the usual reasons) and for the best part of a decade it wasn't mine to ship.

It didn't die, though, and that's almost entirely down to one person. Andrii Podanenko (podarok), backed by ITCare and the Open Y distribution, carried it through the Drupal 8 beta, the Drupal 10 port, and the start of the Drupal 11 line, essentially single-handedly, for years. Huge thanks to Andrii for looking after it all that time. I've picked the 4.1.x line back up alongside him, and 4.1.0 is the first release to come out of that.

Continue reading →

31 Jul 2026 3:30am GMT

Today we are talking about Drupito, its Business model, and Marketplaces with guest Ashraf Abed. We'll also cover Generate (Social Media) Image as our module of the week.

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

Topics

• Meet Drupalito and the Mission
• Platform Layers and Roadmap
• Pricing and New Markets
• Marketplace Success Stories
• Exportability and Vendor Lock In
• Growing the Drupal Ecosystem
• Derivatives and Recurring Revenue
• Rebuilding on Drupedo
• Funding Drupal Association
• Global Community Check In
• Migrating Sites to Drupedo
• Marketplace Vision Shift
• Maintenance and Incentives
• Safe Updates Blue Green
• Testing Mindset for Templates
• Official Marketplace Collaboration
• Agency Revenue and Partnerships
• Niche Derivatives and Pricing
• Launch Plans and Vetting

Resources

• Code that ships

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Ashraf Abed - drupito.com ashrafabed Avi Schwab - froboy.org froboy

MOTW Correspondent

Avi Schwab - froboy.org froboy

• Brief description:
  • Have you ever wanted Drupal to generate dynamic social media images using tokenized node data, similar to the share images on GitHub repos or Reddit threads? There's a module for that
• Module name/project name:
  • Generate (Social Media) Image
• Brief history
  • How old: Created by tfranz of Germany on 22 April 2022
  • Versions available: 1.x-dev, 2.0.0-beta2, published a few weeks ago by our own Martin Anderson-Clutz
• Maintainership
  • Minimally (although now slightly more actively) maintained
  • No Security coverage (yet)
  • Passing GitLab CI tests
  • Well fleshed out README for docs
  • Number of open issues: 8 open issues, 0 of which are bugs against the current branch, but there are lots of feature requests
• Usage stats:
  • 1 site reports using this module
• Module features and usage
  • GSMI requires an image style that uses a "Text Overlay" effect - this comes from the Image Effects module and lets you burn tokenized (or static) text onto an image. Normally, when Drupal generates an image style derivative, there's no entity in scope - it's just processing a file - so a token like [node:title] would resolve to nothing. GSMI's real contribution is the glue: when it builds a derivative for a specific node, it swaps in the node-resolved text before generating the image. That's what makes entity-aware tokens work inside an effect that otherwise only sees global tokens.
  • Once the image style exists, GSMI's settings form lets you pick a source image field on the node - an image field or a media-reference field - plus a fallback image for when that's empty. From there it generates the styled derivative from that source image, for any node of any content type that has the field.
  • Finally, GSMI exposes its own token - [node:generate-style], with optional style/field overrides - so you're not locked into the one global style/field pair configured in the settings form. I used that to drop the generated image into Metatag's og_image field for the Session content type on the MidCamp site, getting us dynamically generated session images..
  • A couple of gotchas we hit setting this up:
  • Text Overlay's layout options have some bugs, and not filling out all of the options will result in an image library error.
  • The bigger one: GSMI names the generated derivative file after the source image's filename - extension included - not after whatever format the image style actually outputs. If you try to convert an image to WebP you might get a WebP image with a JPG extension.
  • BUUUUT - LinkedIn still doesn't support WebP (at least as per their documentation, so it's still in 2026 not safe to use WebP for a universal og:image. https://www.linkedin.com/help/linkedin/answer/a521928

30 Jul 2026 6:00pm GMT

Some WordPress sites reach a point where the content model no longer fits the organization's needs. Custom content types, custom entities, and custom fields become necessary to represent internal data precisely, and Drupal supports all three, shaping that data with full flexibility.

Other sites reach that point because of AI. Drupal has built a strong AI ecosystem over recent years, enabling integrations of every needed type: content creation, accessibility checks, RAGs, among others. These are the two situations behind most WordPress-to-Drupal migrations: an architecture the site has outgrown, or an AI integration WordPress cannot support natively.

The challenge of migrating WordPress content to Drupal

The core challenge in a WordPress-to-Drupal migration is migrating the content itself. WordPress sites may host thousands of pieces of content that need to be moved to the Drupal site.

A full migration project runs through several phases: redesigning the site if needed, building the new architecture, and creating a Drupal node for every WordPress post or page. Creating the content is where the real work concentrates, since every image, every user, and every translation has to make it across, on top of adapting content to a different format defined by the new architecture.

A manual content migration is not viable due to its high costs and risks. Handled by hand, this work is prone to human error. A single error is easy to fix, but a…

30 Jul 2026 6:15am GMT

An AI model does not decide what data it can access, which tools it can use, or whether it can act without approval. People make those decisions at different points. Upstream, a model developer trains and tests the model and decides whether and how to release it. Downstream, a developer builds the model into a system, connects that system to data and tools, and decides whether a person must review its proposed actions before they take effect.

Those choices determine whether harm is possible at all. So when harm occurs, responsibility should fall on those who controlled the relevant choices. That responsibility may be shared: model developers control training and release, product builders control permissions and deployment, and users control deliberate misuse.

Responsibility should follow meaningful control.

That principle is missing from much of the debate over open-weight AI models, which often treats the decision to release a model as the only one that counts.

Axios recently reported that United States officials had considered measures that could restrict American companies from using Chinese open-weight models. Open-weight models make their trained parameters available for others to download, modify, and run on their own infrastructure, without going through the company that built them.

More than 230 companies and organizations have since signed an industry letter defending open weights. After critics accused Anthropic of supporting a ban on open-weight models, Dario Amodei published a statement denying that position. He described open-weight models that do not have dangerous capabilities as a public good and supported mandatory safety testing for sufficiently capable models, open or closed.

The disagreement is less about whether open weights can create risk than about when those risks justify restricting a release, and whether restrictions would improve safety or mainly concentrate power in the largest AI labs.

I am firmly in the open-weights camp. I have run and compared open-weight models, argued that digital sovereignty depends on who controls software, not where it comes from, and believe organizations should control their infrastructure and data instead of depending on a handful of providers.

I also believe consequential algorithms need oversight. More than a decade ago, I argued that we would eventually need something like an FDA for software. The harder question is where responsibility for that oversight should lie.

Open-weight models unbundle control

With hosted, closed-weight models from providers such as Anthropic and OpenAI, the provider typically keeps the weights private, controls how customers access the model, and decides when to update the hosted service.

Open weights can separate those roles. One organization creates and releases the model. A repository such as Hugging Face hosts and distributes the weights. Another team might fine-tune them. A product builder incorporates the model into a product and connects it to data, tools, and users.

Each team controls something different. Because open weights unbundle control, it becomes harder to say who is responsible when harm occurs.

A model developer controls the training process, capability testing, documentation, and release decisions. A repository controls what information it displays about a model's origin, which security checks it performs on uploaded files, and which access restrictions it provides or enforces. A product builder controls what data and tools the resulting system can reach, which actions require human approval, and what gets logged.

Control is not the only thing that matters, but it shows who could still have changed the outcome. When harm involves AI, several actors may bear responsibility for the same incident because each controlled a different opportunity to prevent it.

A lesson from Drupal and Open Source

Like open-weight models, Drupal's code can be copied and changed without asking anyone's permission. A site owner could use it to spread misinformation or operate a fraudulent website. The site owner controls the content and operation of the site and is responsible for those choices. The Drupal project is not responsible merely because someone used its code.

But the Drupal project controls other decisions. When someone privately reports a security vulnerability, the Drupal Security Team follows a coordinated disclosure policy. It keeps the issue private while a fix is prepared. Once a security release is available, the team publishes an advisory and tells site owners to upgrade. The timing of that disclosure can give site owners a fair chance to protect themselves.

The same distinction applies to AI. Responsibility should follow the decisions each actor controls.

The product is where capability receives authority

A model generates outputs. An agent is a software system that uses a model to work toward a goal, often by calling tools and taking actions. The people who build and configure the agent decide what it can access, which actions it can take, and when it needs a person's approval.

In a coding agent such as Claude Code, a model can generate a database command. Whether that command can run depends on the tools and permissions the agent provides, as well as the access allowed by the computer, network, and database.

A content management agent can propose deleting an article. The content management system (CMS) determines whether the agent has permission to delete it, whether the deletion is reversible, and whether the action is recorded.

Permissions, isolation, audit logs, rate limits, human approval, and rollback are not merely engineering details. They determine who has control at the point where harm can still be prevented. That is why AI governance is becoming an essential part of product architecture.

How should government regulate AI?

Deciding who should answer after harm is the easier half of this, even when the answer is not obvious. The harder half is deciding what government should require before any harm has happened.

If control and responsibility are distributed across several actors, government rules should be distributed across them too. This is not a new idea. We already regulate many technologies this way.

More than a decade ago, when I argued for something like an FDA for software, I had drug approval in mind. I no longer think that is the right model. The FDA approves a drug for one or more intended uses, while a general-purpose model may be used for many different purposes.

Cars are a better comparison. The government sets safety standards, manufacturers certify that their vehicles meet them, and drivers are licensed separately. Manufacturers must also report safety defects and conduct recalls when required. Alcohol is regulated in layers too. Bars need a government license that they can lose, and in many US states a bar can be liable for harm caused by serving someone who is visibly drunk.

Each rule targets the actor who controls a particular decision. I would take the same layered approach to AI.

For most risks, government should regulate the products and services that put a model to work. Those rules might limit what data and tools an AI system can access, require human approval for consequential actions, or require those actions to be recorded.

Blocking a model's release is a much stronger step. For an open-weight model, that means preventing the developer from publishing the weights. For a closed model, it could mean preventing the provider from offering access.

I would support that only when safeguards in products and rules governing their use could not prevent a serious danger in time. The three-part test below applies only to this exceptional step, not to AI regulation in general.

Three questions before blocking a model's release

The strongest argument for restricting open-weight releases is that they are difficult to reverse. The UK AI Security Institute notes that safeguards can be removed and that released weights can be redistributed and run privately beyond the original developer's monitoring.

If a model made catastrophic harm much easier, its release could be the last moment anyone had meaningful control. By catastrophic, I mean mass-casualty or comparably systemic harm, not ordinary product failure, fraud, or abuse.

Before blocking a model's release, a government should be able to answer yes to three questions:

1. Would releasing it make catastrophic harm substantially easier? The comparison should be with closed models and other tools people can already access.

2. Would safeguards applied when the model is deployed or used fail? They might be ineffective, easy to bypass, or simply arrive too late.

3. Would blocking the release materially reduce the danger? A restriction should reduce the risk, not merely move it to another country or distribution channel.

The third question is the one I expect people to argue with. Slowing an attacker down has value even if you cannot stop them. But if the same model remains available from another country or distribution channel, a ban costs defenders a tool they can inspect and run themselves while taking almost nothing away from the attacker.

As of July 2026, I have not seen public evidence that an open-weight model has crossed this threshold. It will eventually be crossed, which is why I still think meaningful regulation is coming.

For now, I would allow publication and place obligations where control already exists: on model creators for testing and release decisions, on distributors for provenance and file integrity, on product builders for permissions and deployment, and on users for deliberate misuse.

This approach also protects competition. A regulatory regime that only the largest labs can satisfy could protect them from competition without necessarily making anyone safer. It could also push organizations toward depending on a handful of providers for infrastructure they cannot inspect.

Open weights do not eliminate control. They distribute it. Regulation should follow that structure: place obligations on each actor at the point where harm can still be prevented, and block publication only when release would make catastrophic harm substantially easier, downstream safeguards could not contain it, and a restriction would materially reduce the danger.

29 Jul 2026 9:27pm GMT

It's not new and it's not sexy, but Schema.org is getting a lot more attention these days. The reason is AI.

You've probably heard that Schema improves your AI search results - apply it to your site and voilà, better results. But what is it? How does it help with AI? And, more controversially, does it actually help at all?

29 Jul 2026 4:07pm GMT

If you're reading this article online, you've already experienced the impact of one of history's most influential inventions. Chances are you've also visited several websites today to check the news, compare products, or fill out an online form.

29 Jul 2026 3:07pm GMT

29 Jul 2026 12:00pm GMT

Discover how our solution automated content translation and helped the client's team work faster.

29 Jul 2026 8:42am GMT