fidzu : cms

A statewide publishing platform can reduce repeated technical work across public websites, but it also establishes an operating model that can outlast the migration that created it.

24 Sep 2026 1:21pm GMT

I came up with the title for this blog post while working on 20+ Webform security issues, because there were moments when I used Codex to hammer out a particularly complex issue. I couldn't help but find it ironic to use something as advanced as AI to hammer at a problem or challenge.

Some security issues were so complex to reproduce that I had to push Codex to replicate the problem, and it occasionally generated sloppy code. Still, even with Codex generating AI-slop, it helped me understand the root causes and solutions for security issues that had lingered for years.

Before I go any further, let's step back and talk about the challenge of maintaining the Webform module and addressing security issues.

Maintaining the Webform module

The bulk of the Webform module was created a decade ago, when I had more time and motivation to make a sizable contribution to Drupal. Drupal contributors and their contributions come in all shapes and sizes. The current codebase is stable and extendable, with "extendable" as the keyword, because people and AIs can alter and create Webform features and behaviors as needed using contributed modules or custom code. It is ironic that all the example webforms included in the Webform module, intended to help humans, have proven incredibly useful for AIs in understanding and extending webforms.

Though I am willing to say the code is stable, the fact that a webform is generally public and accepts input leaves the Webform module open to security issues. In other words, malicious actors, including AI, will target webforms to exploit XSS vulnerabilities or expose data.

Securing the Webform module

It is worth recognizing and praising Drupal's security team for...Read More

24 Sep 2026 8:32am GMT

The files that Drupal does not track

Any long-lived Drupal site, whether it stores files in a local folder or a remote bucket like Amazon S3, holds hundreds of files, and there is no easy way to see which ones Drupal still tracks and which it has lost sight of. The files come from four places: live content, leftovers from nodes deleted years ago, migration and backup residue, and direct uploads, such as a PDF dropped onto the server because it was faster.

This is a common problem in the sector, and it does not depend on the technology in use. Every content system faces it sooner or later. The root cause is two stores that must agree: the bytes in storage versus the database that is supposed to keep track of them. The moment both stores exist, they drift. It happens in three ways: records get deleted but the files stay, files get uploaded but never registered, and jobs fail halfway.

These accumulated unreferenced files are untracked files, a kind of dark data: information an organisation keeps but no longer uses.

The cost of untracked files…

23 Sep 2026 10:05pm GMT