Open 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.
Say 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 matter
Drupal 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 record
Not 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.
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.
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.
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.
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.