Read one night of a Drupal or Backdrop site's log and most of it had no business with that site: WordPress login probes on a site which never ran WordPress, fishing for secret files, a thousand pages nobody ever made, from about as many addresses, one request apiece. On an ordinary server each of them wakes PHP for a not-found page, until no worker is free and your real visitors see an error instead of the site. On a BOA server those shapes are refused inside the web server before PHP or the database are consulted, the connection closed for what is only ever abuse, a cheap static not-found where a real page could once in a while match; the rest is judged afterwards by what an address did, a fleet by the share of failures it collects, the search engines whitelisted before anyone is banned; and during a swarm nobody can classify, each site keeps a limit on uncached renders so the cache answers everybody else. A block lasts about a quarter of an hour and lifts on its own.
AI is changing how people build, search, and interact with websites, but not every organisation is moving at the same speed. Chad Capellman argues that Drupal's flexibility may matter more as different generations of the web continue to coexist.
Building an open source knowledge base for the AI era
wolfgang.ziegler
AI agents are only as good as the knowledge they are given. So we are building OpenKnowledgebase: an open source wiki and AI knowledge base where people and agents work together, with trust built in.
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 words
Accessibility 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.
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.
Somewhere in your organization, someone put AI-generated content on your website this week. Nothing marks those pages as AI-generated, and no record exists of which tool produced them, from what prompt, or who checked the result before it went live. Closing that gap is what AI content governance is about.
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
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.
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.
What Top Tier really means
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.
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.
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.
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.
With 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|rawfilter, 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!
Using raw bypasses Twig's protection
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.
What to use instead
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.
So before you reach for |raw
So 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.
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.