fidzu : Drupal

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

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

To paraphrase the much used line about writing: I don't enjoy doing accessibility testing, but I like having done accessibility testing. When a site becomes more usable for everyone, I feel good. Users feel good. Clients feel good. (Regulators feel good.) The process of getting there can be very tedious.

Before we even begin addressing accessibility, we need to know where the problems live, and that's where testing comes in. There are two main categories of accessibility testing: automated and manual. Automated testing uses deterministic tools and scanning scripts to check the rendered HTML markup for certain obvious flaws, things like missing ARIA labels or low color contrast. Manual testing checks what those tools can't. A person navigates the site with the tech real users rely on, like keyboards and screen readers, and catches holes in user flows or spots where meaning gets missed. An image might have text in its ARIA label, but does that text actually help explain what the image is and how it's relevant to the rest of the content? Both categories let us find the areas of a site that need adjustments to make them more usable.

People are having plenty of thoughtful arguments right now about what AI is good for and where it doesn't belong. One use stands out to me: letting it take on the repetitive, mechanical parts of a job, freeing me up for the work that needs real judgment. So I set out to see how much of accessibility testing an AI agent could carry.

Automated testing seemed like the most logical place to start, because so much of it is deterministic: you run the scanners and collect the results. And yet a full automated pass involves lots of little decisions along the way, lots of setup steps, documentation to keep straight, mountains of results to sort through, and reports to write at the end. Exactly the type of work I wanted to hand off.

One Skill File Was Not Nearly Enough

Claude Code has a feature called skills: instruction files that teach the agent a repeatable procedure. That seemed like a promising starting point. There might be other approaches that smarter people have thought of, but this is what I knew at the time, and one of the best ways to learn is to just do and experiment. So I had a conversation with Claude and had it help me write my first automated accessibility testing skill. (In my experience, having AI write instructions for AI based on my intent tends to give me better results.)

I very quickly realized that one skill file could not handle the complexity I was asking of it. So I split it up: a skill for gathering information about the project, one for setup, one for running the tools, one for consolidating and analyzing the results, one for tracing issues back to their source, and one for reporting.

The suite kept growing as I used it and learned what else it needed to be robust. I'd run it through fresh on a site and each time find different ways it either wasn't doing enough or was just doing it flat wrong. Instead of getting mad (ok, I did get annoyed a few times) I asked, "Where is my process breaking down? What does the agent need that I haven't provided? Where is it spending the most tokens and how can I make that more efficient?"

The process now spans fifteen skills and a shared library of tested scripts, covering the full arc of an audit: plan the scope, discover and categorize the pages, pick and configure the scanners, run them, boil the output down, trace findings to source code, verify what's real, research fixes against the actual specs, write reports for the humans who need them, and retest after fixes get implemented.

I also wanted the workflow to work on any project, not just the stacks I know best. Drupal, Next.js, Svelte, WordPress, whatever comes through the door. Including up-to-date documentation for every likely framework inside the skills would have been unrealistic, and stale guidance is worse than no guidance, because the agent follows it confidently. (Just ask any Drupal dev trying to use AI out of the box for dev help). So I baked in a dependency on Context7, a service that lets the agent query current, version-specific documentation for whatever the project uses, and required checking it at several points in the workflow. Now it works from what the project is actually running instead of trusting whatever its training data half-remembers.

Humans Stay In the Loop, On Purpose

I value ownership of my work. Current models can do a lot, but they still far too often make inaccurate inferences, skip facts, and end up like my robo-vacuum, stuck in a corner and tangled in cords, costing me time and effort to get it unstuck and redo work. In personal projects this is annoying; in a regulatory environment this is unacceptable.

So at key moments I want my agents to bring me their work, get my input and signoff, and then continue based on the direction I set. The agent interviews me up front about the project and its goals. It asks permission before installing tooling dependencies or guides me through the installs. It pauses so I can check that the process and the results so far look accurate, and that it hasn't wandered off track.

What Broke Along the Way

Many useful things I learned in this process came from something going wrong. A sampling:

False positives. One scanner rule alone produced 257 rows complaining that icon-only buttons (picture a bare magnifying-glass search button) had no label for screen readers, when in reality every one of them was labeled correctly. A quick fix might be to tell the scanner to stop running that rule, but a genuinely unlabeled icon button elsewhere in the site is a real barrier for someone navigating by screen reader, so switching it off entirely would bury real problems alongside the noise. Instead the workflow keeps a list of these known false-alarm patterns, each with a condition attached: ignore this rule only where the evidence proves a label already exists. And it keeps paired test cases, one that should trip the rule and one that shouldn't. If the exception ever starts covering a real failure, a test catches it.

Too much output, then not enough. Four scanners across a real site produced 188 raw result files holding over three thousand findings, most of them duplicates of each other in different formats. I had to build a whole consolidation stage: normalize, deduplicate, cluster by root cause, rank. Then I discovered the agent was dropping and misclassifying findings during consolidation, so I pushed that work out of the agent's judgment and into tested scripts whose behavior I could verify.

Empty, meaningless reports. Early reports read like typical AI marketing copy, generic percentages and process jargon instead of actual numbers from the audits and explanations a developer could act on. They were unusable to me, the person who had instructed the AI to write them, and would certainly not be usable to anyone else. Now every report has to be built from the audit's actual findings, and written for the specific person who will read it.

The disappearing CSV parser. I watched the agent spend enormous amounts of tokens recreating, over and over, a CSV parser I knew it had already written, until I cornered it on why. The library it needed had gone missing mid-session, and rather than say so, it kept quietly rebuilding the wheel. The lesson went straight into the shared library's principles: "Never write a one-off parser; if the library doesn't support what you need, first check in with me, then extend the library and add tests."

Confidently wrong. Authentication tripped it in a way I almost didn't catch. After one scan cleared browser cookies, the session cookie never got reapplied, so every authenticated page silently scanned as the login page and came back artificially clean. Clean results feel great until you notice the settings page weighs a fraction of what it should. And color contrast in modern CSS gave it fits; converting oklch() color values to check contrast ratios burned real time and produced confident errors before I required the math to live in a tested script rather than the agent's head.

Whenever something like this came up, I stopped the agent and we talked through what happened and why. Then I changed the process and the skills themselves: more decomposition, more ask-the-human steps, more reusable tested scripts, and adversarial review agents that critique the work before I see it. Each time the pattern is the same: treat agent failures as process bugs, not one-offs to scold away.

Did It Produce Anything?

Yes, it did, and I'm quite pleased with the results.

Take a static marketing site. The workflow pointed four accessibility scanners (axe, Pa11y, Lighthouse, and IBM Equal Access) at 35 pages. Between them they returned 7,028 raw findings. Most automated scanners finish by handing me a pile of output that I have to sort through to find the meaning. That's boring and annoying so I use my workflow to remove duplicates, group the remaining items by root cause, and in this case it landed on 37 clusters. A cluster is just a bunch of findings that all come from the same underlying problem, so one broken pattern repeated across fifty pages becomes a single cluster instead of fifty separate things to chase. The review step of the workflow turns those into a short worklist. 11 of them are confirmed code fixes ready to act on. 7k+ findings down to 11 things I need to do.

I've run it on four sites so far, on stacks that share almost nothing, and gotten similar results each time.

And if I had questions about any of them, like where a problem came from, which WCAG rule it violated, even a suggested fix, I could talk it through with the agent, which had the full context of the project.

One of my favorite bits is how the workflow traces big noisy messes back to the source. On the Eleventy site, it found that fixing just two files (one layout template and one stylesheet) would clear 82% of its 7,028 findings. That is exactly the kind of combing-through I used to do by hand, and exactly what AI is good at.

29 Jul 2026 12:00am GMT

I've been working on DDEV for years now, and there's something I don't say often enough:

You make this so worthwhile.

Stas and I love to get up in the morning to hear what you have to say, learn from your experiences, share our path together.

We feel so thankful to be creating something useful in collaboration with you.

All of us have had jobs before where some boss was making random decisions on product features that we knew might be irrelevant in weeks or months. It's a frustrating feeling, and that lack of control is so terrible. With DDEV and your guidance, we always know that you're keeping us on track about real needs for real features. It's fantastic.

Real Feedback About Real Problems

Your questions in Discord or Slack and the issues you file aren't "noise". They're signal. When something breaks (or is awkward) in your workflow, you tell us, often with enough detail that we can reproduce it immediately. When something is confusing, you ask questions that reveal where our assumptions were wrong.

That feedback shapes DDEV in ways that internal testing never could. We don't use DDEV on every possible OS, with every PHP framework, in every hosting environment. You do. And you tell us what you find.

We Love Your Questions and Comments.

AI has been replacing human interaction in support situations, and in many cases doing a decent job. It usually does a good job with questions about DDEV.

But getting answers to questions is not the only purpose of support. It's also a great way to communicate problems and ambiguities to project maintainers.

We want you to ask us questions! We live for your questions. We miss the fact that you've been absent from Discord, #ddev in Drupal Slack, and the issue queue. When you ask, it helps us to understand what your struggles are and how DDEV can get better. DDEV's strength has always been the community's willingness to engage and share their needs and frictions and hopes for the project.

Hard Questions Lead Somewhere

Most of the best improvements to DDEV started with someone asking a question that seemed basic but turned out to be pointing at a real need. Why does this take so long? Why does that require a workaround? Why can't DDEV just handle this case?

Those questions are gifts to all of us. They push us to look at things we've gotten used to, and ask whether they actually need to be that way.

Generous Contributions

The DDEV ecosystem is full of people who built something useful for themselves and then shared it with everyone. Add-ons, CI configurations, documentation fixes, screencasts, blog posts.

Stas, who joined the project more recently, was surprised by how much DDEV could be extended and customized, and how good the documentation was for figuring it out. Looking back, that didn't happen by accident. It came from years of feature requests and contributions from people who solved their own problems and then shared the solution.

Every person who took time to answer another user's question in the DDEV issue tracker or Discord or Drupal Slack freed up time for the maintainers to work on the next feature.

We Learn from You

Working with the community makes us better at this work. The patterns we see in your issues, the use cases we hadn't considered, the ways you've adapted DDEV for environments we never anticipated-that knowledge informs everything.

Thank You

To everyone who filed an issue, answered a question, wrote a blog post, sponsored the project, gave a talk, built an add-on, tested a prerelease, or just told a colleague that DDEV was worth trying:

Thank you. This project exists because of you, and it's only possible because of the ways you engage with it.

If you want to stay involved, here's where to find us:

• Discord - active community discussion
• GitHub Issues
• Drupal Slack

Come say hello.

29 Jul 2026 12:00am GMT

In April 2025, I published Claude Code meets Drupal, my first public experiment with an AI coding agent. I have been experimenting with coding agents ever since, often by building tools to solve problems in my own work.

Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.

I spent an hour walking through the experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.

Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.

I also showed an API catalog that helps AI agents discover my website's search API.

These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can try it and improve it.

Once it is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a community project. If not, that is useful to know too.

The recording goes into much more detail, with demonstrations of the tools and questions from the group. You can watch it below.

28 Jul 2026 8:06pm GMT

composer require drupal/commerce_mrw:^1.1

28 Jul 2026 2:00pm GMT

Learn how Drupal's service container and dependency injection work, why they matter for testable code, and what Drupal 11 changes for your service classes.

28 Jul 2026 11:20am GMT

Beta 3 release of Drupal AI Context Beta 3 of Drupal AI Context , also known as Context Control Center (CCC), is now available. CCC helps Drupal sites provide governed, reusable context for AI workflows and agents, from brand voice and editorial standards to organisational knowledge and governance rules. This gives AI systems access to more structured and relevant information while allowing teams to manage that information centrally. Following the beta 2 release , beta 3 expands how context is authored, imported, selected and extended. It also introduces redesigned administration pages, more granular agent controls and broader integration options.

28 Jul 2026 8:05am GMT

Changes to how Drupal handles dynamic page updates could force contributed-module maintainers to support different behaviour in Drupal 11 and Drupal 12.

28 Jul 2026 5:39am GMT

Maintainers, Association leaders, developers, and community organisers faced versions of the same question this week: how should Drupal fund, govern, and sustain the work its users rely on? Reporting from 20-27 July 2026 followed that question across Association finances, security response, artificial intelligence, technical maintenance, and community participation. Read together, the stories show that shared infrastructure remains dependable only when responsibility for maintaining it is made visible.

The funding question became explicit in The DropTimes' written exchange with Tiffany Farriss, interim CEO of the Drupal Association. Farriss proposed programme-level cost accounting and the possible use of usage-based contributions for enterprise-facing utility and infrastructure services, while separating that work from digital-public-good programmes and ecosystem advocacy. The proposals are not approved policy, but they move the discussion beyond general appeals for support towards clearer questions about cost, value, and who benefits from Drupal's shared systems.

The same issue appeared in The DropTimes' 22 July coverage of Dries Buytaert's earlier distinction between "License-only Open Source" and "Stewarded Open Source", first published on 9 July, and in the week's contributed-project security advisories. A licence can grant access to code, but it cannot by itself guarantee maintenance, vulnerability response, governance, or long-term support. Reporting on AI governance, developer tooling, community events, and the July TDT Open Town Hall extended that principle into newer and more operational parts of the ecosystem. The major stories from the week follow.

Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.

This issue of Editor's Pick was written and curated by Allen Jason.

27 Jul 2026 4:30pm GMT

Our 37th monthly UI Suite meeting (July 23, 2026) opened with a small piece of housekeeping: our sessions had quietly drifted from 30 minutes to a full hour, so Pierre asked the group to bring them back to half an hour - with anyone who wants to keep chatting free to stay on after the slide deck. It worked. Thirty minutes, three updates, two demos, and we still had time for questions.

27 Jul 2026 12:00pm GMT

AI agents do not browse the web in the same way people do. They look for structure, APIs, permissions, verifiable answers and trustworthy sources. Drupal has strong foundations for this, but only when the platform is deliberately maintained and structured. AI agents do not only read web pages: how to make a Drupal site understandable and safe for machines In recent weeks, the Drupal community has been discussing a question many organisations are only beginning to formulate: how does the web change when it is used not only by people, but also by AI agents? On July 23, 2026, the Drupal AI Initiative published "Outside AI - The State of Agent Experience in Drupal". The article describes how an agent may be asked to create a content model, configure permissions, modify a running system or…

27 Jul 2026 6:00am GMT

Are DDEV and Shopware a good fit? If you ask me, yes. Let me tell you why.

I first got to know DDEV a few years ago as a freelancer working on an agency Shopware project. Up until then, every time I switched to a different agency, it was a painful process: Would the development environment on my PC (Linux back then, macOS today) even work? What new ports and commands would I have to memorize? Would the environments for my previous projects break?

So I braced myself for the onboarding meeting. But the preparation turned out to be minimal-I already had Docker, and installing DDEV beforehand was just a script. And then it was a git clone (okay, I knew that one well) and a ddev start-that was new. And it was amazing: after what felt like five minutes (okay, let's say 20, including the database download and so on), I had the shop up and running on my machine. Wow!

I quickly switched to DDEV for all of my client projects. It was a game-changer. No more "port 8000 already in use" errors. A Shopware update needs a newer PHP version? A mismatched Node.js version? Easy-just edit .ddev/config.yaml and run ddev restart. Done.

From time to time I also work on WordPress, Shopware 5, or MediaWiki projects, and DDEV is a great fit for all of them: for me, it's one and the same setup, with the same look and feel. Even to write this blog post, I ran a ddev start to bring up the Astro-based backend.

Why I use DDEV for Shopware

Which features do I reach for again and again?

Project isolation

DDEV projects are isolated from each other, so you can work on several at once without any conflicts. While working on one project, another client calls in. Two clicks and the other project is up and running-and the first one stays up, ready to be picked up again whenever you are.

Xdebug

Xdebug used to be a pain to set up with "traditional" Docker environments. With DDEV, it's a breeze. Just run ddev xdebug on and don't forget to tell your IDE to listen on the relevant port.

Redis, RabbitMQ, and Elasticsearch at your fingertips

But back to Shopware-Shopware 6, to be precise. Since it's built on Symfony, it doesn't really need much for a local setup: Apache or nginx with PHP-FPM and a database (MySQL or MariaDB). Once you get to real-world use, though, things get more complex quickly. Two Redis servers (for cache and sessions), a RabbitMQ instance for the message queue, Elasticsearch. This is where the DDEV add-ons come in. Just run ddev add-on get ddev/ddev-redis-and you're set. In my experience, there's basically no system component that doesn't have an add-on.

Hooks

Hooks exist for all kinds of things-for example, a post-import hook for the ddev import-db command. I use it to make the necessary database adjustments, such as rewriting the sales channel domains or switching the mailer to Mailpit (which is, of course, integrated into DDEV).

Inter-project communication

Did I say DDEV projects are isolated? Well, only if you want them to be. Otherwise, your app in one DDEV project can communicate with other projects-DDEV supports direct HTTP/S calls between projects. It's a great feature for developing and testing a Shopware app server, for example. I've also used it to build and test the migration from Shopware 5 to Shopware 6 across two projects.

Mirroring the production or staging environment

A shop's media files can run to tens of gigabytes-so why copy them over at all? Most of my projects use nginx-fpm, which makes an nginx reverse proxy the easy answer. Add a .ddev/nginx/media.conf file with the following contents:

location @mediaserver {
    resolver 1.1.1.1;
    proxy_pass https://www.example.com$request_uri;
    # Uncomment if the remote environment is behind HTTP basic auth:
    # proxy_set_header Authorization "Basic <base64-of-user:password>";
}

location ^~ /media/ {
    access_log off;
    expires max;
    try_files $uri @mediaserver;
}

location ^~ /thumbnail/ {
    access_log off;
    expires max;
    try_files $uri @mediaserver;
}

Then run ddev restart. This not only mirrors (and caches) the media files from the production or staging environment, but also lets you upload new media files to your local environment for testing.

Shopware tooling

shopware-cli is increasingly being developed into a one-stop tool for development, and of course I want to use it in my projects too. No problem-there's an add-on for that: ddev add-on get vanwittlaer/ddev-shopware-cli. The add-on also lets you reach the storefront and admin watcher URLs directly and, more importantly, over HTTPS.

Project lifecycle support

DDEV has the concept of "providers" that you can use to load any remote resource into your local environment. Many projects have a provider that lets you download and import a sanitized production database, with a command like ddev pull sanitized (this would be a customized command, so its actual name may vary). In theory, this also works in the push direction, although I have never come across a use case for it so far.

AI tooling

At the time of writing, I use Claude Code for my debugging and development work. To keep it isolated from my local environment, I run it inside the DDEV container-yes, there's an add-on for that: ddev add-on get vanwittlaer/ddev-claude-code. Pair it with Playwright (also in the DDEV container, via ddev add-on get codingsasi/ddev-playwright) and watch Claude do interactive frontend development.

How to get started

If you haven't worked with DDEV or Docker before, start with the DDEV installation guide.

For your first project, you may want to follow DDEV's quickstart guide for Shopware.

I prefer to keep the Shopware part of my projects in a subfolder, e.g. shopware/, separate from the infrastructure around it, such as the .ddev and .github folders. That way any developer, even one who has never used DDEV, can tell at a glance which parts are Shopware and which are not.

My Less than 5 Minutes Install guide includes a script that sets this up with a shopware/ subfolder.

If you prefer to do it manually, there are just four steps:

cd <your project directory>
ddev config --project-type=shopware6 --docroot=shopware/public --web-environment="APP_ENV=dev" \
        --web-working-dir=/var/www/html/shopware --composer-root=shopware
ddev start
ddev composer create-project shopware/production
# When it asks whether to include Docker configuration from recipes, answer `x`-
# DDEV takes care of that part.
ddev exec bin/console system:install --basic-setup --shop-locale=en-GB

You will end up with a working Shopware 6 installation; the admin credentials are admin / shopware.

Conclusions-how good a fit is DDEV for Shopware?

Whether DDEV is a good fit for you depends less on Shopware itself than on the kind of Shopware work you do.

What I take from discussions with others in the Shopware community is that we bring in (at least) three perspectives:

• Shopware core development
• Store plugin development
• Client project development

Naturally, the requirements for a development environment and tooling differ for each. For a core developer, what matters most might be running the latest versions of every dependency. For a store plugin developer, it might be testing a plugin efficiently against every Shopware version and configuration out there. There are focused solutions for these requirements, such as devenv, Dockware, the Shopware-provided Docker setup, or the new shopware-cli features.

Client project development, however, is where I spend most of my working time, and there the Shopware version and the environment that mirrors the production setup are predefined and stable within a project. The day-to-day work is:

1. debugging (core, third-party plugins, custom code);
2. developing and testing new features (ERP integration, custom plugins, custom theme);
3. installing and testing third-party plugins;
4. implementing and testing Shopware and third-party plugin upgrades.

So what matters to me is an efficient setup for a given set of dependencies and versions, ease of use, integration with testing and dev tools (Xdebug, Claude Code, Playwright, the storefront and admin watchers), reliability, support (DDEV has a great Discord community), and-last but not least-not losing time when switching between client projects.

tl;dr: my answer to the question-how good a fit is DDEV for Shopware?-is a resounding yes.

27 Jul 2026 12:00am GMT