8 posts tagged with "WordPress"

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.

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.

WordPress site configuration usually lives in wp-admin and in the memory of whoever changed it last. I built SyncForge Config Manager to export that configuration to YAML, diff it, import it with guardrails and roll it back when a release goes wrong. The YAML is the boring part; the value is one deterministic workflow across the admin UI, REST and WP-CLI, instead of three interfaces that behave almost the same.

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.

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.

The Wordfence blog feed lists vulnerable plugins, but it cannot tell a team whether its own sites run them. I built a WordPress plugin that adds wp wordfence-audit plugins and answers that question from the current feed. It is a triage step for teams that already read the feed. A full vulnerability database still covers what the feed never publishes.