29 Jul 2026

feedDrupal.org aggregator

Drupal Association blog: Why We Contribute: The Philosophy Behind 1xINTERNET's Top-Tier Drupal Status

This is a guest post from the incredible team at 1xINTERNET, a Top-Tier Drupal contributor and digital agency headquartered in Frankfurt, Germany.

When the Drupal Association announced that 1xINTERNET had become one of the world's Top-Tier Drupal Contributors, it was a proud moment for the company. Reaching the highest level of contribution recognition places 1xINTERNET among a select group of organisations helping shape the future of one of the world's leading open-source content management systems.

Yet, ask anyone inside the company about the achievement, and you'll hear the same response: becoming a Top-Tier Contributor was never the ultimate goal.

Instead, it is the natural outcome of more than a decade of believing that if you build your business on open source, you should help build open source itself.

For over thirteen years, 1xINTERNET has invested in the Drupal ecosystem, not only by delivering digital platforms for clients, but by contributing code, maintaining projects, sponsoring community events, supporting governance, leading strategic initiatives and encouraging employees to actively participate in the community.

Today, the company sponsors more than 500 hours of Drupal contribution every month, actively supports more than 85 Drupal projects, has sponsored over 50 Drupal events, and has contributed to hundreds of issues across the Drupal ecosystem. Those numbers tell one story. The people behind them tell another.

Contribution isn't only about strengthening Drupal, it creates real value for the organisations that choose Drupal as the foundation for their digital platforms. We spoke with Baddý Breidert, Christoph Breidert and James Tillotson about why contributing matters, how it benefits clients, and why they believe giving back is essential to building better digital experiences.

Photo of James, Christoph, and Baddy
Photo of James, Christoph, and Baddy

Building the future instead of following it

For 1xINTERNET CEO Baddý Breidert, contributing to Drupal has always been part of the company's identity.

"It represents over a decade of dedication to the Drupal project," she says. "I've worked with Drupal since 2006 and been actively involved in the community since 2013. Being recognised as one of the top three Drupal companies globally validates the expertise and sustained effort our team has invested over the years."

But the motivation goes much deeper than recognition.

Instead of simply following the direction of Drupal, 1xINTERNET believes in helping shape it. Since Drupal is the technological foundation behind many of the company's digital platforms, contributing to its future isn't viewed as optional, it's viewed as a responsibility.

That philosophy influences almost every decision the company makes. Rather than waiting for new features, improvements or innovations to arrive, the team actively participates in creating them.

Managing Director Christoph Breidert describes it simply.

"We don't just build with Drupal; we help influence where the platform is going next."

It's an approach that benefits not only the Drupal community, but every organisation that chooses Drupal as the foundation for its digital future.

Open source is built on collaboration

Although contribution often means writing code, the three leaders agree that it's ultimately about something much bigger.

Open source succeeds because thousands of people collaborate, share knowledge and solve problems together. Every contribution, whether it's code, documentation, testing, mentoring, event organisation or strategic leadership, helps strengthen the ecosystem for everyone.

For Christoph, this spirit of reciprocity sits at the heart of open source.

"If you build digital solutions using an open-source project but choose to remain on the sidelines, you miss the opportunity to influence the tools you rely on," he explains. "Open source is built on shared knowledge, and contributing back is simply part of how we work."

That collaborative mindset is equally visible throughout 1xINTERNET's culture.

IxINTERNET's UK Growth Manager James Tillotson sees open source as an extension of how the company works internally.

"We don't hoard knowledge," he says. "We share it to raise the baseline for everyone, which in turn allows us to keep innovating."

Rather than viewing contribution as something separate from day-to-day work, it's embedded in the way teams learn, collaborate and continuously improve.

Contribution isn't separate from client work

One of the biggest misconceptions surrounding open source is that contribution somehow competes with client work.

The reality, according to the team, is exactly the opposite.

James puts it bluntly.

"Contribution is client work."

When developers fix a bug in Drupal core or improve functionality that thousands of websites rely on, every client benefits, not just today, but for years to come.

Christoph agrees.

"If you're not involved in building the technology, you're always reacting instead of leading."

Technology evolves quickly. Artificial intelligence, digital experience platforms, accessibility, security and content management continue to change at an unprecedented pace. Agencies that simply consume technology are forced to wait for innovation. Agencies that contribute help create it.

Baddý believes that's one of the company's greatest strengths.

"Contribution allows us to lead initiatives like Drupal AI, ensuring we aren't just consumers of the technology but creators of it."

Instead of adapting after the market changes, 1xINTERNET helps shape those changes from within.

Driving innovation through Drupal AI

Perhaps nowhere is that philosophy more visible than in Drupal AI.

As Product Lead for Drupal AI, Christoph has been deeply involved in defining its roadmap, working alongside developers from around the world to build practical AI capabilities directly into Drupal.

For him, watching Drupal AI evolve from an ambitious idea into one of the platform's most exciting capabilities has been one of the defining milestones of the company's contribution journey.

"It's been incredible to collaborate with a global community to build something that will help shape the future of the web."

The significance goes beyond technical innovation.

Because 1xINTERNET helps build Drupal AI, its teams understand the technology long before it becomes mainstream. They know what's coming, how it works and how organisations can use it responsibly.

James, who contributes to the Drupal AI Marketing Initiative, believes this creates a significant advantage for clients.

"Our clients have access to the latest innovations because we're involved in creating them."

Innovation isn't something clients wait for. It's something they experience alongside the people helping build it.

Better contributions create better client solutions

Although many clients may never see the code being contributed to Drupal, they experience its impact every day.

Active contributors develop a much deeper understanding of the platform than those who simply implement it.

Because the team understands Drupal's architecture, roadmap and future direction, they can make better long-term decisions for every project.

"Our clients receive stable and modern solutions without having to manage the underlying complexity," Christoph explains. "By maintaining our contribution status, we act as a direct pathway to web innovation."

That means fewer surprises, more sustainable architectures and platforms designed to evolve instead of becoming outdated.

James believes clients increasingly recognise that value.

"They know we're not simply using Drupal, we're helping steer where it's going."

Trust has become a competitive advantage

Contribution also creates something that's difficult to measure but incredibly valuable: trust.

When organisations invest in large scale digital platforms, they aren't simply buying technology. They're choosing partners who will help them navigate years of future development.

Being recognised as one of the world's leading Drupal contributors provides confidence that 1xINTERNET isn't standing on the outside of the ecosystem, it's helping lead it.

Baddý has seen this become increasingly important during procurement processes.

More organisations now actively look for suppliers who contribute back to the technologies they depend on. Public sector organisations and enterprise businesses increasingly view contribution as evidence of technical excellence, long-term commitment and sustainability.

James has experienced this while expanding 1xINTERNET's presence in the United Kingdom. "When entering a new market where people don't yet know your brand, your contribution footprint becomes a global passport. The Drupal community already knows who you are."

That credibility opens doors long before a first meeting takes place.

Supporting digital sovereignty

For Christoph, contribution is also connected to a much broader movement taking place across Europe and beyond.

As organisations become increasingly concerned about vendor lock-in, proprietary platforms and ownership of their data, open-source software is becoming strategically more important than ever.

By contributing to Drupal, companies don't simply improve software, they strengthen an independent digital ecosystem that organisations can trust.

"Businesses increasingly want digital sovereignty," Christoph says. "By actively contributing to Drupal, we're helping build a secure and independent IT landscape that organisations can rely on."

It's a perspective that positions contribution not only as technical work, but as an investment in the future of open digital infrastructure.

A culture that attracts exceptional people

Contribution doesn't only benefit clients.

It also shapes the people who choose to work at 1xINTERNET.

The company actively encourages employees to contribute code, maintain projects, organise events, mentor others and share knowledge across the community.

For many developers, that's exactly the environment they're looking for.

"Top developers want to work on things that matter," James says. "We offer them a stage, not just a desk."

Christoph agrees.

Many developers are motivated by solving meaningful problems that have an impact far beyond a single client project.

For Baddý, contribution creates something equally valuable: a culture of continuous learning.

By collaborating with some of the best Drupal developers in the world, the entire team continually raises its own standards, creating an environment where innovation and professional growth go hand in hand.

Looking ahead

Becoming a Top-Tier Drupal Contributor isn't viewed as a finish line.

Instead, it's another milestone in a much longer journey.

The company plans to continue investing heavily in Drupal AI, supporting the wider community, encouraging employees to contribute and helping organisations embrace open-source innovation with confidence.

Christoph hopes to make Drupal AI even more accessible through practical demonstration environments that allow organisations to experience its capabilities with a single click.

James wants to strengthen the connection between enterprise organisations and the open-source community, demonstrating that open source can successfully support even the most ambitious digital transformation projects.

Baddý remains focused on investing in people, community leadership and the long-term health of the Drupal ecosystem.

More than contribution

Ultimately, becoming a Top-Tier Drupal Contributor isn't really about rankings, badges or recognition.

Those are simply the visible results of years of consistent investment.

The real achievement is building a company where contribution is part of everyday work, where sharing knowledge is expected, collaboration is celebrated, and innovation is something created together rather than consumed.

For 1xINTERNET, contributing to Drupal has never been about giving something away.

It's about helping build a stronger platform, a stronger community and better digital experiences for everyone who depends on Drupal.

Because when the platform grows stronger, so do the organisations, developers and communities that build upon it.

29 Jul 2026 12:00pm GMT

Smartbees: Automatic Content Translation System

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

29 Jul 2026 8:42am GMT

DDEV Blog: A Love Letter to the DDEV Community

A big red heart with the DDEV logo at its center, surrounded by scattered blue dots representing the community

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:

Come say hello.

29 Jul 2026 12:00am GMT

28 Jul 2026

feedDrupal.org aggregator

Dries Buytaert: From personal AI experiments to shared tools

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

BloomIdea: Shipping with MRW from Drupal Commerce: no more copy-pasting into the carrier portal

Several of the e-commerce stores we build and run ship with MRW, one of the main carriers in Spain and Portugal. Until recently, shipping an order meant leaving the store: open MRW's customer portal, retype the customer's address, print the label, then copy the shipment number back into Drupal so the customer gets a tracking link. Multiply by every order, every day, and add returns, which meant doing the same dance with the addresses swapped.

We replaced that with a Drupal module. It now runs the daily expedition of the first of them, and we are releasing it to the community: Commerce MRW is available on drupal.org, with a 1.1.0 release.

What it does

Commerce MRW integrates Drupal Commerce with MRW through SAGEC, the carrier's SOAP webservice for creating and managing shipments (envíos). The whole expedition cycle happens on the shipment admin pages the team already uses:

  • Transmit shipments (TransmEnvio): one click creates the shipment on MRW's side and stores the returned shipment number as the Drupal shipment's tracking code, feeding the customer-facing tracking link.
  • Labels on demand (GetEtiquetaEnvio): the transport label PDF is streamed straight from SAGEC every time someone asks for it. Labels are never stored locally, so MRW stays the single source of truth and there is no stale-file problem.
  • Cancel (CancelarEnvio) transmitted shipments before the courier picks them up.
  • Return pickups: a request can carry a pickup address (DatosRecogida), so MRW collects the parcel at the customer's door and delivers it back to the store. Returns stop being a manual job in the carrier portal.
  • Tracking: a client for MRW's TrackingServices webservice queries the current status, or the full status history, of any shipment: by MRW number, by your own order reference, individually or in bulk.
  • "Transmit as": shipments whose shipping method is not MRW (say, a generic "Free shipping" flat rate) can still be shipped with MRW. The operator picks the executing method at transmit time and the choice is recorded on the shipment.

Service codes cover the SAGEC catalogue (Ecommerce, Urgente 19 Expedición, Urgente 13 and friends), and PRE (test) and PRO (production) environments are separate credential sets with a test-mode toggle, so you can validate the integration with your franchise before a single real parcel moves.

Small module, sharp edges

The SAGEC manual is short; reality is not. A few of the edges the module rounds off for you:

  • Postal codes are per-country folklore. Spain wants 5 digits with leading zeros, Portugal wants only the first 4 of its 7-digit codes, Andorra's letters become zeros, and Gibraltar is always 00010. The module normalizes all of it before SAGEC ever sees an address.
  • The tracking service hides behind a WCF quirk: it only accepts SOAP posts on its relative endpoint address, and answers 404 on the address the documentation leads you to. We found out so you do not have to.
  • No PHP SOAP extension required. Both clients build their envelopes by hand over Drupal's HTTP client, which also makes every request fully testable with mocked responses; the module ships with a kernel test suite that asserts the exact XML that goes over the wire.

Your store's rules stay yours

Carrier integrations die by hardcoding someone else's workflow, so Commerce MRW deliberately does not have one. Site-specific data travels through an event: subscribe to the TransmEnvio request event and fill whatever your store knows, the consignee's phone number, a NIF, delivery observations for the courier, or a full pickup address to turn a transmission into a return pickup. In one of our stores, three small subscribers do exactly that: one copies the customer's phone, one sends the backoffice's "carrier notes" field as delivery instructions, and one swaps the addresses when a shipment is flagged as a return.

Tracking follows the same philosophy. The module gives you the client and a documented integration recipe, but ships no polling and changes no shipment states: whether "delivered at destination" should transition your workflow, or just inform a human, is your call. That store runs an hourly cron that mirrors the last MRW status into the expedition dashboard, next to each tracking code; marking a shipment delivered stays a human decision, now an informed one.

Battle-tested, then released

Like our other contrib modules, this one shipped to drupal.org only after running a real store's daily expedition: real transmissions, real labels handed to the courier, and a tracking client validated against the production webservice before its release was tagged. The test suite (42 kernel tests at the time of writing) covers the SOAP envelopes, the postal code rules, the backoffice forms and the tracking parsing.

Get it

composer require drupal/commerce_mrw:^1.1

Requires Drupal 10.3+ or 11 and Commerce Shipping 3.x, plus SAGEC credentials from your MRW franchise (ask your franchise; ours enabled both the shipping webservice and the tracking service on request).

If you run a Drupal Commerce store shipping in Spain or Portugal, this is for you. The issue queue is open, and international shipments, ZPL labels and MRW delivery points are on the roadmap.

28 Jul 2026 2:00pm GMT

Specbee: Understanding Drupal's Service Container and Dependency Injection

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

Salsa Digital: Drupal AI Context — beta 3 released

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

The Drop Times: Drupal 12 HTMX 4 Upgrade Returns to Review

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

27 Jul 2026

feedDrupal.org aggregator

The Drop Times: What It Takes to Sustain Drupal

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

UI Suite Initiative website: UI Suite Monthly #37 — A new look for Display Builder, and an archaeology site digs in

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

DDEV Blog: Shopware on DDEV: notes from years of client projects

DDEV and Shopware logos joined by a plus sign

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:

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

24 Jul 2026

feedDrupal.org aggregator

Drupal Association blog: Introducing the Drupal AI Security Initiative: The First Six Weeks

Drupal's volunteer Security Team has protected millions of sites for more than 20 years and its process is world-class. Bandwidth among the security engineers has always been the limiting constraint. This spring that constraint met a new kind of pressure: AI-assisted analysis is finding latent vulnerabilities at an accelerating pace.

The Drupal AI Security Initiative adds funded security capacity in response. It is funded through Alpha-Omega's Security-Engineer-in-Residence (SEIR) program, coordinated by the Drupal Association, and works alongside the volunteer Security Team, which continues its normal process throughout.

This post introduces the initiative and reports on our first six weeks. The short version: the funded fractional team model is working and has already evolved our understanding of where we want to focus next.

What changed: the economics of discovery

Drupal's attack surface is what it has always been. What has changed is the cost of finding bugs. AI-assisted analysis makes discovery dramatically cheaper. AI can produce security issue reports at a volume and can discover exploit details at a speed that any volunteer effort struggles to absorb. Our advisory data shows the rate of discovery accelerating (our next post will work through what the data suggests in detail).

Meet the Drupal AI Security Initiative Team

The initiative builds on the lessons of the Drupal 8 Accelerate Initiative, which showed that throughput efficiency depends on funding the whole contribution workflow, not just one part of it.

The Drupal security team needs fixes, not just findings of potential issues. As fixes are developed, they are collaboratively reviewed. An engineer cannot mark their own fix complete. Funding one full-time engineer would likely produce findings faster than volunteers could review them, and they would queue. So we're using the grant to fund a fractional team that covers the full path from discovery to merge on both the project and infrastructure side for Drupal:

  • Drew Weber (@mcdruid) is the Fixer. He applies AI-security expertise directly to Drupal's code: scanning, writing patches, building experimental tooling, and then submitting contribution-ready work across Drupal core and the contributed-project ecosystem.

  • Greg Knaddison (@greggles) and Michael Hess (@mlhess) are Reviewers: They triage submissions, review patches, advance issues, and provide the RTBC status a fixer cannot grant themselves. Both come from the existing Security Team, and the grant helps subsidize the work they would otherwise do on volunteer time.

  • Neil Drumm (@drumm) handles infrastructure, focusing on Drupal.org itself. The package distribution, build pipelines, and update mechanisms are a high-consequence, specialized surface on their own.

  • Tiffany Farriss (@farriss) and Tim Lehnen (@hestenet) provide program support and coordination for the Drupal Association.

Our current grant has two three-month phases: Clarity (understand the problem) and Attention (fix issues and harden the process).

Six weeks in: what we've done

We're using the funding and AI tooling to find, validate, triage, and resolve vulnerabilities faster than before, including proactively, across core, contrib, and our own infrastructure. In six weeks, the team has made contributions to more than 10 published advisories and CVEs and filed more than 30 issues. This work includes SA-CORE-2026-005, a critical PHP object-injection issue reachable via JSON:API that arrived as an external report and was coordinated to a fast release, alongside triage and remediation across dozens of findings and hundreds of inbound requests. The team also worked on rapid response/urgent issues off-hours; in one case, AI-assisted review helped find and fix a significant issue in Drupal.org code.

We're also building reusable tooling and automation prototypes that increase throughput and make our security archive searchable and actionable. That includes five Claude skills and a set of opengrep static-analysis rules, each targeting a vulnerability class, and local, open-weight tooling that processes about 40,000 historical security-mailbox emails to assign metadata like CWE mapping and flag duplicates (keeping sensitive data local). One key project outcome will be delivery of working tools the Security Team can continue to use after the initiative ends.

Drupal's grant is one of several parallel Alpha-Omega grants across open source ecosystems. Being part of this cohort has allowed us to compare notes and share tooling, successes and failures with other open source projects. So far we've collaborated most directly with Volker Dusch, who leads the equivalent effort at the PHP Foundation, and with colleagues at the Open Source Technology Improvement Fund (OSTIF), who shared their report-validator protocol for separating real findings from noise. That protocol feeds straight into our intake, and into the report standard we want to co-create next.

The counts are perhaps not the most interesting part. We've resolved more security issues (10) than the minimum number (8) our proposal had committed to over the entire six-month project. We had assumed the meat of the task would be finding and fixing vulnerabilities. It turns out that the more interesting challenge will be adapting Drupal's security process to the volume and nature of higher-quality-than-expected AI-generated and AI-assisted reports.

So far that adaptation has happened downstream, after an issue has been reported. Shepherding issues to a fix, filing CVEs, automating that filing, and automating the analysis of published advisories are important and help scale the response process. But it is all at the bottom of the funnel. The opportunity we would like to explore is higher up, at intake, where issues arrive.

We've started exploring what that might look like. In discussions with core maintainers, some design principles emerged: AI stays limited to a single triage activity per issue and no bot noise on every commit and merge request. Ideally, early intake tooling would pre-filter inbound security issue reports and run a gated check that confirms whether they include enough context and reproduction detail before they reach a human.

What's next

The next six weeks will build on what is working and push the intake question in two directions. The first is triage. The volume of incoming security issues is expected to keep growing and AI-assisted triage of that queue is an area to explore. We are interested in looking at how modern tooling can sort and deduplicate incoming issues so human attention can be focused where it's actually needed.

The second is the report itself. A clear issue report helps the Security Team and maintainer community move faster; a vague or bloated one slows everyone down. We want to explore and define what a useful AI-generated or AI-assisted security report should contain and draft a working standard, co-created with the Security Team and maintainers. If you are a maintainer or security reporter and have examples of good (or bad) AI-generated reports, please share them in Drupal Slack #security-discussion.

Six weeks of supplemental funding has already made a couple things clear. The roles the Drupal ecosystem depends on (security work as well as release management) need a durable, community-owned funding model, not one-time support. And we need to keep talking and collaborating across ecosystems like this.

Thanks

Huge thank you to Alpha-Omega for the support, funding and for access to AI tooling from Anthropic that enabled several of the findings above; to the Linux Foundation; and to the Drupal Association for coordination. And of course, none of this works without the two decades of effort from Drupal's amazing Security Team.

24 Jul 2026 11:55pm GMT

The Drop Times: Tiffany Farriss Proposes Cost Accounting and Usage-Based Enterprise Funding

Farriss says reserves are covering a gap in Drupal's wider stewardship work, prompting proposals to expose programme costs and connect enterprise use with ongoing support.

24 Jul 2026 4:53pm GMT

Dripyard Premium Drupal Themes: How Dripyard gave Tojio a fast foundation for Drupal CMS

When we started building Dripyard as a business, we had a clear objective: Drupal developers should be able to move fast without giving up the things that make it Drupal. Structured content, editorial control, accessibility, open-source ownership, and long-term maintainability should not be traded away just because a project has a tight timeline or limited budget.

24 Jul 2026 12:53pm GMT

The Drop Times: TDT Town Hall Links Newsroom Changes With Drupal’s Wider Future

Community participation moves beyond story leads as The DropTimes prepares an Editorial Working Group for Drupal contributors.

24 Jul 2026 10:37am GMT

Smartbees: Sumaris

Check out our B2B platform implementation for Sumaris - a company providing specialized solutions for industry.

24 Jul 2026 9:58am GMT