Drupal.org aggregator
Beta 5 release of Drupal AI Context Beta 5 of Drupal AI Context , also known as Context Control Center (CCC), is now available. This is expected to be the final beta release, and an RC 1 release should be available soon. CCC helps Drupal sites provide governed, reusable context for AI workflows and agents, from brand voice and editorial standards to organisational knowledge and governance rules. This gives AI systems access to more structured and relevant information while allowing teams to manage that information centrally. Following the beta 4 release , beta 5 has been shaped by extensive community testing and an expanded scope. The community testing revealed refinements for a more intuitive user experience, and several features earmarked for 1.1 have been brought forward into 1.0.
09 Sep 2026 6:45am GMT
Drupal.org aggregatorAs 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
08 Sep 2026 9:37pm GMT
simplytest.me had been sitting in the back of my mind for a long time. I knew it was unstable, and that release information kept falling out of date. It was a constant battle that always needed another round of maintenance, and it kept sliding.
Then Ryan Szrama wrote about someone cold calling the Centarro phone number looking for a way to sell online. Commerce Kickstart already did what the caller needed, so instead of selling him an engagement, Ryan pointed him to simplytest.me to try it.
08 Sep 2026 1:00pm GMT
Get your content cited by AI engines and get back that traffic you just lost. Read this AEO/GEO playbook to find out how.
08 Sep 2026 11:05am GMT
In April 2025, there was no Top Tier badge in the plan. There was a conviction that Drupal needed coordinated investment in AI. Today, Dropsolid's recognition makes that choice visible.
Dropsolid is now listed as a Top Tier Drupal Certified Partner. I am genuinely proud of that. Not simply because we have reached the highest level in the Drupal Certified Partner Program, but because of what this recognition measures.
08 Sep 2026 10:57am GMT
The code of a Drupal or Backdrop site is the part everyone rebuilds, upgrades and throws away with a light heart; the uploads are the part nobody plans for, and they are the only part which cannot be downloaded again tomorrow. On a BOA server the files and private directories live outside the codebase, in the account's own store, with two symlinks in the site pointing there, so a platform rebuild, a core update or a move to a newer codebase never touches them, a clone gets a real copy of its own, a rename carries them along, a restore sets the old content aside instead of deleting it, and a delete moves the site's uploads into a dated archive, never removes them, and never blocks reusing the name. Every move is dry-run first, refused when the disk is short, and written down; the one thing the machine will not do on its own is delete your uploads, and the one thing it cannot stop is the store growing.
08 Sep 2026 10:54am GMT
Drupal.org aggregatorcomposer drupal-patch-check
A composer plugin created to make it easy for humans to upgrade their patched Drupal websites.
If you ever wanted to know if you still needed that patch after an update, or if your custom patch would still apply to the new version of the module, or if your 15 levels patch tower still applies after the update, this is the tool for you. Install the composer plugin and get started using the remote API.
theodore
07 Sep 2026 10:00am GMT
Debate over open-weight AI moved from model releases into policy at the G20 technology meeting on 1 September 2026. Meta chief executive Mark Zuckerberg argued against broad restrictions on open-weight models, while the United States urged governments to avoid sweeping new AI rules. The discussion turns "open" from a technical distribution choice into a term that governments and technology companies are also using when arguing about access and control.
That distinction became more concrete two days later. The Institute of Foundation Models released K2 Horizon, a family of six AI models for which it published weights, code, training data or detailed data-construction information, intermediate checkpoints, configurations and other parts of the training lifecycle. Meta's Muse Glimmer, released on 10 August, makes its model weights available under the Apache 2.0 licence, but the K2 release illustrates how many additional components may sit behind a broader claim of openness.
The Open Source Initiative provides a more specific framework through its Open Source AI Definition. It defines open-source AI through the freedoms to use, study, modify and share a system and says the preferred form for making modifications must include information about training data, the relevant source code and the model parameters. Downloadable weights can therefore provide meaningful control without, by themselves, establishing that every part of an AI system is open source.
The same problem appears when AI is placed inside a wider digital service. An open-weight model can sit behind a proprietary application, while an open-source content platform can depend on a closed model service. Hosting, search, analytics, organisational data and integrations can each introduce separate dependencies, so openness at one layer does not establish the status of the whole stack.
Drupal provides a useful comparison because its openness applies to a different technological layer. Drupal.org describes the platform as open source, with publicly inspectable code, freedom to modify the software and no single commercial provider controlling the platform. Those freedoms apply to the content-management platform; they do not make an attached AI model, hosting service, analytics system or external integration open.
Three weeks ago, Editor's Pick asked how open-weight AI changes the control available to organisations that depend on it. The G20 debate and K2 Horizon release sharpen that question: control has to be examined layer by layer rather than inferred from one label. For Drupal teams evaluating AI services, that means considering the model, code, data, hosting, integrations and publishing system separately and asking what can be inspected, modified, moved or replaced.
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 Kazima Abbas.
07 Sep 2026 8:59am GMT
Drupal.org aggregatorWith some recent security advisories for Cross Site Scripting (XSS), it feels like an opportune time to remind those who author Twig templates for Drupal:
If you're using Twig's |raw filter, you're probably doing it wrong
Let's cast our minds back to Drupal 7. A time before twig. We had .tpl.php templates with PHP template as the default templating engine. Every variable available in your template had to be carefully sanitized before being printed to avoid XSS.
This meant remembering to call check_plain or check_markup in preprocessing hooks on every variable.
Not surprisingly security advisories for Cross Site Scripting (XSS) were the the number one vector in Drupal contrib security advisories for Drupal 7 and below.
The release of Drupal 8 saw the adoption of Twig as the default templating engine. With auto-escaping by default, Twig promised to provide enhanced security against XSS vectors. No more needing to remember to call check_plain or check_markup - any variable available to Twig was escaped on output!
Which brings us to using the |raw filter. When you use it you're saying to Twig - actually, don't auto-escape this variable, I know better.
But there are very few cases where this is the correct approach.
And in reaching for |raw you're most likely opening an XSS vector.
If you're looking at a template and you're finding that a variable is being double-escaped. E.g. instead of Mathematics & Data Science you're seeing Mathematics & Data Science you might be tempted to reach for raw to fix it.
Instead you need to examine where the value is coming from.
If you're using Drupal's field formatters, you're unlikely to get into this scenario. The most likely cause is you're accessing raw field values.
E.g. something like $node->field_body->value in either a preprocessing hook or some ungainly Twig expression {{ node.field_body[0].value }}.
Check the type of the field. If its in the Text family, e.g. Text, Text (long), Text (long, with summary). You should instead be using the processed property - $node->field_body->processed. This has already been sanitized and is flagged as safe to Twig. Anything flagged as safe bypasses auto-escaping.
If you're doing something custom, like in a configuration form or similar, lean on the TextFormat form element - '#type' => 'text_format'. This gives you a value and format pair. You can use this with the '#type' => 'processed_text'render element and again, the returned value is already marked as safe.
Failing that, if you want a limited set of HTML tags to be allowed and don't have a filter format to use with the ProcessedText element, you can use a #markup render array. E.g instead of printing a string, use ['#markup' => $the_string] - this will go via Xss::filter with the admin tags list. It will allow through some tags, but will strip out those that can lead to XSS.
|rawSo in summary. If you find yourself reaching for the |raw filter, stop. Instead lean on ProcessedText and pass a format, either one you define or one that the users chooses. Or failing that, use ['#markup' => ...].
Perhaps for some homework, go and check your themes and make sure you don't have any use of raw. Remember to follow the procedure for reporting a security issue if you find anything in a theme with security team support.
06 Sep 2026 11:00pm GMT
Rebuilding a data-driven Drupal site: Page templates with Layout Builder
In the previous post in this series, I described how we migrated existing page elements from Panels to Layout Builder.
Pages on this site are assembled from configurable page elements implemented as block plugins. These elements display data managed by an external system. Drupal stores their arrangement and configuration, but not the underlying data.
berliner
06 Sep 2026 7:59pm GMT
Drupal 11 is on 36% of reporting Drupal sites - and climbing at roughly half the speed Drupal 10 managed at the same age. On 9 December 2026 Drupal 10 reaches end of life, and the share of the Drupal web running unsupported code nearly triples overnight. The live numbers, the method, and what the curve actually says. Updated quarterly.
06 Sep 2026 4:01am GMT
Drupal.org aggregatorAuthor: Will Huggins
Imagine asking an AI assistant:
"Show me waterproof jackets under £150, in size M, available for delivery tomorrow".
Today, the assistant might search the web, read several retail websites and summarise what it finds. But what if, instead of reading pages, the agent could ask retailers directly which products matched those requirements?
With that information, you could fast-track your shopping journey and ask:
"Add [my chosen product] to my basket"
The important change here isn't the chatbot; it's what sits behind it. A traditional website can tell an AI agent what products it has and provide the details. Tomorrow's website will give the agent a controlled way to buy it.
That is the shift from publishing pages to publishing capabilities. It fundamentally changes what we expect a CMS to do.
Ever since the early days of the internet, content management systems have had a fairly straightforward job: someone creates a piece of content, the CMS publishes it as a page, a person finds that page, and then reads it and decides what to do next.
Over time, CMS capabilities developed around improved findability of content and the experience humans have when they land on a page. AI agents are now changing that equation, introducing a different type of interaction that moves beyond pages altogether, in search of capabilities that solve a problem rather than pages to read.
Take that same retailer from the jacket example. Its website contains thousands of pages describing products, categories, delivery and returns information, promotions, and offers. That information is useful to both human and AI visitors. But the retailer doesn't only have information, it offers services too: searching products according to particular requirements, comparing specifications, checking availability, calculating delivery, adding products to a basket, and buying them.
The focus is on wrapping those capabilities in an interface that optimises the customer's experience and drives greater conversion. Those 'wrappers' are navigation menus, search boxes, filters, buttons and checkout flows that guide someone towards that conversion target.
Think of an AI agent less like another customer and more like a personal shopper acting on their behalf. Or, perhaps, interacting directly with the shop's warehouse rather than the shop staff.
The visiting customer may care about the photography, the brand story, the layout, and the overall shopping experience. And whilst these elements remain vital in building trust with a potential customer, the personal shopper has a different job. They need to understand what the customer wants, quickly identify suitable products, check availability, compare options and, if instructed, complete the purchase.
They don't need to navigate the website the same way the customer does. In fact, forcing them through the same menus, filters and checkout steps may simply create unnecessary friction. The AI agent needs reliable, structured ways and clearly defined methods to discover what the retailer offers and what actions it can perform.
AI agents need to know not just what the retailer sells, but how to search, compare, check and buy on the customer's behalf, potentially across numerous websites at once. The retailer that makes the personal shopper's job frictionless is the one more likely to win the sale.
None of this means websites are about to become obsolete. People will continue to visit websites, and great digital experiences will still require accessible interfaces, thoughtful design, persuasive content, and strong brand experiences. A retailer still needs customers to trust its products!
But the webpage will increasingly become one interface to an organisation's digital information and services, rather than the only interface.
Drupal has been moving in this direction for a long time. The same structured content managed in Drupal can already be used across websites, applications, search experiences, feeds and APIs. Drupal is now leading the way in how AI agents can interact with websites to complete transactions.
For a marketing team, publishing has traditionally meant putting something in front of an audience: a campaign, a landing page, or a new product
With the rise of the agentic web, publishing is developing another dimension, one that needs AI systems to understand what you offer, who it's for, whether and where it's available, what it costs, and what actions can be taken, and by whom.
That makes structured content much more than a CMS implementation requirement. It must become part of your brand architecture. The idea of 'capabilities' takes that idea one step further.
You don't need to start exposing every organisational process to AI agents right away. Start by asking different questions about your digital estate. Think beyond "do we have a page explaining this product or service?" and ask "what is the underlying action or outcome we want customers to complete, and could an authorised agent safely perform it?"
This is where Drupal AI gets really interesting!
Drupal has always been good at structured content. A product doesn't have to be defined simply through a large page of text called "product page."
For the personal shopper to do its job well, it needs more than a page to read. Drupal can understand that a product has a:
Those pieces of information can be connected to other things Drupal understands, such as related products or customer reviews.
The customer sees the finished page, but underneath that page is a structured content model that provides an AI agent with context, meaning and additional information not directly available to a human reader on the "product page."
Go back to the waterproof jacket. If an agent asks for products under £150, structured data gives it a much more dependable answer than inferring prices from paragraphs of product copy. Ask for size M, and Drupal knows which fields represent product type, features and size. Ask which jackets are available for next-day delivery, and Drupal can use live availability and delivery information rather than relying on an AI model to guess from a page's wording.
The same structured content that makes a product page useful to a human is what lets a personal shopper act on it. The Drupal AI roadmap builds on that relationship between Drupal's content model, context, governance, and trustworthy AI experiences.
But structured information is only half of the story. Drupal is now developing ways to describe actions just as clearly.
AI has already given us enough acronyms to fill a data center, but three are particularly relevant to the future of content management systems: API, MCP, and ARD.
An API, or Application Programming Interface, is a controlled way for one system to request information or perform an action.
In the context of agentic AI acting on a Drupal website, think of it like a service counter. Instead of navigating through the shop yourself, you make a specific request:
"Show me all products under £50 that are currently in stock."
The API defines what can be requested and how the answer comes back.
APIs aren't new. They already connect websites to apps, CRMs, commerce systems, search platforms, and countless other services.
MCP, or Model Context Protocol, is an open standard that lets AI models safely connect to external tools, data and services.
Put simply, while an API can expose a capability, MCP gives an AI agent a consistent way to use it.
Drupal's MCP Server project builds on Tool API, making Drupal tools available to compatible AI systems. It also supports authentication, allowing individual tools to require appropriate authorisation rather than simply opening everything to an external agent.
There is another problem: an AI agent can only use a capability if it knows it exists.
Agentic Resource Discovery, or ARD, is an emerging idea exploring how agents might discover services that can fulfil a particular need.
Instead of already knowing which website to visit, an agent could potentially ask a broader question:
"Who can help me find a product matching these requirements?"
Discovery and execution are different problems. One helps an agent find the right door, whereas the other helps it interact with what is behind the door.
The standards are still evolving, and nobody needs to redesign their digital strategy around a particular acronym today. The important thing is the direction of travel.
One important building block in Drupal's emerging agentic AI architecture is Tool API. It gives Drupal a consistent, reusable way to describe not only the information it holds but also the things it can do, with clearly defined inputs and outputs that Drupal AI Agents, MCP, and other automation systems can all use.
A tool might effectively say I can search products and describe what information it needs (e.g., product type, size, colour, price range and delivery requirements) and what it will return (e.g., a list of matching products).
Another might say I can check stock availability for a particular product and size, or I can add a selected product to the customer's basket.
AI agents can reuse tools and expose them to other AI systems through technologies such as MCP. Tool API is currently available as a beta project, so this is active, evolving work rather than a finished endpoint for the vision.
The big idea is that Drupal can increasingly describe not just what it knows, but what it can do.
That is a fundamentally new Drupal capability being built on top of Drupal's existing publishing capabilities.
This is also where the Drupal AI Initiative's distinction between Inside AI and Outside AI becomes useful.
Inside AI focuses on AI working within Drupal to help you create, manage, and optimise your website. Outside AI focuses on external agents acting on Drupal.
Outside AI enables an external agent to connect to Drupal, inspect it, change it, verify it, migrate into it, or launch it. That makes the publishing-capabilities idea more than a thought experiment.
Drupal's Outside AI work is actively exploring the infrastructure needed to make Drupal a reliable and governable action surface for external AI agents: who the agent is and where it came from, reliable execution in the background, guardrails, limits on what each tool can touch, visibility into what happened, and predictable contracts between agents and Drupal.
In other words, the question isn't simply "can an AI agent make Drupal do something?" but "can we let an AI agent do something useful while Drupal still controls what is permitted, records what happened and protects everything the agent should not be able to touch?"
Imagine an AI agent interacting with a retailer. An anonymous agent might be allowed to search the product catalogue, add a selected product to that shopper's basket, or check the status of their order.
None of those agents should suddenly gain permission to view another customer's orders, change product prices or publish a new promotion.
Drupal has spent decades developing data access and functional controls, based on roles, permissions and workflows for human users. Those same principles become increasingly valuable when the user is an AI agent, and it's one of the reasons Drupal AI's work on guardrails matters.
Guardrails were introduced into Drupal AI and expanded in the 1.4 release so safety and policy checks can be applied more broadly to incoming and outgoing AI interactions, including support for streaming responses. The Context Control Center (CCC) is another piece of this work, helping Drupal AI draw on the right content, rules and standards to deliver more accurate results.
In simple terms, Drupal can put rules between AI and the organisation.
As agents become more capable, that may be just as important as the capability itself.
APIs aren't new. Drupal permissions aren't new and structured content certainly isn't new.
What's new is how those established strengths are being assembled for an agentic web.
For digital leaders, perhaps the simplest way to understand the direction is in four layers.
This is a very different picture of a CMS from the system many people still imagine when they hear the term. It is not simply the place where somebody logs in to edit the homepage. It becomes a critical control layer between an organisation's information, services and the growing number of digital interfaces through which people interact with them.
The first generation of content management systems helped organisations put information on the web. The next generation helped them structure it, personalise it, distribute it across channels and connect it to increasingly sophisticated digital experiences.
AI agents now offer a shortcut to the ultimate outcomes, which may mean they use the website on the customer's behalf. That doesn't make the CMS less important… it makes the CMS much more important because you now need a way to tell the AI agents what your organisation knows, what it can do, who is allowed to do it, and what happens when they do.
Yesterday's CMS published pages. Tomorrow's CMS publishes capabilities.
Drupal is designed to govern both.
04 Sep 2026 6:27pm GMT
We've all been there. Anyone who has worked with content knows that feeling when critical changes are lost because of human error or a technical glitch. The first instinct might be to panic and call your development team to restore last night's database backup.
04 Sep 2026 3:04pm GMT
Someone told me this week, correctly, that ClaudeBot and GPTBot respect robots.txt, so there is no need to block them by other means, and that the really bad bots disguise as Chrome anyway, so a user-agent is useless; watch behaviour, get a WAF. Every fact in that is right and the conclusion is still wrong, and the gap between the two is the story of why the old ways of guarding a Drupal or Backdrop site have quietly stopped working. Not one of the seven stock robots.txt files a Drupal or Backdrop site ships names a single AI agent, and on a core past its end of life that file will never change again; one vendor honours your notice for its crawler and waives it for its assistant in the same document; a hand-kept blocklist goes stale in a month, and a WAF only ever refuses what someone already knew how to describe. What holds is a server which says no cheaply for what it can recognise, and judges the rest by what it does today.
04 Sep 2026 1:00pm GMT
DrupalClaw pushes AI assistance beyond code suggestions into setup, debugging, database work, and repeatable Drupal operations. Paulo Maia Carvalho's testing also shows where that delegation can fail and why version context, approval gates, and human review still matter.
04 Sep 2026 9:23am GMT
The 52-step checklist tells you what to do. This is the calendar those steps actually run against - a realistic 90-day plan broken into three phases, with the milestones that decide whether you finish on time and the resourcing map showing who's busy when.
04 Sep 2026 4:31am GMT