Drupal Commerce vs Shopify and WooCommerce: why Drupal's flexibility, open source code and extensibility make it ideal for complex ecommerce.

12 Mar 2026 5:09pm GMT

The Drupal Coffee Exchange will take place during DrupalCon Chicago 2026, continuing a community tradition that began at DrupalCon Seattle in 2019 and has since appeared at Drupal camps and conferences worldwide. The informal Birds of a Feather session invites attendees to bring a bag of whole-bean coffee from a local roaster and exchange it with someone from another region. Over time, the gathering has become known as a relaxed space where Drupal contributors share stories and build connections beyond code.

12 Mar 2026 4:16pm GMT

12 Mar 2026 3:05pm GMT

Display Builder for Drupal: shaping the editing experience with Config ProfilesPart 2 of the Display Builder Beta video series by UI SuiteIn the first episode of the Display Builder Beta video series, Pierre introduced us to the fundamentals of the module, by demonstrating how to create and work with page layouts. In this second instalment, he is diving into one of Display Builder's most powerful features: Config Profiles.What are Config Profiles?Last time, when we created a Page Layout with Display Builder, we were prompted to pick a profile. Out of the box, only the "Default" profile has been available.Config Profiles are configuration entities - meaning they are fully editable, exportable, and deployable like any other Drupal config.

12 Mar 2026 9:50am GMT

A decade after the European Commission began consolidating hundreds of its websites on Drupal, the conversation around open source adoption has shifted from technology choice to institutional practice. In a session titled "Using Drupal Doesn't Make You Open Source," architect consultant Adam Nagy will reflect on how one of the world's largest Drupal platforms moved from using open source software to contributing back to it. Scheduled at DrupalCon Chicago 2026, the talk examines the governance structures, organisational culture, and shared tooling that enabled collaboration across public-sector teams and turned internal development into reusable community contributions.

12 Mar 2026 6:06am GMT

I'm proud to share that Tag1 has joined the Drupal AI Initiative as a Certified Gold Partner and Maker, committing dedicated engineering time to help shape how AI works inside Drupal. We've been building Drupal since day one, and we're excited to be part of its most consequential evolution in years. We plan to contribute across multiple areas of the initiative, but we're starting by bringing governance to AI-driven changes because that's the necessary foundation for all of it.

The Governance Gap

AI tools that generate content and alter site layout and configuration are getting more capable by the day. But capability without governance is a problem, especially for organizations with compliance requirements, editorial review processes, and production sites that can't afford surprises.

You wouldn't give a new team member free rein to change your website on their first day. It doesn't matter how talented they are. The same logic applies to AI agents: they need a sandbox to work in and a human to review before anything goes live. Letting agents make changes to your website without review, approval, or an audit trail isn't bold; it's reckless.

Tag1 contributed the solution to this problem to Drupal core. Workspaces already gives teams the ability to stage content and configuration changes in isolation, review them, and publish when ready. It's the enterprise content governance layer of Drupal. Extending that same model to AI agents is the obvious move.

What Tag1 is Building

We're starting by extending Workspaces within the AI Initiative so that AI agents operate under the same governance framework that human editors do. The goal is that agents propose changes in isolated branches, humans review/approve, and every action is auditable and reversible. It's how we think AI should be applied everywhere: practical, tested, and built in the open.

We're starting with the underlying architecture, defining the interface contracts that ensure AI tools and other subsystems work correctly within Workspaces. This is the kind of unglamorous infrastructure work that makes everything else possible. If the contracts are right, any AI tool that follows them gets governed staging, review, and rollback for free. If they're wrong, nothing downstream works reliably.

The Tag1 team has been contributing to Drupal's architecture for over two decades. This work is a continuation of that commitment, getting the foundations right so the rest of the ecosystem can build with confidence.

Governance for Every Drupal Site

AI governance built into Drupal core means every site benefits. An agency building on Drupal CMS gets the same governance primitives as a Fortune 500 running a custom installation. The framework is designed to be agent-agnostic, so it works regardless of which AI tools an organization chooses to deploy. The governance layer doesn't care whether the change came from a chatbot or a custom automation. It cares that the change was reviewed and approved before it hit production.

Drupal has always been good at balancing rapid change with shared standards. The current wave of AI adoption is the latest version of that challenge, and open source collaboration is still the best way to get it right. Adding governance by extending Workspaces is just the start, and we'll have more to share as the work progresses.

Let's Talk

If you're thinking about content governance in Drupal, or working through how to keep AI agents safe and auditable on your sites, we'd love to hear from you. We test everything in our own engineering and operations before we bring it to clients - that's our AI Applied philosophy - and the best solutions come from real conversations about real problems.

12 Mar 2026 12:00am GMT

A forthcoming session at DrupalCamp NJ 2026 will offer the first public look at the 3.x rewrite of the accessibility module Editoria11y. Accessibility developer John Jameson explains how the project has evolved through collaboration with the Sa11y project, merging test suites and introducing new backend and frontend capabilities. The session will examine the technical changes behind the rewrite, the development of community-supported add-ons, and the broader roadmap for expanding the accessibility toolkit into a more comprehensive open-source governance suite.

11 Mar 2026 1:55pm GMT

Senior application architect Peter Wolanin will present a session on Drupal's plugin system at DrupalCamp NJ 2026, explaining how the plugin API enables reusable and extensible functionality in Drupal projects. The talk will introduce how plugins are structured across Drupal core and configuration, along with examples showing how developers can identify and create them in their own code. Wolanin also shared what attendees can expect from the session and why understanding the plugin system remains an important skill for Drupal developers.

11 Mar 2026 8:58am GMT

What is coder.ddev.com?

coder.ddev.com is a free, experimental cloud DDEV service. You log in with GitHub, create a workspace, and get a full DDEV environment in the cloud - no local Docker, no local installation needed.

:::warning[Experimental Service] This is an experimental service with no guarantees of data retention, uptime, or long-term availability. The future of its maintenance and sustainability is uncertain. Do not store irreplaceable work here without pushing it to Git. Treat it as a convenience, not a platform to depend on. :::

Want a quick overview? Watch the 6-minute intro video starting from the very beginning:

Table of Contents

How It Works

coder.ddev.com runs on Coder, an open-source platform for remote development environments. Each workspace is an isolated container (using the Sysbox runtime for secure Docker-in-Docker) with DDEV, Docker, and VS Code pre-installed.

Your files persist on a remote volume across workspace restarts. When you delete a workspace, the data is gone - so push your work to Git before deleting. But until you delete the workspace, or it's garbage-collected (not yet implemented), your work persists..

The source code for the templates and Docker image is at github.com/ddev/coder-ddev. Other projects can use this and deploy their own fully-DDEV-capable Coder instances.

Getting Started

1. Log In with GitHub

Go to coder.ddev.com and click Login with GitHub. No separate account needed. coder.ddev.com receives read-only access to your email addresses, public profile, and GitHub organization membership - no code access, no write access.

2. Create a Workspace

From the dashboard, click Create Workspace and choose a template:

• drupal-core - automated Drupal core development environment
• user-defined-web - general-purpose DDEV for any project
• freeform - DDEV with Traefik routing integration for stable URLs

Give your workspace a name and click Create Workspace. Most workspaces start in under a minute. The drupal-core template (with seed cache) is ready in about 30 seconds.

3. Access Your Workspace

Once running, you have several options to use your workspace:

• Web Browser: From coder.ddev.com, use the many options, including web-based terminal, VS Code for Web, and VS Code Desktop.
• SSH with coder CLI: Install the Coder CLI, then coder login https://coder.ddev.com and coder ssh <workspace-name>.

Template Overview

drupal-core

The drupal-core template sets up a complete Drupal core contribution environment automatically using joachim-n/drupal-core-development-project. Drupal core is cloned, Composer dependencies are installed, and a demo site is installed - all in about 30 seconds when a seed cache is available.

Choose your Drupal version when creating the workspace:

• main (12.x / HEAD) - latest development (default)
• 11.x - current stable branch
• 10.x - previous stable branch

The template automatically selects the correct PHP version and DDEV project type for the chosen branch.

Log in to the site with admin / admin.

This takes less than 4 minutes, try it out:

freeform

The freeform template adds Traefik routing integration so your DDEV project and services like Mailpit get stable subdomain URLs (no port numbers). After creating a workspace, run ddev coder-setup once in your project directory, then ddev start. Routing updates automatically on every start.

The Drupal Issue Picker

One of the most useful features for Drupal contributors is the Drupal Issue Picker at start.coder.ddev.com/drupal-issue.

Paste any drupal.org issue URL (for example, https://www.drupal.org/project/drupal/issues/3568144) and the picker launches a drupal-core workspace with:

• The correct Drupal version (10.x, 11.x, or main) detected from the issue
• The issue fork branch already checked out
• Composer dependencies resolved

This replaces the workflow that DrupalPod (Gitpod-based) provided for contribution days. You can hand someone an issue URL, they paste it into the picker, and within 30 seconds they have a working environment with the issue branch ready.

Demonstrating this from start to finish in about 6 minutes:

Development Tools

VS Code Web

"VS Code Web" runs in the browser and supports most extensions. You can install extensions from the marketplace, configure settings, and use the integrated terminal - all without installing anything locally.

VS Code Desktop

Clicking on "VS Code Desktop" opens up your local installation of VS Code and then automatically uses the Remote-SSH extension to connect to your Coder workspace. It's nice, I used it a lot in preparing this blog and even in some recent work on Coder.ddev.com itself. All VS Code features work.

Xdebug

Xdebug works in Coder workspaces the same way as local DDEV with the DDEV VS Code Extension.

Coder CLI

The Coder CLI provides SSH access, port forwarding, file transfer, and workspace management. It's a completely different way of interacting with your workspace. Install with brew install coder or other options.

# Login
coder login https://coder.ddev.com

# List workspaces
coder list

# SSH into workspace
coder ssh my-workspace

# Forward a port locally
coder port-forward my-workspace --tcp 8080:80

# Stop workspace (preserves data)
coder stop my-workspace

Accessing Your Project

Because DDEV runs inside a cloud container, the usual *.ddev.site URLs don't work. Instead, access your project via the DDEV Web app link in the Coder dashboard, or use port forwarding, and ddev start, ddev launch and ddev describe also give URL information.

The freeform template handles this automatically with Traefik routing - you get stable subdomain URLs like https://<workspace>--<workspace>--<owner>.coder.ddev.com/.

Stopping and Deleting Workspaces

Stop: Stops the container and frees compute resources. All files in /home/coder are preserved. Use this when you are done for the day.

Delete: Permanently removes the workspace and all data. Always push your code to Git before deleting.

This can also be done from the command-line on your local machine (after coder login https://coder.ddev.com):

coder list
coder stop my-workspace   # Stop (data preserved)
coder delete my-workspace # Delete (data lost permanently)

FAQ

• How do I pull/push to GitHub/GitLab/Drupalcode? (or use SSH)?

Use the coder publickey command to get the publickey associated with your coder.ddev.com projects (it's the same for all projects). You can then add that to GitHub/GitLab/Drupalcode/Remote SSH to allow you to access those resources.

• How do I set this up myself for my own initiative?

The full details are in the repository at github.com/ddev/coder-ddev.

• Where is this running?

This is running on a 64GB Hetzner bare-metal Ubuntu 24.04 machine in Helsinki, Finland. It has lots of disk and costs about $50/month.

Thanks to Coder.com

The world of open source is amazing. Coder.com is a shockingly mature project, and so many of these things worked just great out of the box.

What's Next

The templates and image are open source at github.com/ddev/coder-ddev. Contributions, bug reports, and feature requests are welcome.

Getting Help

• Documentation: github.com/ddev/coder-ddev/docs
• DDEV Discord: Discord - #support-and-discussion channel
• Issues: github.com/ddev/coder-ddev/issues
• DDEV Docs: docs.ddev.com
• Coder.com: coder.com or github.com/coder/coder

11 Mar 2026 12:00am GMT

Yesterday I wrote about how Open Source infrastructure across many ecosystems is fragile and underfunded.

Drupal is no exception.

Like most Open Source projects, Drupal runs on infrastructure that millions of people depend on but very few people directly pay for.

Drupal's infrastructure costs roughly $3 million per year, including servers, bandwidth, CDNs, software, and staff.

Funding comes from a mix of donated infrastructure from AWS and the OSU Open Source Lab, corporate memberships through our Drupal Certified Partner program, in‑kind contribution from Tag1, and revenue from DrupalCon, donations, and sponsorship on Drupal.org.

Last year, Drupal Association board member Tiffany Farriss and CTO Tim Lehnen analyzed the project's infrastructure costs. Their estimate: infrastructure for Drupal 8+ sites costs about $10 per active website per year.

But the Drupal Association spends only about $7.50 per site per year. About $3 comes from DrupalCon and the Certified Partner program. The remaining $4.50 comes from in-kind support: donated hosting, Tag1's infrastructure partnership, and volunteer contributions. That is all we have to spend.

The missing $2.50 per site shows up as technical debt: certain upgrades get deferred, legacy systems persist longer than they should, and the community sometimes wonders why infrastructure progress feels slow.

Even the $7.50 per site we currently fund is fragile. DrupalCon revenue depends on event attendance. Advertising depends on traffic. Tag1's in-kind contribution depends on one company's continued generosity. Our donated infrastructure from AWS and OSU could disappear at any time. At that point, the funding gap grows, more infrastructure work gets deferred, and things could start breaking.

Before talking about new funding models, it is worth asking whether the Drupal Association could reduce its infrastructure costs. Ten dollars per site per year may sound like a lot. Should we operate all of this infrastructure ourselves, or rely more on hosted platforms like GitHub or GitLab? Are parts of our infrastructure more complex than they need to be?

These are the right questions to ask. I believe we need to work both sides of the ledger: take a hard look at what we spend and build a funding model that depends less on goodwill. In practice, infrastructure decisions rarely optimize for everything at once. They involve tradeoffs between cost, speed, flexibility, and control.

Corporate patronage is worth considering. A single well-resourced sponsor could fund Drupal's infrastructure in a way community fundraising cannot, and if the choice were between a patron and a crisis, a patron wins. It's fast, requires no technical changes, and doesn't touch the social contract with site owners.

But patronage trades one fragility for another. Instead of depending on event attendance or AWS cloud credits, you depend on one company's continued generosity and strategic alignment with the project. If their priorities shift, we're back where we started. A patron funding infrastructure at this scale would also expect meaningful benefits. That usually means greater visibility and some level of control over Drupal.org.

Most infrastructure systems connect usage to funding. Cloud platforms charge for compute. Roads are funded by taxes paid by the people who drive them. Drupal's infrastructure has neither mechanism: millions of sites depend on Drupal.org services, but the cost of operating those services is disconnected from the people who rely on them.

A funding model tied to usage avoids some of the issues with corporate patronage, but comes with its own trade-off. Open Source culture is built on anonymous access. You can download any package, no questions asked, no account required. Any usage-based model has to break that norm. The simplest version would probably require a Drupal.org API key to download packages or receive automatic update notifications.

Requiring an API key is standard practice for any commercial API, but in Open Source it feels different. Requiring site owners to identify themselves to Drupal.org is a cultural shift, even if the key itself is free forever. Any such mechanism requires changes to Drupal Core, which could take years to reach the installed base. If we go down this route, we can't wait for a funding crisis to begin this work. By the time a real crisis arrives, we would still be years away from a solution.

I don't have a specific mechanism to propose yet. But we should start this conversation now, while we have the time and stability to get it right. The alternative is making the same decisions later, under more pressure, with fewer options and less trust to spend.

Thanks to Tiffany Farriss, Tim Lehnen, Gábor Hojtsy and Lauri Timmanee for reviewing my draft.

10 Mar 2026 10:30pm GMT

DrupalCamp NJ 2026 will take place from 12 March 2026 to 14 March 2026 at Princeton University in Princeton, New Jersey, bringing together Drupal developers, site builders, and community members for three days of training, sessions, and collaboration. Among the scheduled presentations is "Governance You Can See: Embedding Content Rules Directly Into Drupal," a session by Nathan Wallace that explores how governance guidance-often stored in documents and policies-can be embedded directly within Drupal's publishing experience to help teams maintain content quality, accountability, and editorial clarity.

10 Mar 2026 3:00pm GMT

10 Mar 2026 1:33pm GMT

The Nightmare of Permissions and OAuth Scopes in Drupal

Drupal's role-based access control is one of its strengths. Permissions and roles are well-understood, and the system is mature. But the moment you step outside the standard cookie-based session - say, into OAuth with the authorization code flow - you hit a wall that the core permission model never anticipated.

Super-permissions and their hidden assumptions

Drupal treats administer nodes and bypass node access as super-permissions. If a user has either, NodeAccessControlHandler assumes they can perform any operation on any content type and skips the granular checks entirely. bypass node access is actually more powerful than administer nodes - a quirk of legacy cruft going back to early Drupal versions.

10 Mar 2026 1:00pm GMT

UUIDv5 with config name as input. Storage decorators that intercept every write path. A hashed-table edge case that almost caused data loss. Here is how the module works.

10 Mar 2026 10:55am GMT

10 Mar 2026 10:01am GMT

Can one open-source CRM manage all your donors and donations in one place? If you're working for a nonprofit, you must read this blog to find out how CiviCRM can manage contacts and fundraising efficiently for you.

10 Mar 2026 7:47am GMT