23 Sep 2026

feedDrupal.org aggregator

The Drop Times: Drupal 11 as the Governance Layer for an Open Health Platform

A complex public healthcare platform can put Drupal at the centre of governance without making it responsible for identity, workflows, messaging, observability or the frontend.

23 Sep 2026 1:57pm GMT

LakeDrops Drupal Consulting, Development and Hosting: Eight Posts on the Fun Part. One on the Bill.

Eight Posts on the Fun Part. One on the Bill.

Photo by Kamil Foatov on Unsplash

Jürgen Haas

In Post 8 I described my monthly billing run. One client never gets an invoice: the Drupal community, which has had almost all of my working time since July 2025. This post is that invoice. The eight posts before it showed the fun part: the Modeler API, the Workflow Modeler, test and replay, the ECA Guide, orchestration. This one shows the ledger underneath: 87 actively maintained drupal.org projects, the Gin admin theme, the Admin theme subsystem in core, 293 public projects on the LakeDrops GitLab, a calendar of weekly and monthly community meetings, two DrupalCons a year. Innovation gets applause; maintenance gets a green badge. Every funding conversation so far was about a feature. Nobody has offered to sponsor a security release. Since July 2025 the revenue has been zero, paid for by earlier years. Dries' cost-allocation posts explain why. The menu at the end has prices: sponsor maintenance through Open Collective, a service agreement, hiring for ECA work, funding the next innovation. Total: roughly €10,000 a month.

23 Sep 2026 1:00pm GMT

Cheppers: ExperienceKit: Drupal Canvas and AI Page Generation - What Digital Teams Should Know

Two shifts are converging in how Drupal pages get built. The first has already arrived: Drupal Canvas, Drupal's new visual page builder, gives editors a modern, component-based way to compose pages. The second is happening across the broader industry: AI that generates pages from natural-language prompts.

23 Sep 2026 12:00am GMT

22 Sep 2026

feedDrupal.org aggregator

Drupal AI Initiative: The countdown is on: sovereignty on the Enterprise AI Summit

The Enterprise AI Summit takes place in one week, on 28 September aboard the SS Rotterdam, and the countdown is a good moment to properly introduce a session that's been on the agenda for a while: sovereign AI with Julien Blanchez.

Digital sovereignty has moved from a policy discussion into a boardroom question. Regulators, procurement teams and public sector organisations are asking the same thing in different ways: can we use world-class AI technology while keeping control over where our data lives, who can access it, and under what conditions?

With over a decade at Google working on data protection, security and digital sovereignty for large, highly regulated organisations, Julien will walk us through what's driving rising sovereignty expectations and how to keep access to leading AI technology on your own terms.

He joins a day full of similar questions answered with real numbers. The European Personnel Selection Office deployed a RAG-powered instant answer engine inside Drupal in under eight weeks, running in all 24 EU official languages, with 90% fewer repeat support questions and zero hallucinations on manual review. The American Diabetes Association will share what happened when editorial teams got real AI tools in their hands, including the honest lessons that came with it. And Moritz Arendt takes on a question that sits right next to Julien's: can AI strengthen digital communities, or does it risk hollowing them out?

With just days left, there's still time to check the full agenda and save your seat. Tickets and details are available on the Enterprise AI Summit page.

22 Sep 2026 11:11pm GMT

Droptica: Drupal vs WordPress enterprise: AI-era content operations

Deux profils de robots humanoïdes en miroir face à face devant des flux de données bleus lumineux et des circuits, métaphore visuelle du comparatif Drupal vs WordPress enterprise à l'ère de l'IA.

Choosing a CMS for a multilingual product catalogue is a content-operations decision, not a plugin shootout.

Drupal vs WordPress enterprise teams must compare field-level translation, moderation, entity APIs, and AI-ready outputs before assistants read conflicting specs. Maciej Lukianski explains when WordPress still wins, when Drupal fits connected complexity, and how to pilot migration without guessing.

22 Sep 2026 2:51pm GMT

The Drop Times: Fifteen of 28 Drupal Core Maintainer Vacancies From 2025 Remain Unassigned

The 2025 recruitment drive added maintainers across a dozen vacancy areas, but Drupal core's current roster shows how later departures and module changes have altered that picture.

22 Sep 2026 2:17pm GMT

Specbee: Your Drupal government website needs to meet WCAG 2.1 Level AA by April 26, 2027. Here's what's in scope, how Drupal helps, and how to plan your government site's remediation.

Your Drupal government website needs to meet WCAG 2.1 Level AA by April 26, 2027. Here's what's in scope, how Drupal helps, and how to plan your government site's remediation.

22 Sep 2026 3:37am GMT

Très Bien Blog: Drupack: Drupal infrastructure in a single binary

Drupack: Drupal infrastructure in a single binary

A few years ago I said Drupal needed infrastructure innovation, and I finally took the time to do something about it. While I really like DDEV, I'm really not a fan of having to use Docker for everything so I'm trying to do something about it.

theodore

22 Sep 2026 12:20am GMT

21 Sep 2026

feedDrupal.org aggregator

Omega8.cc: New Engine, Same Keys

The database under a hosted Drupal or Backdrop estate has to change generations one day, and that is the day most operators find out what their migration tooling was hiding. On a BOA box the move across Percona generations is a rehearsed road: a readiness check names the one account which would block the whole box, the single-account mover carries an account to the newer server with passwords, PHP versions and search indexes intact and the old box relaying traffic until DNS moves, and the whole-server mover refuses to cross a version at all, on purpose, because it replicates rather than dumps. Every transfer and every cutover is a dry run first, every dry run is spent on use, and the watchdog which rescues stuck databases stands down for exactly the minutes it would otherwise rescue you from your own migration.

21 Sep 2026 8:58pm GMT

The Drop Times: What EU Digital Identity Wallets Could Mean for Drupal

European Digital Identity Wallets are moving from technical framework and pilot programmes towards services that people will be able to use across the European Union. The European Commission says Member States must make wallets available to citizens, residents, and businesses by the end of 2026. For Drupal teams, that makes digital identity less a future policy topic and more an application-architecture question.

The wallet model changes what an online service can ask a user to prove. Instead of treating identity as one complete profile, users can present particular identity data or attestations and disclose only the information required for a transaction. Commission figures say more than 550 companies and public authorities across 26 Member States, Norway, Iceland, and Ukraine are participating in large-scale pilots covering government services, banking, education, health, transport, telecommunications, and other uses.

The relevant role for a Drupal application is the relying party. Under the European framework, organisations that use wallets for digital services must register their intended use and indicate the data they plan to request. That puts the request itself inside a defined trust and registration model rather than leaving every application to decide independently what identity information it wants to collect.

The technical exchange is also more specific than adding another login provider. For remote presentation flows, the EUDI architecture uses OpenID for Verifiable Presentations to carry requests and wallet responses between wallets and relying parties. A Drupal service could potentially use a validated result from that layer for authentication, account linking, permissions, eligibility checks, or workflow decisions, but the material reviewed for this issue does not establish a production-ready Drupal integration that provides those functions today.

Data handling may prove more consequential than authentication itself. A wallet may be able to prove that a person has a particular attribute without requiring the service to collect a larger identity record, and the European framework is designed around data minimisation and selective disclosure. The application still has to decide what happens next: whether the verified attribute becomes persistent Drupal user data, whether only a derived result is retained, or whether the information can disappear once the transaction has been completed.

Those decisions sit above the wallet protocol. Drupal already provides accounts, permissions, fields, workflows, access rules, logging, and application-specific data models, but none of those automatically determine which verified identity attributes an organisation should retain. Connecting a verifier to Drupal therefore solves only part of the problem; the rest belongs to application design, data governance, and the legal requirements of the service being built.

The EUDI technical framework is still developing as deployment approaches. Version 3.0.0 of the EUDI Wallet Architecture and Reference Framework, published in July 2026, updates Wallet-Relying Party registration and introduces the concept of Relying Party Services alongside other changes. For Drupal projects in European government, education, and other identity-sensitive environments, the question is not simply how Drupal accepts a wallet, but which verified facts the application actually needs after the wallet has done its job.

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

Kazima Abbas wrote and curated this issue of Editor's Pick.

21 Sep 2026 4:30pm GMT

Droptica: Drupal multilingual websites: how AI cuts translation workload while your team stays in control

Visage IA bleu abstrait avec yeux orange lumineux et flux de texte TRUST ME répétés - métaphore des brouillons de traduction IA sur sites Drupal multilingues qui nécessitent encore une relecture éditoriale avant publication.

Every update on a multilingual Drupal site must reach each market language - not just the source page.

Drupal multilingual websites can use AI-assisted translation drafts inside Content Translation workflows so editors review and publish without copying text between tools. Maciej Lukianski explains shared fields, editorial ownership, document links, and keeping localized pages consistent for people and AI search.

21 Sep 2026 4:28pm GMT

Drupal blog: The AWS Migration: Building the Next Chapter of Drupal’s Infrastructure

This is the first post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covers our testing infrastructure. Part two will cover the community programs we host beyond code. Part three will cover what the AI era is doing to open source infrastructure, and what we're building next.

Drupal is one of the open web's longest-running content management projects, in continuous development since 2001, and a recognized Digital Public Good. It runs a large share of the public web: government portals, universities, hospitals, cultural institutions, and international organizations, including the European Commission and agencies across the UN system. The Drupal Association is the small non-profit that keeps the project's home online. We build the tools that enable our community to build Drupal.

Since 2025, the AWS Open Source Credits program has supported the infrastructure behind that work. This series is our thank you, and impact report about what that support has made possible.

The scale

Drupal's collaboration happens on git.drupalcode.org, our self-hosted GitLab instance and one of the largest in open source. It hosts 42,382 contributed projects: 39,003 modules, 2,400 themes, and 979 distributions, alongside Drupal core itself.

The Drupal community opens more than 5,300 merge requests every month, about 65,000 a year, from 8,000 unique contributors annually. Drupal core alone has 15,256 issue forks.

Every one of those merge requests runs through continuous integration (CI) before it can ship. Our GitLab CI runners autoscale on AWS, accounting for roughly a third of our entire cloud footprint. In the last year they executed ~4.1 million jobs, consuming ~159.8 thousand compute hours. That's 438 hours of compute per day. (Data from Aug 26, 2025 - Aug 26, 2026).

Velocity is a contributor experience challenge

Here's what autoscaling CI means for a community like ours. A contributor in Singapore, Mumbai, or Rotterdam pushes a change and gets test results back in minutes. There is no fixed pool of test machines, no queue where contributors wait on each other, no rationing of who gets to test what.

If elastic capacity, funded by credits, means those contributors have never had to deal with longer queues, capped concurrency, or asking volunteers to test less..

We care about this because contributor velocity is essential to the success of Drupal. The Drupal Association engineering team is small, just 4 people. We don't build Drupal; thousands of people do that. Our job is to make sure the tools are available and fast when they need them.

Velocity and safety are the same system

It would be easy to frame fast CI as a developer-happiness story and stop there. But for a project with Drupal's footprint, that same infrastructure is a safety system.

In the last twelve months, the Drupal Security Team has coordinated 163 security advisories across core and contributed projects. Every fix behind those advisories was developed, tested, and released through the same AWS-powered pipeline as any other change. The sites that depend on those fixes find out through us too: about 667,000 Drupal sites check in with our update infrastructure every week to learn whether they need to act. That's a conservative floor, since it only counts sites that phone home.

We also operate Drupal Steward, a protective service that shields sites during the most dangerous window in security response: the hours between a public advisory and a site's own patching. AWS powers that too.

Drupal powers governments, public utilities, and health systems worldwide, making our testing pipeline critical public infrastructure. Every automated test directly protects the security and stability of the websites people rely on daily.

A smooth transition

For two decades, much of Drupal's infrastructure ran on donated hosting at the Oregon State University Open Source Lab, which has been a quiet hero to dozens of open source projects. As the lab restructures, we have been migrating essential services to AWS. Credit support meant that migration happened without cutting contributor capacity, and without asking a small non-profit engineering team to do more with less at the worst possible moment.

Our thanks to the OSU Open Source Lab for twenty years of partnership, and to AWS for making this next chapter possible.

What's next in this series

While compute numbers show our scale, the human impact matters just as much., In our next post: the community programs we host that have nothing to do with code, and why we think that infrastructure matters just as much.

The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.

21 Sep 2026 3:12pm GMT

BloomIdea: Mautic Audiences for Drupal: personalisation built on the segments you already maintain

Your marketing team already knows who the VIPs are. They maintain the segment in Mautic, they send it a campaign every month, they add and remove people as orders and behaviour change. Then somebody asks for a VIP banner on the website, and the website turns out to know nothing about any of it. So "VIP" gets built a second time, as a Drupal role or a checkbox on the user: two definitions of the same audience, maintained by two teams, drifting apart from the first week.

The second problem arrives with the first. Personalisation on Drupal usually means varying the page per visitor, and a page that varies per visitor is a page nobody else can be served, so the banner meant to lift conversion ends up slowing the site down for everyone.

We build and run Mautic-driven marketing for our e-commerce clients, so we kept meeting both problems on the same projects. Mautic Audiences is our answer, now on drupal.org as free software (GPL-2.0-or-later) for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It reads the segments and tags you already maintain in Mautic and turns them into native Drupal primitives: block visibility, Twig, tokens, JavaScript, Views, Search API and, since 1.1, a field.

What editors can build without a developer

Place any block, scroll to Visibility, pick Mautic segment, type vip. Save. That is the whole configuration, and it covers most of what people actually ask for:

  • A VIP banner that appears the moment Mautic adds someone to the segment. No Drupal save, no cache flush.
  • A homepage hero per traffic source: three blocks, one each for newsletter, instagram and paid-search, each gated on its own segment.
  • Hiding what someone already has. The newsletter signup block disappears for visitors already tagged subscriber.
  • Coupon-aware touches for visitors carrying a coupon:* tag, fired client-side so the page itself stays cacheable at the edge.
  • Cross-channel campaigns. Mautic sends the email, and the Drupal page the link lands on recognises the segment it was sent to. One audience definition, two channels.

Anonymous visitors count: someone carrying Mautic's tracking cookie has an audience with no login, which is what lets a campaign link open a personalised page at all. Editors check their work by appending ?ma_preview_segments=vip to any URL, which shows the site as a member of that segment sees it.

Themers get the same decision as a one-liner that brings its own cache metadata, and there is a token for metatag patterns and a JavaScript call for whatever has to happen after the page is served:

{% if is_in_segment('vip') %}
  <p>Free shipping today, your VIP perk.</p>
{% endif %}

Content that knows who it is for

The module started by answering "who is this visitor?". Version 1.1 adds the other half, "who is this content for?", in a bundled sub-module.

Add the Mautic audience field to any bundle and editors pick, from the real list of segment names, who a piece of content is meant for. By default that is a targeting hint templates and listings read. Per field, you can turn on Restrict viewing to the selected Mautic segments, and content with a segment picked is then refused to everyone outside it. Content with nothing picked stays for everyone.

A gate that only closes the page is not a gate, so the sub-module also ships a Views filter that keeps whichever rows each visitor is entitled to, and a Search API processor that adds the condition at query time rather than keeping items out of the index. Its README lists what none of it can cover, exports, feeds, custom code that loads entities without an access check, because a promise of restriction with holes in it is worse than no promise.

The interesting part is what it refuses to expose

Segment names and tags are business intelligence: cancelled-subscription, risk:churn-90d, coupon:VIP-50. Ship them to the browser and you have published how you categorise your customers, and sometimes a working coupon code, to anyone with DevTools open.

So the client-side API answers questions instead of listing facts. It will tell you whether this visitor is in a segment you name; it will not tell you which segments exist or which ones they are in. The endpoint that returns an actual list starts empty and returns only what an editor has allowlisted. The field type has no formatter at all, and reading its values takes an administrative permission, which covers JSON:API, REST and Views alike.

It stays out of your render path

Audiences are read from local storage on every render, never from the Mautic API, so a slow Mautic never sits in front of a page, and an outage degrades to an empty audience rather than an error. Cache contexts key on the resolved audience rather than on the visitor, so two people in the same segments share a cache entry and a page with two gated blocks has four variants, not one per visitor. Anonymous personalisation does cost you Drupal's Internal Page Cache on the pages that use it, which docs/cdn.md deals with head on.

Get it

composer require drupal/mautic_audiences
drush en mautic_audiences

It needs Advanced Mautic Integration for API connectivity, a Mautic instance with API credentials, and PHP 8.2 or later. A bundled sub-module wires Klaro into the resolver, so visitors who have not consented resolve to an empty audience without any code.

The project page, the issue queue and the documentation are at drupal.org/project/mautic_audiences. If you run Drupal Commerce, Commerce Mautic Connect pushes the abandoned carts, customer metrics and coupon tags into Mautic that this module reads back. Issues and merge requests are very welcome.

21 Sep 2026 1:59pm GMT

Security public service announcements: Upcoming critical contributed project security release on September 23, 2026 - PSA-2026-09-21

Date:
2026-September-21
Security risk:
Critical 16 ∕ 25 AC:Basic/A:User/CI:All/II:All/E:Theoretical/TD:Uncommon
Description:

There will be a security release for a widely used contributed module on September 23, 2026 between 17:00 and 21:00 UTC.

We are announcing this release in advance because the affected contributed module is used on a significant portion of Drupal sites, and the upcoming release will include a significant number of advisories. The advisory with the highest risk score for the release is currently rated as critical.

Drupal core is not affected.

Advisories may be published in batches (a few at a time)

The current rate of advisories may require changes to our practices going forward:

  • The security team may publish advisories individually, at different times inside the window.
  • We will try to publish batches grouped by module.
  • We will announce in Slack when all planned releases for the day are complete.
  • We will release mailing list emails about the security updates together at the end of the window, to reduce the risk of site owners updating multiple times while advisories are still being published.

These changes are intended to make the process easier for the team and to make communication from the team easier to follow.

No special release procedures

The planned update does not require special release procedures.

Coordinated By:

21 Sep 2026 9:56am GMT

The Drop Times: Shared Public-Sector Platforms Shape Big Blue Door’s DrupalCon Rotterdam Focus

Big Blue Door's Rotterdam responses point to a question already being tested in councils and healthcare: how far can shared Drupal platforms be reused across organisations with different services, editorial practices, and governance requirements?

21 Sep 2026 9:37am GMT

DDEV Blog: DDEV Snapshots: Checkpoints, Restores, and Seeded Databases

A retro instant camera producing photos of a glowing database server, with database checkpoints lined up below.

Snapshots have been a beloved feature of DDEV for years, but in v1.25.4 there is so much more.

Read on (or watch, or both) to see:

Table of Contents

Screencast showing new and old features of snapshots

Snapshots are easy!

A DDEV snapshot is a physical, "hot" backup of your database - mariadb-backup/xtrabackup for MariaDB and MySQL, or pg_basebackup for Postgres - not a text-based mysqldump. Because it copies the database's on-disk files instead of dumping SQL statements, it's much faster to create and restore, especially on large databases. All the basics about snapshots are in the docs.

Normally snapshots live in .ddev/db_snapshots/, and the filename encodes the database type and version, for example mariadb_11.8. That's why a snapshot only restores against a matching engine and version - restoring a mariadb_11.8 snapshot into a mariadb_10.11 project will fail.

Snapshots are compressed with zstd by default. --uncompressed skips the decompression step on restore, trading a much larger file on disk for a faster restore. Postgres doesn't support uncompressed snapshots.

Core Commands

If your project has multiple Git worktrees, snapshots taken from other worktrees of the same repository are available too - by name, with --latest, or through the interactive list.

Snapshots as Migration Checkpoints

Take a snapshot before each step of a migration or update: ddev snapshot --name=pre-migration-step3. If a step breaks something, restore the last good snapshot instead of restarting the migration from scratch. (ddev snapshot restore --latest can be a great technique if you do this religiously.)

ddev snapshot --list becomes a log of checkpoints, and ddev snapshot restore <name> or restore --latest jumps back to any of them instantly.

This builds on the workflow described in DDEV Database Management: snapshot, ddev restart --reset-database, restore. It's also a natural lead-in to seeding a new database volume directly from a snapshot, covered next.

The seed Snapshot

DDEV projects have always automatically created a database named db to help you get started fast. But it's been an empty database, with no content. Now, in DDEV v1.25.4+, the seed snapshot has been added. You can create a snapshot named seed (with whatever content you want) and when somebody starts up a project for the first time, the content on the seed snapshot will automatically be loaded. You can even check the snapshot named seed into your Git repository if you don't object to its size, and it can help folks new to the project to get started that much faster. (The seed snapshot is only used when there is no database; your changes to the database are kept as always.)

To add the seed snapshot to Git:

git add -f .ddev/db_snapshots/seed-*
git commit -m "Add default seed db for clean startup"

Seeding New Projects with --seed-snapshot

If you want to start a project with an alternate seed snapshot, ddev start and ddev restart accept --seed-snapshot=<name-or-path>, which seeds the database volume from a snapshot instead of the stock seed database. This only applies when there's no existing database - DDEV errors otherwise, telling you to add --reset-database or use ddev snapshot restore.

<name-or-path> can be a short name from .ddev/db_snapshots/ or a full path:

ddev start --seed-snapshot=$HOME/tmp/mysnapshot-mariadb_11.8.zst

This works for every database type DDEV supports, unlike the baked-dbimage technique below, which is MariaDB/MySQL-only - it's restored the same way ddev snapshot restore does, just at volume-creation time.

Combine --seed-snapshot with --reset-database to reseed an existing project in one step:

ddev restart --reset-database --seed-snapshot=<name> -Oy

-O (--omit-snapshot) skips the automatic snapshot save of the database being thrown away, and -y skips the confirmation prompt.

This is the lightweight alternative to baking a seeded database image: no custom image or registry, just a snapshot file - good for local or small-team use where a shared registry is overkill.

Seed Snapshots + --reset-database

Once you have a seed snapshot, ddev restart --reset-database -Oy repeatedly returns the project to that known-good state - handy between test runs.

Building a Seeded Database Image

You can also create a replacement database image that has an alternate seed database built into it. This is especially great for delivering huge databases, as the process can be handled by the image, or an upstream process. All the image building does is copy a base_db.zst or base_db.mbstream into the /mysqlbase/custom directory of the DB image.

For teams that want to share a ready-to-go database via a Docker image registry instead of a snapshot file, build-and-push-seeded-image.sh is an example that builds a real multi-arch (linux/AMD64, linux/ARM64) image with a snapshot baked in:

build-and-push-seeded-image.sh --snapshot=uncompressed-2g \
  --output-image=randyfay/uncompressed-2g:v1.25.4 --push \
  --base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4

This technique relies on mariadb-backup/xtrabackup, so it doesn't support Postgres.

Uncompressed seeds make for a much larger image and a slower push, but a faster, decompress-free container startup. It's worth comparing the actual image sizes to see the bandwidth cost of each trade-off.

Using a Seeded Image via dbimage:

Point a project at the seeded image using dbimage in .ddev/config.yaml (or .ddev/config.local.yaml):

# .ddev/config.yaml or .ddev/config.db.yaml or .ddev/config.local.yaml
# Example dbimage
dbimage: randyfay/uncompressed-2g:v1.25.4

Then:

ddev restart --reset-database --omit-snapshot -y

Examples and resources

This article was edited and refined with assistance from Claude Code.

21 Sep 2026 12:00am GMT