Somewhere a team is shipping a product that uses passkey credentials as data-encryption keys, and they are genuinely proud of the elegance. They will be less proud the first time a user switches phones and watches their data evaporate. The passkeys critique made this failure mode impossible to ignore — so here are the guardrails I would enforce in any architecture review before that elegant design reaches production.

As of February 27, 2026, WordPress 7.0 Beta 2 (released February 26, 2026) is in active testing ahead of the planned final release on April 9, 2026. I reviewed what can break for custom plugins and themes, and built a minimal checklist to reduce upgrade risk.

February 2026 felt like the month where everyone agreed AI coding is "real now," then immediately discovered the bill: secrets sprawl, shaky governance, fragile tests, and communities trying to stay relevant without becoming AI-themed marketing departments.

I reviewed Drupal advisories SA-CONTRIB-2026-011 through SA-CONTRIB-2026-019 (published on 2026-02-25) and mapped them against active drupal-* projects. Nine advisories, nine modules, one triage session.

Gemini API keys are now under stricter governance: leaked keys can be disabled by Google, and API terms and cloud key controls are evolving. Agent workflows that chain multiple jobs and providers are the most exposed. A single leaked key in logs, prompts, or commits can halt automation and trigger incident response.

I reviewed the policy changes and built a concrete key management update plan.

WordPress 6.9 added assertEqualHTML(), which removes a whole category of brittle test failures caused by formatting-only HTML differences. I reviewed the implementation and mapped out concrete migration patterns for plugin and theme test suites.

If your test suite has ever failed because of a whitespace difference in rendered HTML, this is for you.

If AI agents can open pull requests, secret scanning must become a hard merge gate, not a best-effort report. The practical baseline is: pre-commit scanning for fast feedback, CI blocking checks for enforceability, and policy-controlled break-glass paths with audit logs.

I reviewed the GitGuardian MCP integration pattern and tested it against agent-generated PRs.

Wordfence's February 9-15, 2026 report is a reminder that WordPress security is not a reading hobby. It is an operations loop. Sites that treat it like newsletter content are volunteering for downtime.

As of February 25, 2026, the short answer is: move production to Node 24.14.0 LTS first, test Node 25.7.0 in a non-blocking lane, and treat native addons plus framework engine ranges as the main risk surface. Both were released on February 24, 2026, but 25.x is still the Current line while 24.x is LTS.

Use WarpBuild runners for the compute-heavy parts of your DDEV Drupal pipeline, keep cache keys deterministic, and gate rollout by p95 runtime and failure-rate SLOs. This gives you faster CI without turning your pipeline into a probabilistic black box. I verified this playbook against DDEV v1.25.1 (released February 23, 2026) and WarpBuild docs as of February 25, 2026.

If you maintain a Drupal 10/11 contrib module, the biggest security misses are still predictable: missing access checks, weak route protection, unsafe output, and incomplete release hygiene. The fastest hardening path is to enforce explicit access decisions, protect state-changing routes with CSRF requirements, ban unsafe rendering patterns, and ship every release with a repeatable security gate.

Vault sprawl in multi-team CI/CD is usually a governance failure, not a tooling failure. The practical model that works is: short-lived identity-based access (OIDC/workload identity), path ownership boundaries, policy-as-code with review gates, and measurable rotation/usage controls per team.

Cloudflare viNext is the fastest path today to run modern Next.js apps on Workers with less adapter glue. But the safe adoption pattern is not "AI rewrites everything." The practical pattern is AI for scoped transforms, deterministic checks for every change set, and a canary rollback plan.

That combination gives speed without losing production stability.

I built a reproducible Next.js rebuild benchmark to answer one question quickly: which build profile is fastest, and did we just introduce a regression? It targets next@16.1.6, runs cold and warm cache scenarios, and produces JSON you can diff in CI.

Teams notice build regressions late. This tool makes them visible immediately.

Drupal does not need more hot takes; it needs a cleaner signal path so you can see what changed, what might break, and what to do next before release day punches you in the face.

SearXNG in Drupal AI assistants matters because it gives you controllable, inspectable retrieval without funneling your org's prompts and context into yet another black-box "trust us" API.

If your multi-agent workflow keeps failing in unpredictable ways, implement four controls first: typed handoffs, explicit state contracts, task-level evals, and transactional rollback. GitHub's engineering deep dive published on February 24, 2026 shows the same core pattern: most failures are orchestration failures, not model-IQ failures.

As of February 24, 2026, WordPress 7.0 is in Beta 1 (released February 20, 2026), and the post editor is planned to run inside an iframe regardless of block apiVersion. If your plugin still depends on top-window DOM selectors, legacy block registration, or unflagged classic meta boxes, this is the migration window to fix compatibility before the planned 7.0 release on April 9, 2026.

The Drupal CMS survey callout published on February 23, 2026 is timely and worth acting on. But teams should submit feedback with release context in mind: Drupal core 11.3.0 is current, Drupal 10.5.x is the transitional supported line, and Drupal CMS 2.x is the active stream.

The best use of this survey is to report friction that blocks real launches, not generic wishlist items.

I needed to get data out of Jira. Not just the title, but the full description, comments, and all attachments, packaged neatly for use in other scripts. The official way involves wrestling with an API that feels like it was designed by a committee that never spoke to each other. The unofficial way involves paying $20/month for a SaaS tool that is just a glorified curl command wrapped in a pretty dashboard. I chose the third way: build it myself.