60 posts tagged with "Devlog"

Two titans of the AI industry just dropped major model updates on the same day, and the implications for autonomous coding agents are massive.

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.

GPT-5.3-Codex just dropped, and I wasted no time throwing it into a custom agent harness to see if it can actually handle complex supervision loops better than its predecessors.

Why I Built It​

The announcement of GPT-5.3-Codex promised significantly better instruction following for long-chain tasks. Usually, when a model claims "better reasoning," it means "more verbose." I wanted to verify if it could actually maintain state and adhere to strict tool-use protocols without drifting off into hallucination land after turn 10.

Instead of testing it on a simple script, I built codex-agent-harness—a Python-based environment that simulates a terminal, manages a tool registry, and enforces a supervisor hook to catch the agent if it tries to run rm -rf / (or just hallucinates a command that doesn't exist).

The Solution​

The harness is built around a few core components: a ToolRegistry that maps Python functions to schema definitions, and an Agent loop that manages the conversation history and context window.

One of the key features is the "Supervisor Hook." This isn't just a logger; it's an interceptor. Before the agent's chosen action is executed, the harness pauses, evaluates the safety of the call, and can reject it entirely.

Architecture​

The Tool Registry​

I wanted the tool definitions to be as lightweight as possible. I used decorators to register functions, automatically generating the JSON schema needed for the API.

class ToolRegistry:
    def __init__(self):
        self.tools = {}

    def register(self, func):
        """Decorator to register a tool."""
        schema = self._generate_schema(func)
        self.tools[func.__name__] = {
            "func": func,
            "schema": schema
        }
        return func

    def _generate_schema(self, func):
        # Simplified schema generation logic
        return {
            "name": func.__name__,
            "description": func.__doc__,
            "parameters": {"type": "object", "properties": {}}
        }

registry = ToolRegistry()

@registry.register
def read_file(file_path: str):
    """Reads a file from the local filesystem."""
    with open(file_path, 'r') as f:
        return f.read()

The Code​

I've published the harness as a standalone repo. It's a great starting point if you want to test new models in a controlled, local environment without spinning up a full orchestration framework.

View Code

What I Learned​

• Context Adherence is Real: GPT-5.3-Codex actually respects the system prompt's negative constraints (e.g., "Do not use sudo") much better than 4.6, which often needed reminders.
• Structured Outputs: The model is far less prone to "syntax drift" in its JSON outputs. I didn't have to write nearly as much retry logic for malformed JSON.
• The "Lazy" Factor: Interestingly, 5.3 seems a bit too efficient. If you don't explicitly ask for verbose logs, it will just say "Done." Great for production, bad for debugging. I had to force it to be verbose in the system prompt.

References​

• Opus 4.6 and Codex 5.3
• Introducing GPT-5.3-Codex
• GPT-5.3-Codex System Card

I built a Playwright-based auditor to automate the "user journey" evaluation methodology for UK Council websites, inspired by David Bishop's work.

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.

Why I Built It​

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 Solution​

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.

Implementation Details​

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();
    }
  }
}

The Code​

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.

View Code

What I Learned​

• Decoupling is King: The manager doesn't need to know anything about the implementations until runtime.
• Performance: Service collectors are evaluated during container compilation. This means there's zero overhead at runtime for discovering services.
• Council Insight: Reading David Bishop's thoughts on UK Council websites reminded me that "architectural elegance" doesn't matter if the user journey is broken. Even the best service container won't save a site with poor accessibility or navigation.
• Gotcha: If your manager requires implementations to be available during its own constructor, you might run into circular dependencies. Avoid doing work in the constructor; use the collected services later.

References​

• [The Drop Times: David Bishop on Council Insight and Rethinking How UK Council Websites Are Evaluated](https://www.thedroptimes.com/interview/66236/david-bishop-interview-council-insight-user-journeys-and-evaluating-uk-council-websites?utm_source=Drupal Planet)
• David Bishop on Council Insight and Rethinking How UK Council Websites Are Evaluated
• [The Drop Times: Drupal service container deep dive (Part 3): service collectors](https://www.thedroptimes.com/66222/drupal-service-container-deep-dive-part-3-service-collectors?utm_source=Drupal Planet)

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.

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 Vulnerability: CVE-2025-9318​

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.

Vulnerable Code Pattern​

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 Fix: Prepared 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.

Fixed Code Pattern​

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.

Audit and Verification​

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

Key Takeaways​

1. Never Trust User Input: Even parameters that seem "safe" or internal should be treated as malicious.
2. Use Prepared Statements: This is the primary defense against SQL injection in WordPress development.
3. Type Casting: For numeric parameters, casting to (int) provides an extra layer of defense.

Stay secure!

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

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.

View Code

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

• Drupal 11 is the orchestration hub and data store for processed documents.
• Drupal AI Automators provides configuration-first workflow orchestration instead of custom code for every step.
• Unstructured.io (self-hosted) converts messy PDFs into structured text and supports OCR.
• GPT-4o-mini handles taxonomy matching, metadata extraction, and summary generation using structured JSON output.
• RabbitMQ runs background processing for time-intensive steps like summaries.
• Watchdog logging is used for monitoring and error visibility.

Integration notes you can reuse​

• Favor configuration-first orchestration (AI Automators) so workflow changes don't require code deploys.
• Use Unstructured.io for PDF normalization, not raw PDF libraries, to avoid headers, footers, and layout artifacts.
• Filter Unstructured.io output elements to reduce noise (e.g. Title, NarrativeText, ListItem only).
• Output structured JSON that is validated against a schema before field writes.
• Use delayed queue processing (e.g. 15-minute delay for summaries) to avoid API cost spikes.
• Keep AI work in background jobs so editor UI stays responsive.

QA and reliability notes​

• Validate extraction quality before LLM runs. Droptica measured ~94% extraction quality with Unstructured vs ~75% with basic PDF libraries.
• Model selection should be empirical; GPT-4o-mini delivered near-parity accuracy with far lower cost in their tests.
• Use structured JSON with schema validation to prevent silent field corruption.
• Add watchdog/error logs around each pipeline stage for incident tracing.
• Include a graceful degradation plan for docs beyond context window limits (e.g. 350+ page inputs).

References​

• AI document processing in Drupal – technical case study (95% accuracy)
• AI-powered document categorization for BetterRegulation

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.

References​

• View Code

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

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

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

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.

References​

• View Code

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.

References​

• View Code