10 posts tagged with "Drupal"

PHP2Shell is the name for two use-after-free flaws in the PHP engine, and PHP shipped the fixes on October 21, 2026. My position: patch on your normal urgent schedule, check the exploit conditions against your own servers, and do not download or run anything a stranger on X calls an exploit or a fix. The bugs deserve a patch, the panic deserved much less, and the exploit and fix scripts shared on social media were worse than useless.

GitHub's agentic workflow architecture is a set of promises until CI enforces them, and a promise has never failed a build. For Drupal module and WordPress plugin maintainers, I treat CI as a policy enforcement plane. Its first job is to block risky behavior, and running builds is its second.

Pantheon switched the Drupal CMS upstream to Drupal CMS 2 on March 6, 2026, for new sites only. Existing Drupal CMS sites are not auto-updated, and Drupal 10/11 upstream sites are not affected. A team that reads this as "new upstream, apply everywhere" is about to run a migration by accident. For new builds, starting on Drupal CMS 2 is a good default. For existing sites, I would classify every site first and upgrade each CMS 1.x site as a planned migration with its own release gate.

A faster CI runner earns its place only if p95 runtime and failure rate say so. Run the compute-heavy parts of a DDEV Drupal pipeline on WarpBuild runners, keep Composer cache keys deterministic, and gate the rollout on numbers so the pipeline stays explainable. I checked this playbook against DDEV v1.25.1 (released February 23, 2026) and the WarpBuild docs as of February 25, 2026.

Drupal contrib security review needs explicit access decisions, CSRF protection on state-changing routes, output checks and a repeatable release gate. This checklist focuses on those checks and the limits of grep-based searches.

Asking a Drupal site which PHP version it runs should not require an SSH key and a terminal. I built Project Context Connector, a Drupal module that exposes a read-only JSON snapshot of site configuration to AI agents, automation scripts and monitoring tools. Each tool reads the same snapshot through one of four interfaces: REST, an HMAC-signed endpoint (a request signed with a shared secret), Drush or native Model Context Protocol (MCP) support.

AI made finding vulnerabilities cheaper, but it did not make fixing them cheaper. The cost lands on an open-source maintainer with limited hours, who now has to sort a flood of security reports into urgent, false positive and later. Drupal AI Vulnerability Guardian works on that sorting step: it scans Drupal modules for 12 vulnerability patterns and gives each finding a score, a CWE ID and an estimate of the work to fix it.

Version one of Drupal AI Content Impact Analyzer returned one opaque number, which told editors how a page scored and nothing about why. It was a minimal proof of concept with a single scoring function, no tests and no documentation worth mentioning, so it proved the idea worked but not that editors could use it. Version two rewrites the core into a scoring engine with six dimensions, and each one tells the editor what to fix.

A scanner that only reports broken entity references hands you a well-formatted list of manual work. The first version of drupal-entity-reference-integrity did exactly that. This upgrade adds an opt-in auto-fix mode, batch processing for large sites and the tests needed to trust both in production.

The first version of this Drupal agent could create, read and list nodes. That proved the concept, but it could not fix a typo in the content it had created. A content operations agent also needs update, delete, users, taxonomy and media, and it has to survive a flaky network, so retry logic now lives once in the HTTP client.