Some of the hardest technology failures arrive without a broken component or a clear error. Two DrupalCamp Poland speakers examine what teams can learn from convincing AI mistakes, system-level performance failures, and automation that still depends on human judgement.
Rebuilding a data-driven Drupal site: Separating data objects from pages
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.
On 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.
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.
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 solves
Beyond 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.Canvasis 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.
Putting paths first: Views support for path alias entities
On 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.nid
What 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!
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.