Drupal CMS and ecosystem
View All Tags
For over a decade, Drupal developers have relied on Drupal.ajax—a powerful but heavy abstraction layer over jQuery—to handle dynamic interactions. But with jQuery's slow sunset and the rise of "HTML-over-the-wire" paradigms, it's time for a change.
Enter the HTMX in Drupal Core initiative.
There is a fascinating conversation happening in the Drupal community right now: HTMX Now in Drupal Core. The proposal? To replace the venerable (but aging) jQuery-based Ajax API with a modern, lightweight, HTML-over-the-wire subsystem based on HTMX.
To understand the practical implications, I built a demo module comparing the two approaches side-by-side.
I created drupal-htmx-ajax-replacement-demo, a module that renders two identical interactive cards. One uses the standard Drupal.ajax library, and the other uses HTMX.
The traditional way relies on jQuery and a custom JSON protocol.
The Flow:
.use-ajax.Drupal.ajax intercepts the click.AjaxResponse with commands (e.g., ReplaceCommand).[{"command": "insert", "method": "html", ...}].The Code:
public function timeAjax() {
$response = new AjaxResponse();
$response->addCommand(new HtmlCommand('#container', $html));
return $response;
}
HTMX allows us to be declarative. We define what we want in HTML attributes, and the server just returns HTML.
The Flow:
<button hx-get="..." hx-target="...">.The Code:
public function time() {
return new Response($html);
}
The difference in complexity is striking.
core/drupal.ajax library (and jQuery). HTMX is lighter and requires no custom Javascript for this interaction.Response object with a string. The legacy controller requires instantiating AjaxResponse and learning the Command API.You can view the full source code and the comparative implementation in the repository below.
View Code
Drupal 12 is on the horizon, and with it comes the final removal of a long-standing legacy layer: the procedural Database API wrappers.
If your codebase still relies on db_query(), db_select(), or db_insert(), you are looking at a hard break when D12 lands. These functions have been deprecated since Drupal 8, but they've stuck around for backward compatibility. That grace period is ending.
The Drupal community is gearing up for Drupal 12, anticipated for release in mid-2026. A critical part of this transition is the relaunch of the Deprecation Dashboard, a tool that provides a bird's-eye view of the readiness of contributed modules and core components.
One of the most significant changes in the Drupal 12 readiness strategy is a policy shift: most disruptive deprecations from Drupal 11.3 onwards will be deferred until Drupal 13. This move is designed to make the jump from Drupal 11 to 12 as smooth as possible, maintaining consistency in public APIs and allowing maintainers to adopt the new version earlier.
The relaunched dashboard, now hosted on docs.acquia.com, offers real-time insights into which modules are already compatible and which still have work to do. It leverages static analysis and automated testing to track progress across the entire ecosystem.
Key tools mentioned in the relaunch include:
To complement the existing tools, I've built a lightweight, targeted CLI tool: Drupal 12 Readiness CLI. While drupal-check is excellent for general deprecations, this tool is specifically configured to help developers identify the critical path for Drupal 12.
The tool wraps phpstan-drupal and phpstan-deprecation-rules into a single, zero-config command that you can run against any Drupal module or theme directory.
You can find the full source code and installation instructions on GitHub: victorstack-ai/drupal-12-readiness-cli
# Install via Composer
composer require --dev victorstack-ai/drupal-12-readiness-cli
# Run the scan
./vendor/bin/drupal-12-readiness scan web/modules/custom/my_module
The tool will report any deprecated API calls that need attention before Drupal 12, giving you a clear roadmap for your upgrade path.
By staying ahead of the deprecation curve, we ensure that the Drupal ecosystem remains robust and ready for the next generation of digital experiences.
Inspired by Dries Buytaert's recent insights on AI-Driven Vulnerability Discovery, I built a tool to address one of the biggest challenges in modern open-source security: Triage at Machine Speed.
As AI makes it easier and cheaper to find potential vulnerabilities, open-source maintainers are facing an unprecedented flood of security reports. The bottleneck is no longer finding bugs, but evaluating and triaging them without burning out the human maintainers.
Today I contributed a fix for a subtle but impactful operator precedence bug in Drupal Core's DefaultTableMapping class. The bug affects how SQL table names are constructed when a database prefix is used and entity type tables are not explicitly configured.
In PHP, the concatenation operator (.) has higher precedence than the ternary operator (?:). This led to an issue in the DefaultTableMapping constructor:
$this->baseTable = $this->prefix . $entity_type->getBaseTable() ?: $entity_type->id();
When a prefix is present (e.g., 'prefix_') and getBaseTable() returns NULL, the expression evaluates as follows:
'prefix_' . NULL results in 'prefix_'.'prefix_' ?: $entity_type->id() checks if 'prefix_' is truthy.'prefix_' is truthy, it is returned, and the fallback entity ID is ignored.This results in a table name that is just the prefix, leading to malformed SQL queries.
The fix is straightforward: wrap the ternary expression in parentheses to ensure it is evaluated before concatenation.
$this->baseTable = $this->prefix . ($entity_type->getBaseTable() ?: $entity_type->id());
I've created a standalone reproduction project with a PHPUnit test to verify the fix. The test ensures that table names are correctly constructed even when getBaseTable() and related methods return NULL.
View Code
Issue Link
The recent security alert regarding Moltbook, an AI-only social platform, serves as a stark reminder that "vibe coding" — while incredibly productive — can lead to catastrophic security oversights if fundamental principles are ignored.
In early February 2026, cybersecurity firm Wiz identified critical flaws in Moltbook. The platform, which was built primarily using AI-assisted coding, suffered from basic misconfigurations that led to:
The creator admitted that much of the platform was "vibe coded" with AI, which likely contributed to the oversight of standard security measures like authentication layers and secret management.
AI is great at generating code that works, but it doesn't always generate code that is secure by default unless explicitly instructed and audited. When building AI integrations, especially in platforms like Drupal, it's easy to accidentally store API keys in configuration or expose environment files.
To help the Drupal community avoid similar pitfalls, I've built a small utility module: AI Security Vibe Check.
This module provides a Drush command and a service to audit your Drupal site for AI-related security risks:
.env or .git directories in your web root.drush ai:vibe-check to get a quick health report on your AI security "vibe."View Code
Building with AI is the future, but let's make sure our "vibes" include a healthy dose of security auditing.
Issue: Moltbook Security Alert
In a recent insightful post, Dries Buytaert, the founder of Drupal, addressed a growing concern in the open source community: the deluge of AI-generated contributions. While AI can lower the barrier to entry, it often produces low-value reports or patches that lack expertise, overwhelming maintainers who are already stretched thin.
Dries' core message is clear: We need AI tools that empower maintainers, not just contributors.
Inspired by this, I've developed a prototype called Drupal Maintainer Shield.
The "curl" project recently had to end its bug bounty program due to a flood of AI-generated security reports that were mostly noise. This is "maintainer fatigue" in action. If every AI agent can spin up a patch in seconds, the human bottleneck—the reviewer—becomes the point of failure for the entire ecosystem.
Drupal Maintainer Shield is a CLI tool designed to act as a first line of defense for Drupal maintainers. It uses AI-driven heuristics to analyze incoming patches and issue descriptions, scoring them based on "Signal" vs. "Noise".
View Code View Code
The tool looks for two categories of signals:
Security-Category), specific CVE references, and high-signal code patterns (like fixing unsanitized db_query calls).When a maintainer runs the shield against a high-quality security patch:
bin/shield analyze patch.txt
They get a clear recommendation:
Recommendation: HIGH SIGNAL - PRIORITIZE Confidence Score: 100/100 Findings: References specific CVE ID, Potential SQL injection fix detected.
Conversely, a low-effort report might be flagged as:
Recommendation: PROBABLE NOISE - LOW PRIORITY Warning: This contribution matches common AI noise patterns. Proceed with caution.
As we move toward a world where AI agents are primary contributors to codebases, we must build the infrastructure to verify and validate their work. Tools like Drupal Maintainer Shield are small steps toward a future where AI helps us scale security without burning out the humans who make open source possible.
Check out the project on GitHub and let's discuss how we can improve AI tools for maintainers.
The "Drupal Pivot" isn't just another conference; it's a signal that the public sector is finally prioritizing digital sovereignty over vendor lock-in. Drupal is becoming the cornerstone of their strategy to escape proprietary ecosystems and guarantee data residency.
The Drupal AI module is getting granular with a new 'Focal Point' operation type and fixing critical streaming consistency issues in the API Explorer.
Caching is usually the answer to everything in Drupal performance, but there's a crossover point where the overhead of the cache itself—retrieval and unserialization—outweighs the cost of just doing the work.
Two issues caught my eye today that dig into these micro-optimizations: one challenging the assumption that we should always cache JSON:API normalizations, and another squeezing more speed out of the service container dumper.
If you've ever wondered how Drupal magically discovers all its breadcrumb builders, access checkers, or authentication providers, you're looking at the Service Collector pattern. It's the secret sauce that makes Drupal one of the most extensible CMSs on the planet.
In complex Drupal projects, you often end up with a "Manager" class that needs to execute logic across a variety of implementations. Hardcoding these dependencies into the constructor is a maintenance nightmare. Instead, we use Symfony tags and Drupal's collector mechanism to let implementations "register" themselves with the manager.
I wanted to blueprint a clean implementation of this because, while common in core, it's often misunderstood in contrib space.
The Service Collector pattern relies on two pieces: a Manager class that defines a collection method (usually addMethod) and a Service Definition that uses a tag with a collector attribute.
In the modern Drupal container, you don't even need a CompilerPass for simple cases. You can define the collector directly in your services.yml.
services:
my_module.manager:
class: Drupal\my_module\MyManager
tags:
- { name: service_collector, tag: my_plugin, call: addPlugin }
my_module.plugin_a:
class: Drupal\my_module\PluginA
tags:
- { name: my_plugin, priority: 10 }
namespace Drupal\my_module;
class MyManager {
protected $plugins = [];
public function addPlugin(MyInterface $plugin) {
$this->plugins[] = $plugin;
}
public function executeAll() {
foreach ($this->plugins as $plugin) {
$plugin->doWork();
}
}
}
Always use priority in your tags if order matters. Drupal's service collector respects it by default.
I've scaffolded a demo module that implements a custom "Data Processor" pipeline using this pattern. It shows how to handle priorities and type-hinted injection.
Drupal CMS 2.0 is betting big on AI, moving beyond "chatbots" to practical, day-one utilities like automated SEO metadata. But knowing the tools exist and having them configured are two different things.
Today, I built a Drupal CMS Recipe to automate the setup of AI-driven SEO tags, turning a repetitive configuration chore into a one-line command.
The "AI Agent" isn't just a buzzword for the future—it's the junior developer clearing your backlog today.
Recent discussions in the Drupal community have converged on a pivotal realization: if we want AI to contribute effectively, we need to tell it how. Between Tag1 using AI to solve a 10-year-old core issue and Jacob Rockowitz's proposal for an AGENTS.md standard, the path forward is becoming clear. We need a formal contract between our code and the autonomous agents reading it.
The Cloudflare 2025 Q4 DDoS threat report has just been released, and the numbers are staggering. A record-breaking 31.4 Tbps attack was mitigated in November 2025, and hyper-volumetric attacks have grown by 700%.
For Drupal site owners, these aren't just statistics—they represent a fundamental shift in the scale of threats our infrastructure must withstand.
The report highlights the rise of the Aisuru-Kimwolf botnet, which leverages Android TVs to launch HTTP DDoS attacks exceeding 200 million requests per second (RPS). When an attack of this magnitude hits a CMS like Drupal, even the most optimized database queries can become a bottleneck if the attack bypasses the edge cache.
To help Drupal communities implement defense-in-depth, I've built the DDoS Resilience Toolkit. This module provides application-level safeguards that complement edge protection like Cloudflare.
As we move into 2026, the scale of DDoS attacks will only increase. Relying solely on default configurations is no longer enough. By combining edge mitigation with application-level resilience, we can ensure our Drupal sites remain performant even under extreme pressure.
Ref: Cloudflare 2025 Q4 DDoS Threat Report.
The Drupal AI Hackathon: Play to Impact 2026, held in Brussels on January 27-28, was a pivotal moment for the Drupal AI Initiative. The event focused on practical, AI-driven solutions that enhance teamwork efficiency while upholding principles of trust, governance, and human oversight.
One of the most compelling challenges was creating AI Agents for Content Creators. This involves moving beyond simple content generation to agentic workflows where AI acts as a collaborator, researcher, or reviewer.
Inspired by the hackathon's emphasis on governance, I've built a prototype module: Drupal AI Hackathon 2026 Agent.
This module implements a ContentReviewerAgent service designed to check content against organizational policies. It evaluates:
By integrating this agent into the editorial workflow, we ensure a "human-in-the-loop" model where AI provides the first layer of policy validation, but humans maintain the final decision-making power.
Building AI agents in Drupal 10/11 is becoming increasingly streamlined thanks to the core AI initiative. The key is to treat the AI not as a black box, but as a specialized service within the Drupal ecosystem that can be tested, monitored, and governed just like any other business logic.
View Code
As AI agents become part of the Drupal workflow, we need infrastructure that makes automation traceable, predictable, and composable. I built four small Drupal modules that together form an MCP Toolkit for agent-driven site management.
The drupal-droptica-ai-doc-processing-case-study project is a Drupal-focused case study that documents an AI-assisted workflow for processing documents. The goal is to show how a Drupal stack can ingest files, extract usable data, and turn it into structured content that Drupal can manage.
This is useful when you have document-heavy pipelines (policies, manuals, PDFs) and want to automate knowledge capture into a CMS. Droptica's BetterRegulation case study is a concrete example: Drupal 11 + AI Automators for orchestration, Unstructured.io for PDF extraction, GPT-4o-mini for analysis, RabbitMQ for background summaries.
This post consolidates the earlier review notes and case study on Droptica AI document processing.
View Code
Title, NarrativeText, ListItem only).The Hook DDEV 1.25.0 ships experimental support for Podman and Docker rootless, opening up new corporate-friendly runtimes while introducing a few practical trade-offs.
Why I Built It The Podman and rootless workflows depend on specific global settings (ports, mount mode). I wanted a fast, repeatable way to confirm a workstation is configured before teams flip the switch.
The Solution
I built a CLI that audits global_config.yaml and flags missing settings for Podman or Docker rootless, with a focused checklist for macOS Podman users.
The Code View Code
What I Learned
no-bind-mounts mode is required.global_config.yaml, and the config can live under $HOME/.ddev or an XDG location.The Hook Centrarro argues you can deliver a B2B portal experience on top of a standard Drupal Commerce store without spinning up a separate platform or domain.
Why I Built It I wanted a concrete, extendable starting point for the portal experience described in the post: a gated landing page, clear account highlights, and a place to route buyers to the next action.
The Solution I built a small Drupal module that creates a B2B portal route, lets admins tune portal labels, and surfaces a summary table. The summary builder is isolated so it can be swapped for real Commerce order data, customer profiles, or pricing logic.
The Code View Code
What I Learned