
21 Sep 2026
Drupal.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,instagramandpaid-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
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.
- Bram Driesen (bramdriesen) of the Drupal Security Team
- Damien McKenna (damienmckenna) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Moshe Weitzman (moshe weitzman) of the Drupal Security Team
- Pierre Rudloff (prudloff) of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
21 Sep 2026 9:56am GMT
DDEV Blog: DDEV Snapshots: Checkpoints, Restores, and Seeded Databases

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:
- Basic use of snapshots
- Use of a
seedsnapshot to automatically provide content to a project on first start - Committing a seed snapshot into a Git repository
- Starting/restarting with a seed snapshot
- Embedding a snapshot (usually for huge databases) into a custom database image
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
ddev snapshot --name=<name>- create a snapshotddev snapshot restore- opens a TUI allowing you to select snapshot to restoreddev snapshot restore <name>- restore a named snapshotddev snapshot restore --latest- restore the most recent snapshotddev snapshot restore $HOME/tmp/mysnapshot-mariadb_11.8.zst- restore from an arbitrary path, not from the default.ddev/db_snapshots/ddev snapshot --list(-l) - table of snapshot name, created date, size, database version, and compression; shows a Worktree column when relevantddev snapshot --cleanup(-C) - delete one snapshot (--name=<name>) or all of them (prompts for confirmation unless-y)ddev snapshot --all(-a) - snapshot all projects (automatically starts stopped projects to accomplish this)
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
- Some example images with seeds built into them
- uncompressed 2GB databases: https://hub.docker.com/r/randyfay/uncompressed-2g/tags
- compressed 2GB databases: https://hub.docker.com/r/randyfay/compressed-2g/tags
- MySQL 9.7 databases: https://hub.docker.com/r/randyfay/mysql-97-tagbase/tags
- Example image builder build-and-push-seeded-image.sh
- Example invocation:
build-and-push-seeded-image.sh --snapshot=seed --output-image=randyfay/d11_normal:v1.25.4 --push --base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4
This article was edited and refined with assistance from Claude Code.
21 Sep 2026 12:00am GMT
20 Sep 2026
Drupal.org aggregator
Gspikes: What Adobe Experience Manager Actually Costs (and When to Leave)
Adobe does not publish AEM pricing. Here is what it actually costs - licence, implementation, the specialist team you must keep - and how to tell when the renewal is funding software nobody uses.
20 Sep 2026 1:51am GMT
19 Sep 2026
Drupal.org aggregator
Gspikes: Drupal Hosting Compared: Speed Data From 424 Government Sites
We measured server response time on all 424 Drupal sites in the US federal and state .gov registry. Pantheon vs Acquia, CDN tails, and 12 sites on unsupported Drupal.
19 Sep 2026 3:54am GMT
Omega8.cc: Two Old Friends Move In
BOA now runs Textpattern and Grav 2 sites inside the Ægir control panel, next to Drupal and Backdrop: install, backup, restore, clone, an upgrade done on a copy while the original keeps serving, then rename and cutover, on platforms which build themselves from the newest official release. It is a promise kept, the Continuity which our thirty years story named and our website has repeated since: Drupal CMS on Ægir, done; Backdrop first-class, done; and now Textpattern, our pick before the Drupal era, whose return that story did promise, together with Grav, which has run our own website for a decade and runs our docs from Git. All of it lives in a Drupal 7 panel, on a Drush 8 which works on every PHP between 5.6 and 8.5 and talks to bee, to the Drush inside every modern Drupal codebase, and now to Grav's own CLI and Textpattern's own installer. Fourteen Drupal core lines and fifteen distributions sit next to them. And before somebody asks: no plans for WordPress ;-)
19 Sep 2026 12:53am GMT
18 Sep 2026
Drupal.org aggregator
Drupal AI Initiative: Intelligent Layouts: Drupal Canvas AI and the Context Layer
Reposted from Acquia with permission from Acquia. Authored by Martin Anderson-Clutz (mandclu)
Drupal Canvas AI shifts content platforms from reading to writing, using governed context layers to help enterprise AI agents automate safely.
What changes when an agent stops reading your content and starts writing it?
For the last two years, the conversation about AI and content has mostly been about reading. Retrieval, summarization, a chatbot that answers a question from your knowledge base. That problem is largely solved, and it is solved almost everywhere. Any serious platform can find a relevant paragraph and hand it back.
The shift that actually changes the job of a content platform is quieter. Agents have moved from "answer my question" to "do the work." They are no longer only reading your content. They are starting to write it, assembling pages and populating components and publishing the result. The category we have called content management for twenty years was built for the first job. It was never asked to do the second.
Where the Real Cost Lands
At this point a fair objection turns up: is this not exactly why we keep a human in the loop? It is. Any content platform worth running in an enterprise keeps a person between the agent and the published page. A system that lets an agent push unreviewed work straight to production is not showing you the risk of agentic content. It is showing you that it was never built for the enterprise to begin with.
So the risk worth talking about is not the rogue page. Review catches that. The risk is waste.
A read and a write still fail in opposite directions, and the cost is what separates them. When a retrieval system returns a weak answer, one person spends a moment sorting it out and moves on. When an agent produces a weak write, a layout that misses the brand or a component wired to the wrong relationship or a draft that ignored a business rule, someone has to notice it, correct it, and often send it back to be generated again. Every one of those steps costs the reviewer's time and burns the tokens that produced the work in the first place.
That cost lands on the exact person the agent was supposed to help. The promise of agentic content is leverage, so the specialist spends their time on judgment instead of assembly. A guessing agent quietly reverses the trade. Rather than assembling the page themselves, the reviewer now inspects a draft they did not write. They hunt for the places it went wrong and explain what to change. That is not leverage. It is rework wearing the costume of automation, and it scales the wrong way, because an agent that guesses does not guess once. It guesses across every draft, at machine volume.
This is why context is the whole game. A human in the loop is cheap when the work in front of them is already right, and expensive when it is not. Give the agent structured, governed context and the review step becomes a quick yes. Hand it flat fields and hope, and the review step becomes the job you were trying to automate, now done twice.
Every Generation Answered to a Different Consumer
It helps to look at what actually changed, because the content platform has served three different consumers over its life.
| Content Management System | Headless and Composable | Agentic Content Platform | |
|---|---|---|---|
| Primary consumer | A person in a browser | A front end serving a person | Software that acts |
| Content flows | Outward, to one presentation | Outward, to many presentations | In both directions |
| How editorial judgment is applied | By hand, page by page | By hand, page by page | Encoded as context up front, confirmed at review |
| Measure of success | Editorial autonomy | Reuse across channels | Safe, accountable machine action |
For most of that history, judgment stayed with the editor. The system stored content and rendered it, while a person decided what was true, what was on-brand, and what was ready to publish. Headless moved content to more places, but it did not move that responsibility. A human still stood between the content and the world.
Agentic content management changes that. The agent now does the assembly the editor used to do, which means the judgment the editor brought to the work has to come from somewhere. A platform that carries it, with the business rules and the content relationships and the standards for what good looks like, hands the reviewer a draft that already reflects those things. A platform that cannot leaves every one of those calls for the person to supply by hand, one draft at a time. The judgment does not disappear. It moves back onto the reviewer the agent was supposed to free.
The Distinction the Category Is Missing
Here is the line most tooling blurs, and the reason so many agentic demos fall apart the moment they meet a real enterprise. Content is not context.
Content is what you publish: the page, the article, the product description, the campaign.
Context is everything an agent draws on to produce that content safely. Your brand voice. Your content model. Your business rules, your reference material, and the relationships that connect all of it. Context is what turns a vague prompt into a result the organization would actually stand behind.
Most systems collapse the two. They hand an agent a set of flat fields and hope it infers the rest: the tone, the relationships, the governance that always lived in the editor's head. Guessing works beautifully in a demo and breaks in production, because the fields never carried the context to begin with. The agent was handed the output and asked to reconstruct the reasoning behind it.
Treating context as a governed layer of its own, with clear owners, review, version history, and scope, is what separates an agent that produces a plausible draft from one an enterprise can trust to publish. The prompt gets simpler. The result gets more accountable. The organization decides in advance what the agent is allowed to know and do.
What Structure Actually Buys You
Here the shape of the underlying system stops being an implementation detail and becomes the whole question.
An agent that writes needs things the read era never demanded. It needs to see the page as a structure it can reason about, with components, order, and resolved values, rather than a wall of markup it has to pattern-match. It needs to work inside the governance that already exists, the roles and permissions and workflows the organization spent years getting right, instead of routing around them. And it needs its output to land in a reviewable state, with a record of who initiated the work and what produced it, so a person can still say yes or no before anyone sees it. Structured context is what makes that review a quick confirmation rather than a second round of work.
None of that can be added after the fact. A platform that stores content as flat, disconnected fields cannot suddenly expose relationships it never modeled. A platform with shallow governance cannot suddenly supervise an agent it was never designed to hold. These are properties of the foundation. Either the structured content and the mature governance are already there, or you are trying to pour a footing under a building that already stands.
For years, careful content modeling and granular governance were treated as overhead, the slow and unglamorous work that held teams back. The agentic era inverts that. The same rigor is now what lets a team move quickly and safely at once, because it is exactly what an agent needs in order to act without guessing.

Where This Gets Real: Drupal Canvas
Plenty of tools can turn a prompt into a layout now. That trick is becoming table stakes, and it is the wrong thing to be dazzled by. The real question is whether the layout that comes back is on-brand, relevant, usable on the devices your audience actually reaches for, and built on terms you control. The answer depends on the foundation under the prompt, and that is what Drupal Canvas is designed around.
Four differences show up the moment you move past the demo.
The first is how layouts get built. Canvas assembles them from Twig-based single-directory components, React-based code components, and Drupal blocks, so you work with the component technologies your team already knows rather than adopting one proprietary format wholesale.
The second is where the context comes from. Because Canvas can ground its work in the Context Control Center, the agent is not inventing your brand from a prompt. It is working from the voice, content model, business rules, and relationships your organization has already curated and approved. That is the difference between a layout that is merely plausible and one that is on-brand and relevant.
The third is the model underneath. Through a provider-agnostic AI layer, Canvas is not wired to a single vendor's model. You use the one that suits the task in front of you, and you change your mind later as the field moves, without re-platforming to chase whatever shipped this quarter.
The fourth is where the output can go. Coupled or decoupled, you manage the content once and render it across the front ends and devices your audience uses, so a traditional site and a headless build stay open to you from the same system.
Any one of these helps on its own. Together they are the distance between generating a layout and producing one you can put into production: on-brand because it is grounded in your context, usable anywhere because the output is ambidextrous, and built with whatever model best fits the work.
The Engine Behind It: The Drupal AI Initiative
None of this is a single product feature or a one-vendor bet. It comes out of the Drupal AI Initiative, the funded and coordinated effort in the Drupal community to make the platform both a great place to build with AI and a safe place for agents to act. That initiative is the engine behind the capabilities that put Drupal in front on the things that matter here: structured content an agent can reason about, governance it has to respect, a provider-agnostic model layer, and the freedom to publish coupled or decoupled.
The work runs on two fronts. One brings common AI features directly into Drupal so they operate together instead of as disconnected add-ons. The other makes Drupal legible and callable to agents and tools working from outside, measured against an Agent Readiness scorecard that keeps the progress honest. Because it is happening in the open, on standards-based foundations, the improvements compound for everyone building on Drupal rather than accruing to one company.
The Context Control Center is a good marker of the pace. It turns the context an agent can draw on into a governed content entity, with ownership, workflow, revisions, translations, and scope, and its first stable release is expected in the days ahead. That moves the grounding layer from promising to production, which is the exact piece most platforms are still treating as a roadmap.
If you want to see where this is heading, DrupalCon Rotterdam has two AI Summits dedicated to it. I will be presenting at the AI Dev Summit, and my colleague Scott Falconer will present at the Enterprise AI Summit, one track for the people building with these tools and one for the people who have to answer for them in production.
Design It In, Do Not Patch It On
Faced with a fast-moving category, the tempting move is to wait for a winner and buy in later. The trouble is that the properties that matter here do not arrive as an upgrade. Structured content, relationship-aware data, a governed context layer, model choice, and the freedom to render coupled or decoupled are either in the foundation or they are not.
So the question for a content team is not which AI feature to switch on. It is harder and more useful than that. When an agent stops reading your content and starts writing it, does your platform still carry the judgment that used to live with your editors? Content answers to a person. Context is what lets software act in their place. The teams that see the difference, and that build on a foundation treating context, structure, and governance as first-class concerns, are the ones who will let agents do real work while keeping a hand on what ships.
18 Sep 2026 4:02pm GMT
The Drop Times: Native Observability 2.0.0 Measures Its Own Performance Cost
Diagnostic tools can add work while they investigate what a website is doing. Native Observability 2.0.0 now measures that added cost on the Drupal site where it runs instead of asking administrators to rely on a general estimate.
18 Sep 2026 3:03pm GMT
Electric Citizen: Keeping Your Website Fit

Launching your site isn't the end of the work. That's the bad news.
Even after you settle back into your day-to-day, your website still needs you. There's still so much you can and should do.
The good news: the work spreads out across the year, and the effort rises and falls. But measuring your data and making steady improvements is needed to keep your website effective long after launch.
18 Sep 2026 1:09pm GMT
Morpht: Marking its own homework: an AI content compliance reviewer for Drupal
Your content writing guidelines can now grade your content. An AI agent scores every article from 1 to 10 against site governance and lists the exact fixes.
18 Sep 2026 12:00pm GMT
Matt Glaman: Simplytest.me can launch Drupal CMS site templates
About a week ago, I wrote about the simplytest.me rewrite and closed on what was next: site templates and recipes. You can now launch a sandbox for a site template. I'm excited that people can now easily try out all the site templates on Simplytest.me.
18 Sep 2026 12:00pm GMT
mark.ie: Unboxing the Drupal Compound Field Module
Unboxing the Drupal Compound Field Module
Compound field was released as an alpha release two days ago. It's getting a lot of people excited. Let's install it and see how it works.
18 Sep 2026 11:47am GMT
Omega8.cc: The Valet Key
Every login on a BOA account is a key of one kind, and the ring holds six of them: your own panel login and your oN.ftp shell open everything; a colleague's login to the Ægir panel holds one of two roles, Client, which can do with a site what you can short of deleting it, backups and the admin login link included, or the new Site operator, the valet key of the control panel, which verifies, clones, migrates, flushes caches and runs updates on the Client's Drupal and Backdrop sites and cannot reach a copy of the database, the admin account or the delete button, not even from the Backups tab; and a colleague's shell login comes as one of two, files and themes, or whole codebases with Composer and Drush. Every task records the login which queued it. Drush is the database, so the codebase key belongs with the Client role and never beside a site operator, and the roles are a list shipped with BOA, re-asserted every night, readable to the permission on one page.
18 Sep 2026 12:36am GMT
17 Sep 2026
Drupal.org aggregator
Talking Drupal: Talking Drupal #570 - Laravel & Marketing PHP
Today we are talking about Laravel, Marketing, and The PHP Foundation with guest Matt Stauffer. We'll also cover Formdazzle as our module of the week.
For show notes visit: https://www.talkingDrupal.com/570
Topics
- What Is Laravel
- Writing Laravel Books
- AI and Technical Writing
- Laravel Versus CMS
- Drupal as Framework
- Integrating Laravel and CMS
- Laravel and Symfony
- Marketing Modern PHP
- Laravel Community Marketing
- Jigsaw and Onramp
- Drupal Marketing Lessons
- Onboarding Focus in Laravel
- Laravel BDFL Changes
- Onboarding And Docs
- Drupal Framework Perception
- What PHP Foundation Does
- Marketing PHP Vs Laravel
- AI Answers And Positioning
- Cross Ecosystem Collaboration
Resources
- Jigsaw
- Onramp
- Native php
- Alpine
- Tailwind
- Vue
- Laravel herd
- php.new
- Blog post on how to contribute to php
- Laracon talk Kent C. Dodds The Last Software Engineer (how in the AI era, we need to all become Product Engineers)
Guests
Matt Stauffer - mattstauffer.com
Hosts
Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)
MOTW Correspondent
Bernardo Martinez - bernardm28
- Brief description:
- This week's module is Formdazzle, a developer tool that makes theming Drupal forms easier.
- Drupal's Form API is a powerful abstraction, but when you want to target one specific field, label, button, or form wrapper, the default Twig template suggestions can be limited.
- The module works by taking information Drupal already knows about the form, like the form ID, element type, and element name, and using that to generate more targeted Twig template suggestions.
- For example, in a Drupal View with exposed filters, you may want to style the Reset button differently from the Submit button. By default, Drupal renders both buttons through the same input-submit.html.twig template, which makes it difficult to customize them independently. This module lets you assign different templates to individual form buttons-such as Submit, Reset, or Filter-based on their action, type, and other properties.
- This module has no configuration. Just enable the module and it starts working and look at the twig debug comments including extra template suggestions.
- Module name/project name:
- Brief history
- How old: created in 13 September 2019 by johnalbin
- Versions available: ^10.1 ^11 ^12
- Maintainership
- Actively maintained
- Last release was 1 September 2026, currently the module has two maintainers Stephen Mustgrave and John Albin.
- The module includes both test and security coverage.
- Usage stats:
- 3,956 according to drupal.org
- Module features and usage
- There's no configuration. Just enable the module and it starts working, including with Views exposed forms and Webform.
- Formdazzle automatically adds more specific theme suggestions based on the form ID, element type, and element name.
17 Sep 2026 6:00pm GMT
Droptica: Drupal content modeling for answer coverage: fields, not prose

Prices, specifications and proof buried in body copy are hard to compare, filter or reuse across pages, feeds and AI answers.
Drupal content modeling stores those facts as fields, connects related records with entity references and leaves prose for explanation. Maciej Lukianski walks through buyer-question audits, product and service field tables, migration stages and coverage reports that turn one edit into every output.
17 Sep 2026 1:18pm GMT
Morpht: Agents in a field: introducing AI Automators Agent
Your fields can now think. Route any Drupal field automator through a tool-using AI Agent and let RAG pick the answer.
17 Sep 2026 12:00pm GMT