In case you missed PSA-2026-11-02 ( https://www.drupal.org/psa-2026-11-02 ): starting in 2027, each Drupal core minor version gets 8 months of security coverage instead of the 12 we've had since 8.6. The Security Team's reason is the flood of AI-generated security reports they can't keep up with on current funding. Fewer supported branches means less backporting.

The part that matters day to day: with a new minor every six months, when 11.6 / 12.1 comes out in June 2027, 11.5 / 12.0 only has two months of support left (until August 2027).

And Drupal 10 reaches EOL on December 9, the same week Drupal 12 (PHP 8.5 minimum) is released.

I'm migrating a few sites from 10 to 11 right now. Core isn't the issue. What eats the time is deprecated APIs in custom code, contrib modules several releases behind, the odd abandoned module, and patches in composer.json that no longer apply. Upgrade Status and Rector help, but the sites that were kept up to date are a completely different experience from the ones nobody touched for two years.

I wrote a longer post on what this means for site owners and what a maintenance budget should realistically cover now: https://menetray.com/en/blog/eight-months-drupal-shortens-security-support-and-your-site-cant-wait-year-anymore

Are your clients actually budgeting for regular updates, or are you still doing big catch-up jobs every couple of years?

https://menetray.com/en/blog/green-tests-arent-enough-thats-why-my-ai-goes-through-audit

Models often fall back on D7/D8-era patterns: \Drupal::service() instead of dependency injection, |raw in Twig, render arrays without cache metadata. Most of it works, and tests don't catch it.

So my agents now run the Audit module's Drush commands on whatever they touch (complexity, duplication, Twig, security, PHPStan, PHPCS), fix what comes up and run them again. Then I do the final review. Full disclosure, I maintain the Audit module.

What are you checking beyond tests in your AI workflow?

Six situations this week working with AI agents on Drupal. Some saved me hours. Others tried to ship solutions that looked right but weren't.

One bug had been stuck at an agency for hours and got resolved in 30 minutes. Another fix, if I had accepted it as-is, would have left me with custom patches on contrib modules.

The AI conversation usually focuses on the speed and skips what you have to catch in review. Wrote it down with the six cases. If you work with Drupal or with code in general, curious what you think.

https://menetray.com/en/blog/six-real-world-ai-cases-drupal-week

A while back I wrote an article explaining how I was working with AI on my Drupal projects using DDEV containers with Drupal-specific agents and skills. Several people asked me to share it but I couldn't, because it had client data in it. I've cleaned it up and published everything as open source DDEV add-ons: a meta add-on that installs Claude Code, OpenCode, specialized agents and skills for Drupal 10/11, and several supporting pieces with a single command.

I explain it in detail in the article:
https://menetray.com/en/blog/ddev-ai-workspace-ive-published-my-full-drupal-ai-development-setup

If you work with Drupal, I'd love to hear what you think: whether you try it, if you find it useful, if you'd actually use it. If you run into any issues, let me know here or open an issue on the matching repo and I'll fix it as soon as I can.

https://github.com/trebormc/ddev-ai-workspace

Just published a contributed module on drupal.org for auditing Drupal projects:

https://www.drupal.org/project/audit

It analyzes your installation and gives you scored reports across different categories: module updates, security, cache, performance, SEO, fields, Views... with concrete recommendations in each one. It's built around independent submodules so you only enable what makes sense for each project.

The idea is that you install it, run the audit, and get a clear picture of what's wrong and where to focus. It works on any hosting, everything stays on your server, and most submodules are fine to run on production. The only exceptions are audit_phpstan and audit_phpcs, which do static code analysis and require dev dependencies so those are better suited for development or staging environments.

Curious how you currently handle audits across your Drupal projects and whether something like this would fit into your workflow or not. Any feedback is welcome.