Drupal's emerging agent interfaces are beginning to expose actions as well as information. MCPIO 1.0.0-alpha1 presents external Model Context Protocol clients with two entry points, search and execute, through which they can discover and invoke a wider set of Drupal operations. WebMCP User Forms takes a different route, adding WebMCP-style tool metadata to Drupal's login, password-reset, and registration forms so browser agents can identify their inputs more explicitly. These are different interfaces, but both make capabilities that were designed primarily for people or Drupal code more legible to automated actors.
Once a capability becomes callable, the harder question is not simply whether an agent can find it. Will Huggins' argument about Drupal publishing capabilities puts authentication, permissions, workflow, guardrails, and controlled context alongside the interface itself. In that model, an agent-facing tool should not create a route around Drupal's existing governance controls; the authority to perform an action still has to come from an identified actor with defined access.
The current projects do not establish one settled architecture for doing this. MCPIO remains an alpha release and is not covered by Drupal's security advisory policy, while WebMCP User Forms is also an alpha project outside that coverage. MCP, WebMCP, Tool API, and other agent-facing approaches also operate at different layers, from external protocol clients to capabilities exposed inside a browser. That distinction matters because making an operation discoverable is not the same as deciding who may execute it.
Issue 36 of Editor's Pick looked at a broader requirement for machine-facing websites: meaning must be explicit, access constrained, and important rules represented in ways software does not have to infer from prose. The next question is narrower. As Drupal makes more capabilities available to agents, interface design and permission design begin to meet at the same boundary: which actor is represented, which actions that actor may invoke, and which Drupal controls remain in force when the request comes from software rather than a person. The implementations are still emerging, but that authority boundary is becoming harder to treat as a secondary concern.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
This issue of Editor’s Pick was written and curated by Allen Jason.
In the previous post in this series, I described how we rebuilt our page templates with Layout Builder. I ended that post by mentioning that templates are less suitable when the page hierarchy must be derived from the data itself.
To explain that part of the rebuild, it helps to look at a more basic change. In the Drupal 7 site, an imported data object and the page that presented it were the same node, whereas the rebuilt site stores them as separate entities.
berliner Fri, 09/11/2026 - 11:07 TagsOn today's show we are talking about Site Templates, What they do, and How you can use them with guests Tim Lehnen & Adam Globus-Hoenich. We'll also cover Haven as our module of the week.
For show notes visit: https://www.talkingDrupal.com/569
TopicsWebinar: Drupal Canvas and Agentic Content Management: What Enterprise Teams Need to Know Drupal Site Templates Tim's book - Fog & Fireflies
GuestsTim Lehnen - @TimLehnen hestenet
Adam Globus-Hoenich - @PhenaProxima phenaproxima
HostsNic Laflin - nLighteneddevelopment.com nicxvan Stephen Cross - SecondSginalMedia.com [stephencross]](https://www.drupal.org/u/stephencross) Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)
Module of the Week CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Haven - Site Template - Designed for non-profit sites, this template features a bright, warm design that can be adapted for many use cases. It comes pre-confifgured with blog, projects and people profiles, as well as newsletter signup, donation add-ons and more.
Register for our next webinar to see a live demonstration of Centarro Bootstrap.
Every new theme for a Drupal Commerce project starts with the same sequence: define your colors, configure button styles, set typography, style your forms, change icons, and then wire all of it into whatever page-building paradigm Drupal currently offers.
After twelve years, our front-end team accumulated a long list of friction points and recurring tasks. Centarro Bootstrap is the result of addressing all of them in a single, reusable foundation. What used to take weeks of custom theming can now be accomplished in hours.
The problem Centarro Bootstrap solvesBeyond making it faster and simpler to complete repetitive theming tasks that every custom Drupal website must perform, Centarro Bootstrap also helps with dynamic page layouts.
Drupal has gone through several iterations of page builders, both as contrib modules and part of Drupal core. Canvas is the current tool, which brings a Figma-like experience. Users can place components directly on a page, compose layouts visually, and see immediate results. Content teams can create single-use content straight from the interface.
Read moreOn a recent project, I was struck by how the content editors used spreadsheets to manage their content. This wasn't just as a planning tool in the early stages; they had spreadsheets which essentially mirrored the content in Drupal, and this is where they kept track of who was responsible for sign-off on a piece of content, what stage it was at, and so on.
Leaving aside for a future post or many the matter that if editors are needing to use spreadsheets to manage their content, it doesn't speak well of the 'M' part of the CMS and that there are surely things we need to improve in Drupal, one thing I noticed was how content was listed.
The main identifier of content, the first column in the spreadsheet, wasn't the title, or the node ID, but the path. To these editors, the path was the starting point, it represented that piece of content.
This is completely add odds with how Drupal treats paths. Paths in Drupal are like an afterthought: tacked onto entities as second-class citizens. They're not even shown in the content admin pages, you're left to discover them for yourself by hovering over the content link.
But what if we could change that, and put path aliases first? What if we could make Drupal list content in the same way that these users have in their spreadsheets? It would be a first step in providing the sort of content overview and administration tools that Drupal is currently lacking for these users. Other things are needed too, such as a sign-off user content, and more complex statuses. But paths are the starting point.
Unfortunately, the flexibility of Drupal's path system is actually a problem here: paths aren't just for entities, and an alias can be for any system path. So there's no connection in the database from the path alias to the entity it points to, and there's nothing on the entity either: the path alias field you see on a node is a computed value, obtained by querying the path_alias table for the node's canonical path.
Of course, this doesn't stop SQL: you can join two tables on anything, and Views provides a 'join' plugin type precisely for these sorts of weird cases.
So we can define Views relationships from the path_alias entity type to all content entity types, using our special join plugin. The join clause then looks like this for nodes:
... JOIN node ON SUBSTRING(path_alias.path FROM 1 FOR 5) = 'node/' AND SUBSTRING(path_alias.path FROM 6) = node.nidWhat that's saying is that we only join if the path alias's real path starts with 'node/' and we join the numeric suffix to the node table row of the same value. We need the first part so that we don't join an alias for 'media/42' to node 42.
With this, we can make an admin view of nodes listed by their path aliases, with all the same features as the default Content admin view:
And the wrapped up result is the Path Alias Views module, which provides the integration to show path aliases in Views: fields, sort orders, and filters.
The Views relationship is generalised to work for any content entity type that has a canonical path of the form 'something/ID'. If your custom entity type does something weird with its canonical paths (such as include the ID of a parent entity; I've done that myself with custom entity types), then you can use hook_views_data_alter() to change the relationship from path_alias entities to your entities, so that it uses your own custom Views join plugin.
The view shown in the screenshot is installed as default config, and if you also install the Client-side Hierarchical Select module, a more souped-up path component filter allows you to select the path prefix to filter on one path component at a time.
This can be used as a drop-in replacement for the default core Content Admin view, though of course it will only show nodes that have a path alias.
I'm sure there are other ways of showing paths. Replacing the URL aliases admin page with a view would be one. Reverse relationships from entity types to path aliases would open up other possibilities too. I'll be interested to see what people come up with this: do please let me know on Mastodon, in Slack, or in MRs in the issue queue.
Do you need help with doing something unspeakably twisted with Views queries? I've had plenty of experience with this sort of customisation, and I'm available for hire - contact me!
joachim Thu, 10/09/2026 - 12:56 TagsOpen Source projects have spent decades asking companies to contribute. Projects should also give buyers the information they need to reward the companies that do.
Any Open Source project with a commercial or institutional funding ecosystem should publish an official contribution record: who contributes, how much and over what period, what kind of work they do, which parts of the project they work on, and, where disclosed, who paid for the work.
The test for a good record is simple. A buyer should be able to answer three questions in about a minute: does this vendor contribute at all, how much do they contribute compared to other vendors, and do they work on the parts of the project I care about?
Contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price. It matters because some buyers want the money they already spend on Open Source services to help maintain the software they depend on.
Vendors that pay people to do that work carry costs that others avoid, and some of those costs may appear in their rates. A price comparison that ignores those costs can put contributing vendors at a disadvantage. I've argued that procurement should score contribution alongside price. APELL, the European Open Source Software Business Association, has also asked the EU to consider a provider's record of Open Source contribution.
Vendor claims are hard to verify and compareSay you need a vendor for your Drupal site, your Kubernetes cluster, or whatever Open Source software you use, and two firms bid. Both say they're deeply involved in the project, and both might be telling the truth by their own definition of "involved".
Without a project record, verifying those claims often means reconstructing each vendor's contribution history yourself.
The code repository seems like the obvious place to start, but even counting commits by vendor is not simple. A project has to connect individual contributors to the organizations that employed or funded their work, and those relationships can change over time.
More importantly, Open Source contribution can include documentation, support, event organization, governance work, promotion, and more. Much of that work happens outside the code repository or isn't recorded in a form a buyer can easily interpret.
Projects decide which contributions matterDrupal has tracked contribution credits since 2015, following a method I proposed in 2014 and now governed by the Drupal Association. Its system records more than code and gives credit not only to individual contributors, but also to the organizations and customers that fund their work.
Not every contribution counts the same. A contribution to Drupal Core or a strategic initiative earns more credit than one to a module that few sites use, and work on contributed projects counts for more when more sites depend on them.
Raw contribution data does not tell buyers which work matters most to the project. The project has the context to decide what advances its priorities and how different contributions should be weighted. Its record should publish those rules, link to the underlying contributions, and explain how mistakes or disputes are corrected. Buyers can then decide how much that record matters for a particular purchase.
Drupal has a strong foundation, and credits feed the Drupal.org marketplace where buyers compare agencies, but I'm not sure we could answer all three questions in sixty seconds today. We still have work to do to make the record easier to find, understand, and compare.
Projects can start with a simple recordNot every project needs a system as elaborate as Drupal's. A small project could begin with a short list: who its recognized organizational contributors are and what they worked on. A text file in the official repository can be enough for a first version.
More complex ecosystems may need separate categories or weighted comparisons. Whatever form it takes, the record has to be easy to find and quick to use.
So if you maintain an Open Source project with a commercial or institutional funding ecosystem, start publishing a contribution record and improve it over time. If you buy services built on Open Source, ask for the project's contribution record. Decide at the start how contribution should count in your purchasing decision, then check bidder claims against the record. If you fund Open Source, use the record to find contributors working on the parts of the project you want to support.
Where buyers can consider contribution, I expect projects with clear records to see more commercial opportunities go to their maintainers than projects that rely on appeals alone.
Special thanks to Henry Poole for his contributions to this blog post, and to Sachiko Muto, Tiffany Farriss, Tim Lehnen and Amandine Le Pape for their review.
The European Accessibility Act came into force in June 2025, raising WCAG AA compliance from a best practice to a legal requirement for most web projects in the EU. Among the criteria that standard covers, WCAG 3.1.2 is one of the most consistently missed in editorial workflows: it requires that any change of language within a page be identified in the markup. Content that mixes languages is nearly universal, since any site writing in Spanish will borrow English terms, and any site writing in English does the same in the other direction. That language-mixing fails this criterion silently, and most sites have no mechanism in place to fix it. Drupal 10 and later ship with a native solution in Core that requires no extra modules, and the gap between sites that comply and sites that fail is almost always just a matter of awareness.
The accessibility gap: foreign wordsAccessibility now carries weight on two fronts at once. It improves SEO, and it is a legal requirement. Since the European Accessibility Act came into force in June 2025, meeting WCAG level AA stopped being a good practice and became a legal must for any web project.
One of the most frequent mistakes when authoring content sits right at this intersection: using a word or expression from another language without identifying or marking it semantically. The most common case is writing in your main language and reaching for loanwords. A text in Spanish borrows…
Druxt's Drupal module carries a list of twelve JSON:API resources it answers for. It's been the same twelve since 2021, hardcoded in a PHP array, and changing it has meant carrying a patch.
1.3.0, tagged today, makes that list yours. The twelve stay exactly as they are, so nothing a site exposes changes when it updates. What is new is being able to choose, and the first thing I would choose is the one my frontend has always had to guess at: the toolbar an administrator configured for a text format.
A CORS default ships in the same release. If you keep a proxy rule in front of your frontend so that authenticated calls succeed, this is the release where you delete it.
As I've been experimenting with different AI models, I've observed varying behaviors. For example, I like the price point and the reasonable output from GPT-6 Luna. On Reddit, many people recommend running it at max, so I tried it. I assumed Luna Max would yield better results. Instead, it would take an unreasonable amount of time to respond, with not much better code. Because I am using AI as a coding assistant, speed matters. Luna Max may be better suited for autonomous coding agents.
I'm starting to feel like I have to track different models and modes, as if I were on a dating app looking for someone I'd be compatible with. Yes, I am humanizing AI, even though it is just an advanced pattern-recognition machine. Still, I recently discovered that AI can get stubborn and enter "Brat mode."
Brat mode
On one of the many AI-related podcasts I was listening to, someone shared a tip: if your AI gets stubborn and frustrating, clear the context and start a new session. Their theory was that the AI gets locked in a negative feedback loop and, instead of trying to please you, it leans into frustrating you. I am calling this "Brat mode."
I ran into "Brat mode" while trying to fix a simple report with duplicate records that needed a minor query tweak and some display adjustments. My prompt was matter-of-fact, but the AI would still make one change and then revert another. I caught myself asking the AI, "Why did you revert our recent changes? Please restore them," and the AI failed to explain or fix the problem. It felt like I was dealing with a stubborn child who was enjoying my frustration. Yep, I got frustrated. Fortunately, I knew better than to play this game, so I had the AI create a slightly better prompt, started a new session using the improved prompt, and the AI fixed the issue immediately.
This experience with AI's "Brat mode" made me start to...Read More