fidzu : Drupal

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

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

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

24 Jul 2026 11:55pm GMT

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

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

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

24 Jul 2026 10:37am GMT

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

24 Jul 2026 9:58am GMT

The Pattern I Keep Seeing

A team starts a Drupal project. Someone asks how editors will build and arrange page content. Someone else says "Layout Builder," and that is the end of the conversation. Nobody asks what the editors actually need. Nobody asks what the content model demands. Layout Builder gets switched on because it is powerful, modern, and comes with core.

Six months later, one of two things has happened. Either the editors are happily composing layouts and everyone is glad, which is the good outcome. Or the editors are confused by a tool that gives them more power than they wanted, the developers are fighting to constrain a system designed to be open-ended, and the content is inconsistent because thirty editors made thirty different layout choices. That is the bad outcome, and it is more common than the Drupal community likes to admit.

The tool is not the problem. The reflexive selection of the tool without asking whether it fits is the problem.

The Four Options

Before the framework, a quick map of what you are actually choosing between when you decide how editors build pages in Drupal.

Layout Builder. Editors compose pages by placing blocks into regions of a layout, visually, per page or per content type. Maximum flexibility. Maximum editor power. The editor decides the structure.

Paragraphs. Editors add and arrange predefined content components in a field. Structured flexibility. The developer defines the components; the editor arranges them. The structure is constrained by what you built.

Custom templates. The developer defines the layout in Twig and the editor fills in fields. Zero layout flexibility for the editor. Maximum consistency and developer control.

Plain blocks and block layout. Content is placed in regions through the block system, configured by a site builder, largely static across pages. Good for site-wide furniture, weak for per-page composition.

Each of these is correct for some situations and wrong for others. The framework is about matching the tool to the situation.

The Framework: Four Questions

I run every "how should editors build pages" decision through these four questions, in order.

Question 1: Do editors actually need to compose layouts, or do they need to fill in content?

This is the question that settles most cases, and it is the one nobody asks.

If your editors are filling in structured content (an article has a title, a body, an author, a hero image, a set of related links), they do not need Layout Builder. They need well-designed content types with well-designed fields, rendered through templates the developer controls. Giving these editors Layout Builder hands them a layout composition tool for a job that has no layout composition in it. They will either ignore it or misuse it.

If your editors are genuinely composing pages (a marketing team building landing pages with varying structures, arranging components differently per campaign), then layout composition is a real need and Layout Builder or Paragraphs becomes relevant.

The test: watch an editor work, or ask them to describe their job. If the word "arrange" or "compose" or "build" comes up, layout tooling might fit. If they describe "entering" or "updating" or "filling in," it probably does not.

Question 2: How much layout variation do you actually need?

If the answer is "every page can look completely different," Layout Builder is designed for that.

If the answer is "editors combine a fixed set of components in different orders," Paragraphs is the better fit. It gives editors arrangement flexibility without giving them raw layout power they do not need and will misuse.

If the answer is "pages of this type all look the same," you do not need either. Custom templates with fields is the right call, and it will be faster, more consistent, and more maintainable than either flexible option.

Most projects need less layout variation than they think. The instinct is to build for maximum flexibility "just in case." That flexibility has a cost, paid in editorial inconsistency and developer maintenance, and the "just in case" scenario often never arrives.

Question 3: Who bears the cost of flexibility?

Every option shifts cost to a different party.

Layout Builder shifts cost to editors, who now have to make layout decisions on every page, and to developers, who have to constrain and style a system designed to be open. The flexibility is real but so is the ongoing cost of managing it.

Paragraphs shifts cost to developers upfront (building and styling the components) and keeps the editor experience constrained and predictable. Once built, it is low-cost for editors.

Custom templates put all the cost on developers upfront and give editors the simplest possible experience: fill in the fields, the layout is handled.

The question is not "which is most flexible." It is "who should bear the cost of flexibility on this project, and can they?" A marketing team that wants control can bear the Layout Builder cost. An editorial team of subject-matter experts who just want to publish articles cannot, and should not be asked to.

Question 4: How many people will use this, and how consistent does the output need to be?

Flexibility and consistency are in tension. The more freedom you give editors, the less consistent the output.

If three trained content designers are building marketing pages, Layout Builder's flexibility is a feature and the consistency risk is manageable because the team is small and skilled.

If thirty subject-matter experts across departments are publishing content, Layout Builder's flexibility is a liability. You will get thirty interpretations of what a page should look like, and your site will drift into visual chaos within a year. Constrained tools (Paragraphs with a limited component set, or custom templates) protect consistency at scale.

The larger and less design-trained your editorial pool, the more you should constrain their tooling.

The Framework in One Sentence Each

To compress it:

• Custom templates when pages of a type look the same and editors fill in fields.
• Paragraphs when editors arrange a fixed set of components in varying orders.
• Layout Builder when editors genuinely compose free-form layouts and the team is small and skilled enough to manage the flexibility.
• Plain blocks for site-wide furniture, not per-page composition.

Notice that Layout Builder is the right answer for the narrowest set of conditions, not the widest. That is the inverse of how often it gets chosen.

Why Layout Builder Gets Over-Applied

Three reasons the reflex exists.

It is in core and it is visible. Paragraphs is contrib. Custom templates require writing code. Layout Builder is right there in core, promoted, documented, demoed. Visibility drives adoption regardless of fit.

It demos beautifully. The drag-and-drop layout composition is genuinely impressive in a demo. Stakeholders see it and want it. The demo does not show the editorial inconsistency that emerges at scale six months later.

It feels like the modern choice. Choosing custom templates can feel like you are not using Drupal's capabilities fully. There is a subtle pressure to use the powerful tool because it is there, even when the simpler option is correct. Resisting that pressure is a senior move.

Closing Thought

Layout Builder is a good tool. I am not arguing against it. I am arguing against choosing it reflexively, without asking whether the project actually needs page composition or just needs structured content entry.

The four questions above take ten minutes to run and save months of pain. Do editors compose or fill in? How much variation is really needed? Who bears the cost of flexibility? How many people, how consistent? Answer those honestly and the right tool usually selects itself.

The instinct to reach for the most powerful option is understandable and usually wrong. The senior move is to reach for the option that fits, which is frequently the more constrained one. A Drupal site where editors fill in well-designed fields through developer-controlled templates is not a less sophisticated site than one built on Layout Builder. Often it is the more sophisticated one, because someone made a deliberate choice instead of a reflexive one.

If you have shipped Layout Builder on a large multi-editor site and kept it consistent over years, I would be curious how you constrained it. That is the hard case, and the honest accounts of making it work at scale are rarer than the demos suggest.

24 Jul 2026 8:28am GMT

The Drupal AI module's Guardrails system runs configurable validation plugins both before a prompt is sent to an LLM and after a response is received. Guardrails can pass, block, or rewrite content, and can be combined into sets with a scoring threshold.

24 Jul 2026 7:20am GMT

A developer I work with sent this skill over recently, asking whether it was worth adopting across the agency's client projects (an additional pass before publication under a client's name). That's a fair question to ask before rolling something out across multiple sites, so I read the source rather than taking the pitch at face value.

24 Jul 2026 7:09am GMT

We heard you... and we want to hear from more of you!

The MidCamp 2026 Call for Sessions has been extended. The new deadline is March 13, 2026.

If you had a session idea brewing but didn't quite get it across the finish line, now's your window. We extended the deadline because we want a lineup that reflects the full range of people who use, build, and care about Drupal - and we're not there yet without you.

What We're Looking For

MidCamp sessions are open to all skill levels and all corners of the Drupal ecosystem. Whether you're a developer with a deep technical dive, a project manager with hard-won lessons, a designer with a perspective the community needs, or an end user who figured something out the hard way - there is a place for your session at MidCamp.

We're especially interested in talks around:

• Drupal AI - practical applications, integrations, and what's actually working in the field
• Drupal CMS / Canvas - building with and extending Drupal's newest tools
• Decoupled and headless implementations - real-world lessons from the front lines
• Accessibility, equity, and inclusion - building a better, more accessible web
• Community and contribution - how we grow the ecosystem together

Not sure if your idea fits? Submit it anyway. We'd rather review more proposals than miss a great talk.

How to Submit

Session submissions are open now through March 13, 2026.

👉 Submit your session here

Need help shaping your proposal? Join the #speakers channel on the MidCamp Slack - there are people there who will help you get it over the finish line.

Slack: https://mid.camp/slack

What Happens Next

After the submission window closes, our review team will evaluate proposals and notify selected speakers by April 9, 2026. Selected speakers will have until April 15 to confirm, and the full schedule will be published April 16.

MidCamp 2026 is May 12-14 in Chicago. We hope to see you on stage.

24 Jul 2026 1:40am GMT

Watch the Dries fireside chat from 2025, or catch up on all of the sessions from last year on Drupal.tv.

Theres even more Drupal goodness to be had in our archives or Drupal.tv's.

The Archives: 2024 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014

24 Jul 2026 1:40am GMT