So, last week was quite a big week, really. Both for me personally, more of that in a moment, and for the Drupal project as a whole, I think.
09 Oct 2026
Drupal.org aggregator
The Drop Times: “Drupal Isn’t About Quick Wins”: Henadzi Koltun on Sustainable Growth
Henadzi Koltun argues that Drupal's value lies in durable engineering rather than short-term gains. He discusses when headless architecture is justified, why AI still needs human oversight and how accessibility becomes an organisational responsibility.
09 Oct 2026 11:50am GMT
Metadrop: How to fix Drupal redirect chains automatically with Redirect Audit
Why Drupal sites accumulate hundreds of redirect chains
A Drupal site with many years of life, one or more migrations, or frequent content changes accumulates redirects automatically. Every alias change and every moved page leaves one behind, until there are hundreds or even thousands of them. A new project gets there too once content starts to be created, redirects added, and URLs moved.
The problem is silent. Nobody decides to create a redirect chain; chains appear when redirects pile up on top of each other over time. Reviewing them manually is unfeasible because of the time it would take, so they stay. These situations usually surface in audits run with different tools: until that moment they go unnoticed.
Redirect chains and loops cost performance, SEO, and dead pages
A redirect chain is several hops in a row: a → b → c → d. Each additional hop increases navigation latency for users and makes crawling harder for search engines. Keeping every redirect at a single hop contributes to better SEO.
Googlebot follows up to 10 hops in a chain before giving up, but …
09 Oct 2026 11:40am GMT
The Drop Times: Drupal Security Team Confirms Four Full-Member Promotions
Pierre Rudloff, Joseph Zhao, Bram Driesen and Swan Kalata have moved from provisional to full membership of the Drupal Security Team. Their public records show experience in vulnerability reporting, fixes, advisory coordination, core contribution and community leadership.
09 Oct 2026 7:31am GMT
08 Oct 2026
Drupal.org aggregator
Talking Drupal: Talking Drupal #573 - Off The Cuff #13
Today we are talking about Drupalcon Rotterdam, Canvas and evaluating modules. We'll also cover Revision Graph as our module of the week.
For show notes visit: https://www.talkingDrupal.com/573
Topics
- DrupalCon Rotterdam recap
- AI summits and training
- FrankenPHP app servers
- Driesnote highlights
- Advocacy and WordPress
- Rosetta Sprint and MCP
- Canvas multilingual and headless
- 3Frameworks And Voiceover
- Canvas And SDCs
- Headless And Signage
- Drupal 12 Beta Testing
- Rector And Deprecations
- PHP 8.5 Requirements
- Rethinking Module Evaluation
- AI And Commit Scale
- Module Discoverability
- 0Distributions Versus Recipes
Resources
Hosts
Nic Laflin - nLighteneddevelopment.com nicxvan Martin Anderson-Clutz - mandclu.com mandclu Tim Sharp - tea-sharp
MOTW Correspondent
Martin Anderson-Clutz - mandclu.com mandclu
- Brief description:
- Have you ever wanted to see a node's revision history drawn like a Git graph, with each translation as its own branch? There's a module for that.
- Module name/project name:
- Brief history
- How old: created in Sep 2019 by Shibin Das (D34dMan) of Factorial
- Versions available: 4.0.0, which works with Drupal 11 and 12, and 3.1.1 for Drupal 10 and 11
- Maintainership
- Actively maintained, 4.0.0 landed in mid-August after two alphas the same week
- Security coverage
- Test coverage
- Documentation: a solid README plus in-depth technical and revision-model docs in the repo
- Number of open issues: zero open issues
- Usage stats:
- 242 sites
- Module features and usage
- With the module installed, every node gets a Revision Graph tab, right next to the core Revisions tab
- One row per revision, one lane per language, so you can see when a translation branched off and how it's evolved since
- Each dot tells you two things: a solid ring means that revision was live at some point, a dashed ring means it's a draft that never was, and a filled center means it's what that language is serving right now
- It works with Content Moderation if you have it, showing your workflow states as text badges with whatever names your site uses, and adapts cleanly when you don't
- Reverts, and edits made from the published version while a draft is pending, show up as forks instead of a straight line
- Under the hood: Drupal doesn't actually store which revision a new one was derived from, so the module adds a small base field that records it at presave
- Older revisions don't get backfilled, on purpose, since reconstructing that would mean guessing. Those edges are inferred, and the graph draws inferred edges differently from recorded ones, so it never implies more precision than it has
- So on an existing site, make sure you run drush updb after enabling it
- Ships a distinct color for all 95 language codes Drupal knows, so it looks good out of the box, but you can override a lane's color or the fallback palette in config
- The graph loads in pages as you scroll, so long histories render quickly, and it's keyboard navigable, ARIA-labelled, and works in forced-colors mode
- Great for editorial teams on multilingual sites, and handy for compliance or auditing when you need to answer "what was live, and when?"
- Caveats: it's nodes only, and for obvious reasons a user will need the "view all revisions" permission to see the graph
08 Oct 2026 6:20pm GMT
Drupal blog: State of Drupal presentation (September 226)
This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
More ways to reach more people
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
Opening Drupal's capabilities to other software
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
Talk louder about Drupal
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
08 Oct 2026 3:23pm GMT
ImageX: Driesnote Rotterdam 2026: The Future Drupal Is Sailing Toward
Yet another amazing DrupalCon Europe has come to an end, leaving us with unforgettable memories. This time, we gathered in a city where futuristic architecture meets historic streets, home to Europe's largest port and an absolutely unique food market. Rotterdam is a city that has embraced the future and innovation and is sailing towards it with all sails set.
08 Oct 2026 3:01pm GMT
Drupal Mountain Camp: Sponsorship for Mountain Camp 2027 Is Now Open
Sponsorship for Mountain Camp 2027 Is Now Open sinduri
Sponsorship for Drupal Mountain Camp 2027 is now open. On March 2-4, 2027, the camp returns to Davos Congress for its sixth edition, ten years after the first gathering in 2017.
This year's theme is Humans with AI in the loop. Over three days of talks, hands-on workshops and contribution sprints, we look at how AI is changing the way we build software, why digital sovereignty matters, and where open source fits in.
The camp brings together people who care about the open web: developers, designers, AI practitioners, public-sector teams and open source communities from Switzerland and beyond.
Why Sponsor Mountain Camp
As a sponsor, you have a visible place at the camp and time to talk with the people who attend. Sponsoring lets you:
- Share your tools, services and expertise with people who build with open source and AI.
- Meet developers and technical leads in person, over three days.
- Connect with attendees between sessions and at the social events.
- Support an independent, community-run event that has brought people together since 2017.
We welcome sponsors of any size and from any field who want to support an open, independent web.
Sponsorship Packages
There are four packages: Platinum, Gold, Silver and Bronze. Places are limited, with 3 Platinum, 5 Gold and 8 Silver packages available.
Depending on the package, benefits include:
- Introducing a keynote speaker on stage
- A promotional video at the opening and closing ceremony
- An exhibition stand
- Job listings on the website and at the venue
Every package includes conference tickets and a logo on our sponsor page.
If you would like to support a specific part of the camp, you can also sponsor the opening reception, a social event, the session recordings, the coffee breaks or a diversity scholarship.
Become a Sponsor
You can find all packages and what they include on our sponsorship page.
To become a sponsor or ask a question, write to us at info@drupalmountaincamp.ch.
To stay up to date, subscribe to our newsletter and follow us on Mastodon, Instagram, Bluesky and LinkedIn.
We look forward to hearing from you.
08 Oct 2026 2:46pm GMT
Matt Glaman: SDCs, Canvas, and the agent skills that build with them
My DrupalCon Rotterdam talk moved from MCP to the CLI. How Canvas Tools and agent skills let a coding agent build Canvas pages through Drush, and what's still rough.
08 Oct 2026 1:00pm GMT
07 Oct 2026
Drupal.org aggregator
Dynamosys Insights: Google’s AI Content Update: Why Fact-Checking Matters for SEO
Google has updated its guidance to emphasize human review of AI-generated content. Here's what changed, what it means for SEO, and what website owners should check before publishing.
07 Oct 2026 9:53pm GMT
Acquia.com - Drupal Blog: Vibe Coding Drupal: The Pragmatic Middle Path
Vibe coding or AI rejection? Learn the pragmatic middle path for Drupal teams: what to delegate to AI, when, and how to verify it.
07 Oct 2026 8:20am GMT
Dries Buytaert: State of Drupal presentation (September 2026)
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
More ways to reach more people
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
Opening Drupal's capabilities to other software
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
Talk louder about Drupal
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
07 Oct 2026 7:50am GMT
The Drop Times: AI Neuron Connects Drupal AI With PHP Agents and Workflows
Drupal AI can keep control of providers and model settings while Neuron handles agents and workflows. The new bridge also brings Neuron objects into Drupal's plugin system.
07 Oct 2026 7:11am GMT
Gspikes: Drupal Multilingual: Migrating Translations Without Losing Them
One node, many translations: how Drupal's translation model works, why Drupal 7 migrations break it, and the configuration that has to be right afterwards.
07 Oct 2026 7:00am GMT
webchick: The October #DrupalOffTheIsland challenge
During the Driesnote at DrupalCon Rotterdam, one of the closing points was that Drupal has evolved light years beyond its reputation. And that's true. But it's also true that there is a whole world of people out there who've never heard of Drupal, and we need to talk about it differently to them than we do when talking amongst the Drupal-aware.
Enter The October "Off the Drupal Island" challenge.
The gist: During this, the spoooookiest month, go out to a local event (meetup, hackathon, etc.) where Drupal isn't, and no one has ever heard of "Drush" or a render array. ;) And ideally, where their local community presence is larger than ours.
For example:
- AI events
- JavaScript events
- WordPress events
- ...
NOT to pitch Drupal! To learn, quickly, and at scale. Be curious. Talk to people. Find out more about what they're building, where they're struggling, and what they wish was better.
Then, post a mini "field report" about your journey to this issue (there's a handy template there if you like).
We'll circle back on these learnings in a November AI Learners Club meeting, and strategize what kind of demo(s) we think would resonate best with these audiences, reflecting back their words and their use cases and pain points.
Then, we get louder about Drupal to them. ;) #DevRel at global scale.
Note: If you need extra incentive, perhaps because the idea of talking to strangers is slightly terrifying to you ;) note that this community research work qualifies you for credits under the new Drupal Advocacy program. \m/
For discussion, see LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7513498359781826560/
07 Oct 2026 6:58am GMT
06 Oct 2026
Drupal.org aggregator
rachel_norfolk: DrupalCon brings love in every drop
DrupalCon brings love in every drop
- Read more about DrupalCon brings love in every drop
- Log in with GitHub or Google to post comments. Or, if you came across this post via Mastodon, just reply there!
06 Oct 2026 8:19pm GMT
Aten Design Group: Freedom with the form Attribute: More Flexible Drupal Views Exposed Filters
Freedom with the form Attribute: More Flexible Drupal Views Exposed Filters

Drupal Views exposed filters tend to accumulate controls.
A basic search form may start with a keyword field and a few filters. Add sorting and an items-per-page selector, and Drupal naturally renders everything as part of the same exposed form.
That makes sense structurally. It does not always make sense visually.
Sorting often belongs above the results. Items per page may belong next to pagination. Filters might live in a sidebar or drawer.
The HTML form attribute gives us a simple way to separate those concerns.
Form controls do not have to live inside the form
Most of the time, an input belongs to the <form> that contains it.
But HTML allows controls to explicitly reference a form by ID:
<form id="search-form"> <input name="keywords"> <button type="submit">Search</button> </form> <select name="sort" form="search-form"> <option value="date">Date</option> <option value="title">Title</option> </select>
The <select> can live anywhere in the document and will still participate in search-form when it is submitted.
That is particularly useful with Drupal Views exposed filters.
Instead of forcing every exposed control into one visual group, Twig can put them where they make sense:
{{ exposed|without('sort_by', 'items_per_page') }} <div class="results-sort"> {{ exposed.sort_by }} </div> {{ rows }} <div class="results-footer"> {{ pager }} {{ exposed.items_per_page }} </div>
Then a form alter can associate those controls with the original exposed form:
/** * Implements hook_form_views_exposed_form_alter(). */ function example_form_views_exposed_form_alter( array &$form, FormStateInterface $form_state, string $form_id, ): void { foreach (['sort_by', 'items_per_page'] as $key) { if (isset($form[$key])) { $form[$key]['#attributes']['form'] = $form['#id']; } } }
Drupal still owns the form. The browser still understands which controls belong to it. The template gets considerably more freedom.
The same technique can help with controls in sticky toolbars, dialog footers, complex search layouts, or other interfaces where form controls need to appear outside their natural DOM container.
There are a few tradeoffs
Moving controls outside the form changes more than layout.
JavaScript that relies on closest('form') will no longer work. CSS such as form select will not match detached controls. Events from those controls also do not bubble through the form element because the form is no longer their DOM ancestor.
The form ID also becomes part of the implementation contract, which matters when multiple Views or exposed forms appear on the same page.
These are manageable constraints, but they are worth documenting.
The form attribute gives us form ownership, not DOM nesting.
Maybe this should be contrib
There is also a small but interesting Drupal contrib opportunity here.
A module could allow site builders to configure which exposed Views elements should receive a form attribute and which should autosubmit.
The theme would remain responsible for placement. The module would simply provide the form association and optional behavior.
That could eliminate a recurring bit of project-specific PHP and JavaScript while relying primarily on native browser behavior.
For a relatively obscure HTML attribute, form opens up a useful amount of flexibility in Drupal Views. It lets the markup follow the interface instead of forcing the interface to follow the form.
For additional information on the form attribute, checkout the docs.

06 Oct 2026 7:19pm GMT
