9 posts tagged with "Review"

An automated AI review passed front-end work that had missing interactions, no hover states (the change an element shows when the pointer rests on it), colors that did not match the design and a laggy page. I think the concept behind the LLM (large language model) reviewer is wrong. It should work like a QA engineer and check the implemented page against the design, so I set up a front-end testing procedure that validates the work from the mockup, step by step.

WordPress 7.0 ships five block-editor changes that look small in a changelog and can still break custom patterns, mislead teams about hidden content, and let editors inject CSS into blocks that were never built for it. The dev notes landed on March 15, 2026, and cover content-only pattern editing, viewport-based block visibility, per-block custom CSS, expanded dimensions support and native text indent. Retest patterns and wrapper blocks before you upgrade, and treat the rest as permission to delete custom UI and CSS that plugin and theme teams have carried for years.

Ally shipped an unauthenticated SQL injection to 400,000+ WordPress sites, and exploit traffic arrived before many of them had updated. Plan for that order of events, because the next plugin will repeat it.

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.

Passkey credentials should not double as data-encryption keys. The design looks elegant in review, and then a user switches phones and their data stays behind with the old device. The passkeys critique made this failure mode hard to ignore, so these are the guardrails I would enforce in any architecture review before that design reaches production.

WordPress 6.9 added assertEqualHTML() to the core test tools. A test that fails because of whitespace in rendered HTML has lost its excuse. I reviewed the implementation and mapped migration patterns for plugin and theme test suites. My call: use it when a test checks what the markup means, and keep assertSame() wherever escaping or exact bytes are the contract.

If AI agents can open pull requests, secret scanning has to block the merge. A scanner that only reports will write accurate notes about a key that already reached the protected branch. My baseline has three layers: a pre-commit hook for fast feedback, a required CI check for enforcement, and a break-glass path (a controlled emergency bypass) that policy governs and audit logs record.

I reviewed the GitGuardian MCP integration pattern and tested it against agent-generated pull requests. MCP is the Model Context Protocol, a standard way for an AI agent to call external tools. My call: teams shipping AI-assisted code should adopt this now.

Most build regressions get reported as "it feels slower", long after the commit that caused them. I built a small Node CLI that benchmarks next@16.1.6 builds under cold and warm cache, compares the result with a baseline, and writes JSON that CI can diff. A run is flagged when its mean build time rises past a threshold you set.