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
Recently, Simon Willison shared research on running Pydantic's Monty in WebAssembly. Monty is a minimal, secure Python interpreter written in Rust, designed specifically for safely executing code generated by LLMs.
The key breakthrough here is the ability to run Python code with microsecond latency in a strictly sandboxed environment, either on the server (via Rust/Python) or directly in the browser (via WASM).
I've put together a demo project that explores both the Python integration and the WebAssembly build.
Monty is a subset of Python implemented in Rust. Unlike Pyodide or MicroPython, which aim for full or broad compatibility, Monty is built for speed and security. It provides:
By compiling Monty to WebAssembly, we can provide a Python REPL that runs entirely on the client side. This is perfect for interactive documentation, playground environments, or edge-side code execution.
In my demo, I've included the WASM assets and a simple HTML interface to try it out.
AI agents often need to execute code to solve problems (e.g., math, data processing). Traditional sandboxing (Docker, Firecracker) has significant overhead. Monty offers a "sandbox-in-a-sandbox" approach that is lightweight enough to be part of the inner loop of an LLM interaction.
Check out the GitHub repository for the full source and instructions on how to run it yourself.
Recently, a critical authenticated SQL injection vulnerability (CVE-2025-9318) was discovered in the Quiz and Survey Master (QSM) WordPress plugin, affecting versions up to 10.3.1. This flaw allowed attackers with at least subscriber-level permissions to execute arbitrary SQL queries via the is_linking parameter.
In this post, we audit the vulnerability, demonstrate how it worked, and show the implementation of the fix.
The core of the issue was a classic SQL injection pattern: user-supplied input was directly concatenated into a SQL string without being sanitized or passed through a prepared statement.
The vulnerable code looked something like this (simplified for demonstration):
function qsm_request_handler($is_linking) {
global $wpdb;
// VULNERABLE: Direct concatenation of user input into SQL
$query = "SELECT * FROM wp_qsm_sections WHERE is_linking = " . $is_linking;
return $wpdb->get_results($query);
}
By providing a payload like 1 OR 1=1, an attacker could change the logic of the query to return all sections or extract data using UNION SELECT statements.
The vulnerability was resolved in version 10.3.2 by properly utilizing WordPress's $wpdb->prepare() method. This ensures that parameters are correctly typed and escaped before being merged into the query.
function qsm_request_handler($is_linking) {
global $wpdb;
// FIXED: Using wpdb::prepare to safely handle the parameter
$query = $wpdb->prepare(
"SELECT * FROM wp_qsm_sections WHERE is_linking = %d",
$is_linking
);
return $wpdb->get_results($query);
}
In the fixed version, the %d placeholder tells WordPress to treat the input as an integer. Any non-numeric payload (like 1 OR 1=1) will be cast to an integer (resulting in 1 in this case), neutralizing the injection attempt.
We have created a standalone audit project that simulates this environment and provides automated tests to verify both the vulnerability and the fix.
View Code View the Audit Repository on GitHub
(int) provides an extra layer of defense.Stay secure!
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.
Drupal Dripyard Meridian Theme is a Drupal theme project I set up to provide a consistent, brandable front end for a Drupal site. From the name, this is a site-specific theme that focuses on structure, styling, and layout conventions for the Dripyard Meridian experience. It lives as a standard Drupal theme repo and can be dropped into a Drupal codebase when you need a cohesive look and feel.
This is useful when you want a clean separation between content and presentation. A dedicated theme lets me iterate on UI structure, templates, and styling without touching core or module logic, keeping upgrades safe and changes focused. The theme approach also makes it easier to hand off design updates to collaborators while preserving the Drupal data model.
One technical takeaway: for Drupal themes, small, disciplined template overrides and consistent component class naming go a long way. Keeping the theme surface area minimal while relying on Drupal's render pipeline makes the UI predictable and reduces regressions when content types evolve.
View Code
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).I put together drupal-droptica-field-widget-actions-demo as a small Drupal demo project that showcases how field widget actions can be wired into content editing workflows. The goal is to show the mechanics in isolation, with a simple project structure that’s easy to clone and inspect.
This kind of demo is useful when you want to validate an interaction pattern quickly before rolling it into a real module or site build. It helps confirm how widget actions behave in the form UI, what they can trigger, and how they affect editor experience without the noise of a full product stack.
A key takeaway: keep the demo surface area minimal so the widget action behavior is the only moving part. That makes it straightforward to reason about configuration, test edge cases, and reuse the pattern in other Drupal projects.
View Code: View Code
drupal-entity-reference-integrity is a Drupal module focused on keeping entity references consistent across content. It aims to detect and prevent broken references when entities are deleted, updated, or otherwise changed, so related content doesn’t silently point to missing or invalid targets.
This is useful in content-heavy Drupal sites where references drive navigation, listings, or business logic. Integrity checks and cleanup reduce hard-to-debug edge cases and help keep editorial workflows dependable as content models evolve. If you want to explore the implementation, see View Code.
Technical takeaway: treat entity references as first-class data relationships. By enforcing validation or cleanup at the module level, you can keep reference integrity aligned with your content lifecycle, which makes downstream rendering and integrations more reliable.
I built drupal-gemini-ai-studio-provider as a Drupal integration that connects Google Gemini AI Studio to Drupal’s AI/provider ecosystem. In practice, it’s a provider module: it wires a Gemini-backed client into Drupal so other modules can invoke model capabilities through a consistent interface.
This is useful because it keeps AI usage centralized and configurable. Instead of hard-coding API calls in multiple places, you configure one provider and let Drupal features (or custom code) consume it. That keeps credentials, settings, and model choices in one spot and makes swapping providers or environments far less painful. View Code
Technical takeaway: a provider module should prioritize clean dependency injection, clear service definitions, and configuration defaults. When the provider is the only place that knows about the external API, you get a clean seam for testing, mocking, and future migrations.
View Code
Drupal GPT-5.3 Codex Maintenance PoC is a small proof-of-concept that explores how an agent can assist with routine Drupal maintenance tasks. From its name, this project likely focuses on using a codex-style agent to interpret maintenance intent and apply safe, repeatable changes in a Drupal codebase.
I find this useful because maintenance work is constant, easy to overlook, and expensive to do manually at scale. A focused PoC makes it easier to validate workflows like dependency updates, configuration checks, or basic cleanup without committing to a full platform build.
The key technical takeaway is that even a narrow, well-scoped agent can create leverage by standardizing maintenance logic and making it auditable. If the workflows are deterministic and the outputs are easy to review, teams can integrate this approach into CI without adding unpredictable risk.
View Code
drupal-cms-2-ai-agent-poc is a proof‑of‑concept that connects Drupal CMS to an AI agent workflow. From the name, I’m treating it as a focused bridge: a Drupal-side surface area that can invoke, coordinate, or integrate with agent logic for content or automation tasks.
Why it’s useful: Drupal teams often need repeatable, safe automation around content ops, migrations, or editorial workflows. A small POC like this is the right way to validate how agent-driven actions can plug into Drupal without over‑committing to a full platform redesign.
One technical takeaway: keep the integration seam narrow and explicit. A thin module or service layer that exposes a minimal API for agent tasks makes it easier to test, secure, and evolve over time—especially when agent behavior changes.
View Code
I built drupal-cms-2-review-canvas as a focused review scaffold for Drupal CMS 2 work. It’s a small, purpose-built space to capture what matters in a CMS review: structure, decisions, and the evidence behind them. If you’re reviewing builds, migration plans, or release readiness, a consistent canvas makes the process repeatable and easier to compare over time.
It’s useful because it keeps reviews lightweight without being vague. A single place for scope, risks, test notes, and recommendations reduces context switching and avoids scattered notes across tickets or docs. The result is a clearer review trail and faster handoffs for teams that iterate quickly on Drupal-based sites.
One technical takeaway: even minimal artifacts benefit from a clear schema. A well-defined canvas nudges reviewers to record the same critical signals every time, which makes later analysis and automation possible. That consistency is the difference between “nice notes” and actionable review data.
View Code: View Code
drupal-cms-ai-recipes-review is a small, focused Drupal CMS review project that documents and validates a set of AI-oriented recipes for building common site features. I use it as a quick, repeatable way to check how recipe-based setups behave in real Drupal CMS installs without spinning up a large scaffold.
It’s useful because Drupal CMS recipes can drift as core, contrib, or tooling changes. A lightweight review repo makes it easy to spot breakage, confirm assumptions, and share what actually works right now, especially when AI-assisted workflows are involved.
Technical takeaway: recipe reviews are most valuable when they capture both the “happy path” and the sharp edges. Even a minimal repo can encode a reproducible checklist that saves time across multiple projects.
View Code
I built drupal-content-audit as a lightweight way to inspect and report on content in a Drupal site. It focuses on surfacing what content exists and how it’s distributed, giving a quick snapshot that’s easy to share with stakeholders. View Code
This is useful when you’re migrating sites, pruning stale content, or validating content models before a redesign. Instead of guessing, you get a concrete audit you can reference while planning content changes or setting editorial priorities.
One technical takeaway: keep the audit output narrowly scoped and deterministic. When the report structure is stable, it’s much easier to diff changes over time and wire it into CI checks or content QA workflows.
View Code
Drupal Aggregation Guard is a small Drupal module focused on protecting asset aggregation. It aims to keep CSS/JS aggregation reliable and safe under real-world deployments, where caches, build artifacts, and file permissions can drift. If you’ve ever had a site render fine locally but break after a deploy, this kind of guardrail is the missing layer.
The value is in predictable behavior: when aggregation goes sideways, you want the site to fail gracefully or self-correct rather than silently serve broken assets. The module is meant to tighten that gap, especially in automated pipelines where you can’t babysit cache rebuilds. View Code
Technical takeaway: treat aggregated assets as a stateful artifact, not a guaranteed side effect. That means verifying preconditions (writable directories, expected hashes, and cache integrity) and making failures visible early instead of letting them leak into production.
I built drupal-ai-gemini-content-generator as a Drupal module that wires Google Gemini into a content generation workflow. The goal is straightforward: generate draft text inside Drupal so editors can iterate faster without leaving the CMS. View Code
It is useful when teams want consistent, AI-assisted drafts that still live in Drupal’s content model, permissions, and review flow. The module name suggests it targets Gemini as the LLM provider, which makes it a practical fit for organizations already standardized on Google tooling or looking for a simple provider integration.
Technical takeaway: AI features in CMSs work best when they behave like first-class content operations. Hooking generation into Drupal’s form and entity flows keeps drafts traceable, reviewable, and replaceable without changing how editors already work.
drupal-ai-module-generator-deepseek-mcp is a Drupal-oriented generator that uses a DeepSeek-backed MCP workflow to scaffold module code. I built it to take the repetitive, error-prone parts of module setup—info files, boilerplate, and consistent structure—and make them fast and repeatable. It fits naturally into agent-driven workflows where you want consistent Drupal modules without losing time to manual setup.
It’s useful because it standardizes the starting point for modules and makes the first commit reliable. That means less time redoing file structures, fewer mistakes in module metadata, and a faster path from idea to a working, testable Drupal feature. If you’re iterating on multiple modules or experiments, the generator pays off almost immediately.
The key technical takeaway is that pairing MCP with a targeted generator creates a clear contract between intent and output. You define the module intent, and the generator enforces a predictable Drupal skeleton that downstream tools can build on. That makes subsequent automation—tests, linting, and CI checks—much easier to wire in.
References