21 Sep 2026

feedDrupal.org aggregator

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

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