Drupal feeds

Drupal Association blog: Meet The Drupal Association Team At DrupalCon Rotterdam 2026

Drupal Planet -

DrupalCon Rotterdam 2026 is almost here. The Drupal Association staff and board are heading to the Netherlands next week, and we'd love to see you there!

Photo Credits: Ryan Witcombe

Here's where you'll find us during DrupalCon Rotterdam 2026:

Drupal.org Engineering Panel

Join the DA engineering team for an open and honest look at the current state and future of Drupal.org (the platform the entire community relies on every day). From nearly 10,000 projects migrated to GitLab, plans to support a brand new Drupal.org marketing site, and initiative support for Drupal CMS + Canvas and the AI Initiative, there's a lot to cover. The session closes with an open Q&A, so bring your questions

Day & Date: Wednesday, September 30, 2026

Time: 11:40 to 12:25 CEST

Location: Goudriaan Room I&II

Marketing Panel

Building on the momentum of the Drupal AI initiative, the Drupal Association is growing coordinated advocacy and marketing efforts in new areas, opening the door for more people to get involved and make a visible contribution.

Join the panel to understand how the initiative is taking shape, why they’re gaining traction, and what makes them different. The panelists will discuss how marketing in Drupal is becoming one of the most accessible and high-impact ways to contribute, where individuals and organizations  alike can raise their profile, earn recognition, and help shape Drupal’s future.

Day & Date: Tuesday, September 29, 2026

Time: 16:40 to 17:25 CEST

Location: Goudriaan Room I&II

Drupal Association Public Board Meeting

The DA Public Board Meeting is open to all DrupalCon attendees and is your opportunity to hear directly from the Drupal Association board. Come with your questions, your feedback, and your ideas. This is your chance to engage with the people shaping the future of the Drupal Association.

Day & Date: Tuesday, September 29, 2026

Time: 14:25 – 15:10 CEST

Location: Rotterdam Room I&II

Drupal Association Partner Lunch

An exclusive afternoon gathering for agency leaders and partners to connect with Dries and DA leadership over a seated lunch. A unique opportunity to share strategies, discuss the Drupal business ecosystem, and build meaningful relationships with peers from around the world.

Tickets are required, register here.

Day & Date: Tuesday, September 29, 2026

Time: 12:00 – 13:30 CEST

Location: Postillion Hotel & Convention Centre WTC Rotterdam

Drupal Business Dinner

Cap off Wednesday evening with the Drupal Business Dinner, an intimate gathering of Drupal agency executives for a seated 3-course dinner, a presentation, and meaningful conversations in a beautiful Rotterdam venue.

Tickets are required, register here.

Day & Date: Wednesday, September 30, 2026

Time: 19:00 – 22:30 CEST

Location: De Harmonie, Rotterdam

Photo credits: Matthew Saunders

Whether you're joining us for a session, an exclusive event, or just stopping by our booth to say hello, the Drupal Association team can't wait to connect with you.

The last few days are left to secure your ticket to DrupalCon Rotterdam 2026, if you already haven’t. See You in Rotterdam!

Drupal AI Initiative: Introducing our official Drupal AI Initiative training program: AI Inside Drupal Essentials

Drupal Planet -

As we see our goals for Drupal AI innovation under responsible human guidance flourishing at such a remarkable pace, we recognize a growing community need for practical, responsible ways to learn it. We’re excited to announce, as part of our efforts to fill that need, AI Inside Drupal Essentials (AIDE,) developed and presented by DrupalEasy, as the official training program of the Drupal AI Initiative. 

We’ve partnered with Drupal expert developer and highly respected trainer Mike Anello (ultimike) to ensure the program supports our mission to drive responsible AI innovation and build on Drupal’s position as the leading open-source content management system for AI integration. Mike and the team at DrupalEasy have the commitment and experience to create, maintain and present the curriculum with our standard for ethical, powerful, and accessible AI in the open-source world.

AIDE

AIDE is designed to help you move forward quickly and confidently with a solid foundation in how to conscientiously take advantage of Drupal AI benefits. The 2-week, 18-hour curriculum is presented on a timetable designed to integrate well into work schedules; meeting live, online for 3 hours every other day. The first session kicks off on November 9, 2026 and runs through November 20th. Additional sessions will be announced in the coming weeks.

In addition to DrupalEasy’s signature lively, online classes; each class session is recorded and becomes part of the video library that participants have lifetime access to. Other resources included as part of the course is a dedicated Slack channel and more than 100 pages of technical guides and implementation tools. The cost to register is $600.

Learn risk mitigation & human oversight

Mike Anello, who has meticulously developed hundreds of hours of Drupal curriculum and trained Drupal developers for more than 20 years, has created another stellar program that leads you, hands-on, through admin-facing responsible AI techniques that prioritize workflows that keep a human in the loop to review AI-generated suggestions before they are saved to the database. From class to class, you'll move from secure foundations to advanced agentic workflows and high-performance retrieval augmented generation (RAG) search, with intensive hands-on examples you can apply to your own Drupal projects right away.

Course content

The course covers four areas:

  • AI Foundations: Establish a baseline for secure LLM integration. Configure the AI Automators and Field Widget Actions modules to see how AI output can be reviewed before it's saved.
  • AI Agents: Implement agentic workflows and swarm orchestration agents, and deploy tool-calling capabilities that let AI interact directly with Drupal's Tool API.
  • RAG Search: Build retrieval augmented generation systems using vector databases, and learn semantic chunking and representation strategies that maximize search accuracy.
  • Local AI & Privacy: Deploy local models via Ollama for maximum privacy and cost-efficiency, and use the AI Metering module for automatic local fallback when commercial API quotas are reached.

Our goal, with AIDE and our other learning resources including webinars, workshops, events and the Drupal AI Demo is to make sure everyone who works with Drupal AI can do it safely and effectively.  

Learn more about AI Inside Drupal Essentials training , or ask about the course or AIDE team pricing.

DDEV Blog: DDEV September 2026: v1.25.4 Ships, Hobobiker Rides Again, Pressable Goes Official

Drupal Planet -

DDEV v1.25.4 Is Out

DDEV v1.25.4 landed on September 2 with 142 PRs from the community. The theme is doing less by hand:

  • Database seeding — a new project can start from a seed snapshot instead of an import step.
  • ddev start --reset-database — throw away a project's database and start clean without ddev delete -O.
  • Global Dockerfiles and env files — image and environment customizations applied to every project at once, instead of per-project.
  • MySQL 9.7 LTS, plus MODX Revolution and Maho project types.
  • Linux packages moved to Cloudsmith at packages.ddev.com (Gemfury keeps working).

Read the full release post for details.

Snapshots, Explained (with Screencast)

The snapshot work in v1.25.4 got its own post: DDEV Snapshots: Checkpoints, Restores, and Seeded Databases. It covers basic snapshot use, checkpointing during a migration, uncompressed snapshots, snapshots embedded in the project, and seeding a new project from a snapshot — with a screencast↗ walking through old and new behavior.

The older DDEV Database Management post has been updated to match.

Hobobiker Rides Again: A Three-Part Live Series on Drupal 6 → Drupal 11 with Claude

The Drupal AI Learners Club↗ — the initiative led by Amber Matz and Angie Byron that meets regularly for show-and-tell on AI tools and workflows — has scheduled a three-part live series with Randy Fay joining Amber and Angie as host, migrating hobobiker.com — a Drupal 6 site with years of content — two different ways.

After Jamie Abrahams migrated a site live and checked the result with evals in One Command, One Migration: AI Best Practices in Action↗, Randy tried the approach on his own very old site. The results made one thing clear: Claude does its best work with a guided plan, a clear view of the source and destination, and success criteria it has to prove it has met. So the series takes hobobiker.com on two journeys — one ending in static HTML, the other in Drupal 11 — and checks both against the same test suite.

These are working sessions, not polished demos. Bring your questions, suggestions, and opinions; the peanut gallery is part of the show.

All three are on the club's Luma calendar↗, and recaps of past sessions are collected in the session list on drupal.org↗.

  • October 16, 2026 at 9:30 AM US Pacific / 12:30 PM US Eastern / 18:30 CEST — Part 1: Road Test: Having Claude Write the Tests Before the Trip
    Before any migration starts, we need a way to know whether it worked. Randy works with Claude to explore the Drupal 6 site and design automated tests covering content and design: pages, paths, images, menus, and how things look. The goal is a test suite that doesn't depend on any particular destination, so the same tests can run against a static archive and a Drupal 11 rebuild. Along the way: how to push Claude past "looks good to me" toward a complete verification plan, and how a sandboxed environment like coder.ddev.com smooths out the process.
    RSVP↗

  • October 23, 2026 at 9:30 AM US Pacific / 12:30 PM US Eastern / 18:30 CEST — Part 2: The Last Ride: Sending a Drupal Site into Retirement
    Not every old Drupal site needs an upgrade; some just need a dignified retirement. Randy has archived plenty of legacy sites as static HTML, and this time Claude does the work — given a proven strategy (Lullabot's "Sending a Drupal Site into Retirement"), clear success criteria, and the tests from Part 1. Can it turn hobobiker.com into a static site that holds up, in an hour, in a way everyone watching can follow? A practical use case for anyone with an aging site that still has content worth keeping.
    RSVP↗

  • October 30, 2026 at 9:30 AM US Pacific / 12:30 PM US Eastern / 17:30 CET — Part 3: The Long Haul: Planning and Running a Drupal 6 to Drupal 11 Migration
    This is the hard one. Drupal 6 to Drupal 11 skips many major versions and hits most of the snags that come with them. Instead of turning Claude loose, we prepare it the way you'd onboard a new team member: first it explores the D6 source database and files, then it learns what the D11 destination offers, then it writes a migration plan before touching any code. Randy follows that plan live, with plenty of input from the peanut gallery, stopping at sensible checkpoints and picking up in later sessions if needed. The finish line is the same test suite from Road Test, now running against a working Drupal 11 site.
    RSVP↗

Pressable Ships an Official DDEV Add-On

Pressable↗ released an official, open-source DDEV add-on for syncing WordPress sites between their hosting and a local DDEV environment.

  • What it does — ddev pull pressable and ddev push pressable sync the database and uploads over SSH and WP-CLI, with no API tokens or plugins required. --skip-db and --skip-files let you move one or the other, and Pressable limits pushes to non-production staging sites, with confirmation prompts, as a safeguard.
  • Install — ddev add-on get pressable/ddev-pressable
  • Links: changelog entry↗ • source on GitHub↗

There's also a French write-up from KingLand looking at how Pressable combines the DDEV add-on with MCP-driven AI for agency WordPress maintenance, including the case for keeping humans on the sensitive operations: Pressable : l'hébergement WordPress dopé par DDEV et l'IA↗ (French).

Community Projects

ddev-branchery: a URL, PHP version, and database per branch — Benjamin Kott's add-on gives each Git branch its own worktree beside the main checkout, with its own web address, PHP runtime, and isolated database, while the main project keeps running. Documentation↗

ddev-tailnet-proxy: DDEV projects on your tailnet — Titouan Mathis built a proxy that discovers running DDEV projects on a remote development server, assigns them stable ports, and serves them under the server's Tailscale hostname — no per-project configuration. Read the note↗

TYPO3 Quickstarter 0.7.0 — The CLI that scaffolds local TYPO3 environments on DDEV added support for legacy TYPO3 9 and 10 on PHP 7.4, so older extensions can be worked on before modernizing, plus a built-in phpMyAdmin that auto-logs in. Release notes↗

Knecht Cloud, hands-on — Matthias Andrasch walks through installing Knecht Cloud on a Hetzner VPS: project setup, AI-driven workflows, a browser terminal, and online previews, in a tool built for DDEV projects on TYPO3, Drupal, and Craft CMS. Read part 1↗

Talks and Tutorials from Around the Web
  • DDEV & shopware-cli for Shopware 6 → Benny Poensgen's slides from Shopware Open-Stage on September 17, 2026, on pairing DDEV with shopware-cli. View the deck↗ — see also his Shopware on DDEV post, and his October 21 training session below.
  • Mailpit with DDEV for Drupal 11 email testing (Spanish) → Jesús Daza covers DDEV's built-in Mailpit integration and an SMTP-based setup, how to reach the UI, and how to confirm mail is being delivered during development. Read on solucionex.com↗
  • A DDEV-based local development workflow → Michael K. Laweh on what DDEV gives a consultant working across Laravel, Yii, and WordPress projects: consistency across projects and teams, fast project setup, and framework-agnostic tooling. Read on klytron.com↗
DDEV Live Training

Sessions are open to everybody.

Zoom Join Info:
Link: Join Zoom Meeting
Passcode: 12345

Governance
  • The next DDEV advisory group meeting, open to everybody, is November 4, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CET. Add to Google Calendar • See the agenda. We love to hear from our community!
Sponsorship Update

We so appreciate all of you supporting the project!

August 2026: ~$10,038/month (83.7% of goal)

September 2026: ~$10,099/month (84.2% of goal)

If DDEV has helped your team, consider sponsoring. → Become a sponsor↗

Contact us to discuss sponsorship options that work for your organization.

Stay in the Loop—Follow Us and Join the Conversation

Compiled and edited with assistance from Claude Code.

Talking Drupal: Talking Drupal #571 - GovHub

Drupal Planet -

Today we are talking about GovHub, Drupal in Government, and Why Governments Love Drupal with guest Jasmyne Epps. We'll also cover Convivial Gov Site Template as our module of the week.

For show notes visit: https://www.talkingDrupal.com/571

Topics
  • GovHub Origins and Goals
  • Feature Requests and Governance
  • Why Government Chooses Drupal
  • Team Structure and Release Cadence
  • Accessibility and Compliance Strategy
  • Hosting Model and Multisite
  • Structured Content and Microcontent
  • Syndication and Emergency Alerts
  • Orchard Design System Explained
  • Training and Onboarding Editors
  • Gov Talks Conference
  • Logo Specs and Releases
  • Ticket Prioritization PRICE
  • QA Workflow with Tugboat
  • Handling Traffic Spikes
  • Drupal 11 Performance Talk
  • Drupal 11 Upgrade Gotchas
  • Getting Users Excited
  • Translation Strategy Limits
  • Why Government Loves Drupal
Resources Guests

Jasmyne Epps - jasmyneepps.com jasmyneepps

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

Martin Anderson-Clutz - mandclu.com mandclu

  • Brief description:
    • Have you ever wanted to stand up a polished, accessible government website in Drupal (with components, content types, SEO, and cookie consent all wired up) without writing any code? There's a site template for that.
  • Module name/project name:
  • Brief history
    • Created in March 2026 by Morpht, the shop behind the Convivial family — with Ivan Zugec leading the maintainer team.
    • Versions available: 1.3.3, which works with Drupal 11
  • Maintainership
    • Actively maintained: release just last week, on September 16th
    • Security coverage
    • Test coverage: functional tests for install and validation, plus a kernel requirements test.
    • Documentation there's a full handbook over at docs.morpht.com, and a live demo at gov.convivial.io
    • Open issues: none?
  • Site template features and usage
    • Like the Haven site template we talked about a couple of weeks ago, Convivial Gov gives you a curated stack plus demo content, and in this case hands you a robust, ready-to-customize government site.
    • Because it's built on Drupal CMS, you get all the latest Drupal tooling: Canvas for visual page building, Single Directory Components, and Recipes.
    • The front end is Morpht's Morphos theme, built on Tailwind and DaisyUI, so you get dark mode, multiple colour palettes, and a big library of editor-friendly components out of the box. It's worth mentioning that using the Morphos theme on a production site requires a paid license
    • The provided components are sorted into six buckets: container, content, child, element, background, and behavior. They include fun ones like scroll reveal and a colour palette switching behavior
    • The content model is broad. You get seven content types: Page, Section, Article, Publication, Resource, Topic, and Audience. And, they come with a stack of teaser and card view modes to display them.
    • The whole point is no-code: a site builder can compose sophisticated pages in Canvas without ever touching a template.
    • One thing to watch: the default timezone is Australia/Sydney out of the box
    • It's also worth comparing Convivial Gov to another site template called Local. Both dropped in March 2026, both are Canvas-based Drupal CMS site templates for the public sector, and both lean on ECA for automation — so there's real common ground. The difference is scope and mechanism. Local, from Annertech, is narrowly purpose-built for local councils and community-service directories: it ships a specific service information architecture — Service and Service Landing content types — with ECA wired so section pages stay in sync when service pages get published or updated, taking its cues from the gov.uk design system. Convivial Gov goes the other way — it's design-system-led and general-purpose, a broad component library and content model meant for any government, agency, or marketing site rather than one particular workflow.

Centarro: Drupal Commerce vs. Shopify

Drupal Planet -

Shopify is the fastest way to launch a simple online store. It handles hosting, security, and checkout beautifully. For straightforward DTC brands, it's hard to beat. But the more your business strays from a simple product catalog (B2B workflows, multi-brand storefronts, complex product configurations, deep ERP integration, content-driven commerce, full SEO control) the more you end up fighting the platform, stacking paid apps, and working around limitations that shouldn't exist.

And there’s a deeper issue. Shopify is a merchant services company first and an ecommerce platform second. When 68% of GMV (Gross Merchandise Value) flows through Shopify Payments and the Shop app mediates your post-purchase relationship, you have to ask yourself: do you really own your customer relationship at all?

Drupal Commerce is an open source ecommerce framework that gives you complete ownership of your code, data model, customer relationships, and roadmap. No per-transaction platform fees. No forced migrations. No artificial product limits. No locked-down URLs. No platform inserting itself between you and your buyers. It's built for businesses that need the platform to adapt to them—not the other way around.

Read more

Jacob Rockowitz: Vibing Drupal: Using AI to hammer at the Webform module's security issues

Drupal Planet -

I came up with the title for this blog post while working on 20+ Webform security issues, because there were moments when I used Codex to hammer out a particularly complex issue. I couldn't help but find it ironic to use something as advanced as AI to hammer at a problem or challenge.

Some security issues were so complex to reproduce that I had to push Codex to replicate the problem, and it occasionally generated sloppy code. Still, even with Codex generating AI-slop, it helped me understand the root causes and solutions for security issues that had lingered for years.

Before I go any further, let's step back and talk about the challenge of maintaining the Webform module and addressing security issues.

Maintaining the Webform module

The bulk of the Webform module was created a decade ago, when I had more time and motivation to make a sizable contribution to Drupal. Drupal contributors and their contributions come in all shapes and sizes. The current codebase is stable and extendable, with "extendable" as the keyword, because people and AIs can alter and create Webform features and behaviors as needed using contributed modules or custom code. It is ironic that all the example webforms included in the Webform module, intended to help humans, have proven incredibly useful for AIs in understanding and extending webforms.

Though I am willing to say the code is stable, the fact that a webform is generally public and accepts input leaves the Webform module open to security issues. In other words, malicious actors, including AI, will target webforms to exploit XSS vulnerabilities or expose data.

Securing the Webform module

It is worth recognizing and praising Drupal's security team for...Read More

Tag1 Insights: All Hands on Deck: Tag1 Is Headed to DrupalCon Rotterdam

Drupal Planet -

Take Away Hank VanZile, Senior Director of Customer Experience at Tag1, previews Tag1's seven-talk lineup for DrupalCon Rotterdam 2026: practical AI in Drupal, the deep core work behind performance and testing, and a labor-union learning platform rebuilt on Drupal. One is a shadow-AI session he co-presents with amazee.ai. The day before the conference, Tag1 attends and sponsors the Enterprise Drupal AI Summit as a Certified Gold Partner and Maker in the Drupal AI Initiative.

The DrupalCon program is always more than any one person can take in, so ahead of Rotterdam I want to lay out where Tag1 will be and how to connect with us. We have seven talks across Tuesday the 29th and Wednesday the 30th.

If you are coming, treat this as a map to where we will be and what we will be talking about. If you are not, the lineup is a fair read on where our heads are this year. A good deal of it is AI a team can put to work in a Drupal project today. More of it is the unglamorous work inside Drupal core, the parts nobody demos but everything else leans on. And one talk is the client story that keeps the rest honest. The full DrupalCon schedule covers everything beyond our own sessions; the times below are all local CEST.

First Stop, Afloat: The Enterprise Drupal AI Summit

The week opens on Monday the 28th, before any of the DrupalCon sessions, with a full day at the Enterprise Drupal AI Summit aboard the SS Rotterdam, the former ocean liner. It's a strategy day rather than a code day, built for senior decision-makers in government, higher education, and large enterprises, with a program on data sovereignty and running AI on enterprise platforms. Tag1 is there as both a summit sponsor and a Certified Gold Partner and Maker in the Drupal AI Initiative. The certification marks demonstrated Drupal AI expertise and a commitment to the Drupal code and community, and it fits a longer pattern. Data sovereignty is also where my own session picks up the next day, so if that is the thread you care about, the summit is the place to start.

Next Stop, Ashore: The DrupalCon Sessions Tuesday, September 29 From Shadow AI to Sovereign AI Infrastructure Thomas Schröpfer Hank VanZile

Often, AI use inside a company was never approved by IT. It arrives through a browser extension, a personal account, a tool someone tried because it saved them an afternoon, and it stays out of the security review until something goes wrong. That is shadow AI. Thomas and I walk through an alternative: a private AI gateway that gives an organization visibility into how AI is being used without pushing teams off the tools they like or slowing them down. My part is how Scolta uses amazee.ai's private AI infrastructure to add secure AI capabilities across Drupal, Laravel, and WordPress, so the AI a site needs does not come with the governance gaps shadow AI opens. If this is a challenge your organization is facing, come find me after and we can compare notes.

Wednesday, September 30 Rebuilding the LMS Mid-Flight: A Drupal Success Story with AFT and AFL-CIO
  • Location: Mees Room I
  • When: 10:45-11:30 CEST
  • Speaker: Marcin Grabias

Rebuilding a live LMS is risky. Rebuilding it while it powers mission-critical training for organizations like the American Federation of Teachers and the AFL-CIO is even harder. This session takes you through that journey—from growing pains and technical debt to a fully reimagined Drupal-native solution—sharing the lessons learned along the way.

Inside the Pyramid - A path to faster, clearer Drupal testing

The test pyramid has been a cornerstone of software quality for decades, yet Drupal core has no formal guidelines instructing contributors how to write automated tests. This session will cover both the current state – discussing techniques to write faster tests – and how to change Drupal to make these improvements structural.

A joyful tour through the CLI now in Drupal Core
  • Location: Penn Room I&II
  • When: 13:40-14:00 CEST
  • Speaker: Moshe Weitzman

It finally happened! A CLI in Drupal core. With the help and blessing of the Drush maintainers, Drupal core has gained its own extensible CLI. Learn how to use it, and develop and test commands for it.

Client Spotlight Scolta: Drop-in AI Search Without a Search Server Kelly Booz Jeremy Andrews

What if you could replace Solr with something that runs in the browser, costs almost nothing, and delivers better results out of the box? Scolta is an open source search toolkit that does exactly that: client-side search powered by Pagefind, with an AI layer for query expansion and summaries.

How we made the biggest performance gains in a decade in Drupal core

Drupal 11.4 reduced database queries and cache I/O by around 50% compared to Drupal 11.0, as well as various front end performance improvements. This session will explain how we got there and give you tips for applying these techniques to your own site.

AI-Powered Site Building in Drupal: From Blank Site to Styled Pages in a Conversation Francesco Pesenti Francesco Quagliati

Building a complete Drupal site demands expertise across content types, taxonomy, menus, block configuration, and styling. What if a non-technical user could describe what they need in plain language and get back fully structured, styled pages, then refine everything through conversation?

Come Find Us

A lot of the work in these talks usually sits out of sight, in performance, testing, and the plumbing of AI workflows, so a week like this is one of the few times it surfaces all at once. If any of it is close to what you're working on, catch me or any of the team between sessions and let's talk. We would love to hear about the hard problems you're working to solve.

Metadrop: Managing untracked files in Drupal with File Inspector

Drupal Planet -

Content management systems include different types of files as part of the managed content. However, for several reasons, those files are not always tracked by the application and can accumulate and lead to certain issues. This article explores this problem and proposes File Inspector as a solution. The files that Drupal does not track

Any long-lived Drupal site, whether it stores files in a local folder or a remote bucket like Amazon S3, holds hundreds of files, and there is no easy way to see which ones Drupal still tracks and which it has lost sight of. The files come from four places: live content, leftovers from nodes deleted years ago, migration and backup residue, and direct uploads, such as a PDF dropped onto the server because it was faster.

This is a common problem in the sector, and it does not depend on the technology in use. Every content system faces it sooner or later. The root cause is two stores that must agree: the bytes in storage versus the database that is supposed to keep track of them. The moment both stores exist, they drift. It happens in three ways: records get deleted but the files stay, files get uploaded but never registered, and jobs fail halfway.

These accumulated unreferenced files are untracked files, a kind of dark data: information an organisation keeps but no longer uses.

The cost of untracked files…

Berliners blog: Generate Drupal local actions from Views configuration

Drupal Planet -

Generate Drupal local actions from Views configuration

On an editorial site, it is often useful to give articles, documents and other content types their own administration listings. Editors can then work with one type of content at a time, with an "Add Article" or "Add Document" button alongside the relevant list.

Maintaining a separate button definition for every listing means keeping the same relationship in two places. Whenever we add a listing or change which content type it shows, we need to remember to update its creation action too. This article shows how to avoid that duplication with a local action deriver.

When those listings are built with Views, their content-type filters already tell us which creation form belongs on each page. We can use that information to generate the buttons, keeping their definitions in step with the listings they belong to.

Illustrative mockups with example content. Each listing offers its own creation action.

A creation button for each listing

Drupal provides these buttons through local actions. To add one, we specify its label, where it links to and which page should display it. For an article listing, that could take a short YAML definition in listing_actions.links.action.yml, assuming the custom module's machine name is listing_actions:

listing_actions.add_article: title: 'Add Article' route_name: node.add route_parameters: node_type: article appears_on: - view.content.page_articles

Here, appears_on places the button on the article listing. The route name view.content.page_articles assumes that the View's ID is content and its page display's ID is page_articles, following the pattern view.{view_id}.{display_id}. Clicking it opens the node.add route, where the node_type parameter selects the article creation form.

We could add another entry for documents and continue in the same way for other listings. That is a good fit when each action needs its own wording or destination. If all the listings follow the same convention, though, we can get those values from existing configuration: the View identifies the display and content type, and the content type supplies its label.

A plugin deriver lets us build those entries from the existing configuration. It returns several plugin definitions that share one implementation—the same approach I described in my 2014 post about block derivatives. The early Drupal 8 code in that post is outdated, but the idea applies to local actions too.

Which displays qualify?

For this example, we will use a View named content, with a page display for each listing. To choose the right creation form, the deriver needs to know that a display lists exactly one content type. The configuration therefore needs to follow a few conventions:

  • Each eligible display overrides its filters and has a content-type filter named type_1.
  • That filter includes exactly one node type, is not exposed and restricts the whole listing. No OR group admits other content types.

The key type_1 identifies a particular filter in the View's configuration; the content type it selects has its own machine name, such as article. Your View may use a different filter key, for example type. To find it, export the View and look under display → your_display_id → display_options → filters in views.view.content.yml. Find the entry with entity_type: node and field: type, then use its key in place of type_1 in the PHP example. As written, the deriver expects that same key on every eligible display.

These constraints let the deriver read the filter straight from each display's stored configuration. It skips displays that inherit their filters; to support those as well, we would need to read their effective options through the Views display API.

The example also relies on a cache rebuild after configuration changes, so it fits a deployment workflow that imports configuration and then rebuilds caches. We will look at that requirement after the implementation.

Register the deriver

With those conventions in place, we can replace the individual action entries with one definition that points to the deriver. In an enabled custom module named listing_actions, put this in listing_actions.links.action.yml:

listing_actions.content_add: class: Drupal\Core\Menu\LocalActionDefault deriver: Drupal\listing_actions\Plugin\Derivative\ContentLocalActions

Local actions use YAML discovery, so this entry is how Drupal finds the deriver. The class property keeps core's LocalActionDefault as the implementation for every generated action. All we need to supply is the code that works out their labels and routes.

Read the displays and build the definitions

To load the View and its referenced content types, the deriver needs the entity type manager. The complete class uses ContainerDeriverInterface to receive that service from Drupal. Save it as src/Plugin/Derivative/ContentLocalActions.php inside the module so it matches the class named in the YAML entry.

Most of the work happens in getDerivativeDefinitions(). It loads the content View, skips displays that do not meet the conditions above and builds an action for each remaining display:

public function getDerivativeDefinitions($base_plugin_definition): array { $this->derivatives = []; $view = $this->entityTypeManager->getStorage('view')->load('content'); if (!$view || !$view->status()) { return $this->derivatives; } foreach ($view->get('display') as $display_id => $display) { if ($display['display_plugin'] !== 'page') { continue; } $options = $display['display_options']; if (($options['enabled'] ?? TRUE) === FALSE) { continue; } // Only use filters explicitly overridden for this display. if ($options['defaults']['filters'] ?? TRUE) { continue; } $filter = $options['filters']['type_1'] ?? []; $types = $filter['value'] ?? []; if (($filter['entity_type'] ?? NULL) !== 'node' || ($filter['field'] ?? NULL) !== 'type') { continue; } if (($filter['operator'] ?? NULL) !== 'in' || !empty($filter['exposed']) || count($types) !== 1) { continue; } $node_type = $this->entityTypeManager->getStorage('node_type')->load(reset($types)); if (!$node_type) { continue; } $this->derivatives[$display_id] = [ 'title' => $this->t('Add @label', [ '@label' => $node_type->label(), ]), 'route_name' => 'node.add', 'route_parameters' => [ 'node_type' => $node_type->id(), ], 'appears_on' => ['view.content.' . $display_id], ] + $base_plugin_definition; } return $this->derivatives; }

The array near the end of the method contains the same values as our first YAML example. The content type supplies the label and creation-form parameter, while the display ID determines where the action appears. Adding $base_plugin_definition carries over shared properties, including the action class we registered earlier.

Using the display ID as the array key also gives each action a distinct derivative ID. Drupal combines it with the base plugin ID, so the action for page_articles becomes:

listing_actions.content_add:page_articles

That ID identifies the action itself. Its appears_on route is still view.content.page_articles, and its destination is still node.add with the article type as a parameter—just as in the static definition.

Who can see the button?

Once Drupal has these definitions, it can decide which actions to show on a page. It does this by checking access to each destination route with its parameters. For the article action, that means checking whether the current user may open node.add for the article content type, separately from whether they may view the listing.

This is why the deriver contains no current-user permission checks. Drupal caches its definitions, so making discovery depend on the user who triggered it could leave other users with the wrong set of actions. Access belongs in the later step, when Drupal builds the buttons for the current page.

When the configuration changes

Caching also means that the deriver does not reread the View on every request. If a display's filter or ID changes, or a content type gets a new label, the stored action definitions need to be regenerated.

For this example, a full cache rebuild is the point at which those changes take effect. Rebuild after installing the files and after importing changed configuration, using Drupal's "Clear all caches" action at Configuration → Development → Performance or your environment's Drush cache-rebuild command. This refreshes both the definitions and the rendered output.

The same applies when editing the configuration through the UI. If those edits need to take effect automatically, the integration must respond to the relevant configuration changes, call clearCachedDefinitions() on plugin.manager.menu.local_action and invalidate the affected rendered output. Those handlers are not included in the accompanying class.

With this in place, adding another listing that follows the same filter convention also gives it the appropriate creation action after the next cache rebuild. There is no separate button definition to maintain.

berliner Thu, 09/24/2026 - 00:05 Tags

Pages

Subscribe to www.hazelbecker.com aggregator - Drupal feeds