WordPress 6.9.3 is out, and it shows how far apart “technically correct” and “safe on real legacy code” can sit. If you woke up to a blank front end after yesterday’s update, you are not alone. The Core team had to ship a fast-follow release because a security hardening change in 6.9.2 took out themes that lean on one particular PHP trick.
Yesterday, WordPress 6.9.2 patched ten security vulnerabilities. Reports of the white screen of death started coming in shortly after, from themes passing stringable objects to the template_include filter instead of plain strings. The documentation has always said that filter expects a string, but PHP itself is happy to accept an object with a __toString() method almost anywhere a string is wanted. WordPress 6.9.3 closes that gap so those sites load again.
The regression: stringable objects vs. primitive strings
I have run into this pattern before. A developer builds a Path object that handles directory separators or lazy loading, hooks into template_include, and returns the object. Day to day, PHP treats it like a string and nobody notices. Then Core adds a strict type check or sanitization, which is what 6.9.2 did, and the object fails is_string(). The template loader ends up with nothing, and the visitor gets a blank page.
The code in those themes usually looks something like this:
<?php
/**
* The Naive Approach: Returning an object instead of a string.
* This broke in 6.9.2 but is patched in WordPress 6.9.3.
*/
add_filter( 'template_include', function( $template ) {
class bbioon_TemplatePath {
public function __toString() {
return get_stylesheet_directory() . '/custom-template.php';
}
}
return new bbioon_TemplatePath(); // This is a "Stringable Object"
} );The fix in WordPress 6.9.3 casts those objects back to strings before the loader tries to include the file. If you write themes, refactor the hook to return a primitive string anyway. It is cleaner and it stops Core updates from tripping over your types.
WordPress 7.0 Beta 4 and the road ahead
Alongside the emergency patch, WordPress 7.0 Beta 4 is now live with the same ten security fixes plus the 6.9.3 regression fix. If you are testing the WordPress 7.0 features, pull it now. The April 9th release date has not moved, but an extra beta was added to the cycle for stability.
On production sites I would run the update through WP-CLI. It is faster, and it tells you right away if the PHP process hangs. Just run:
wp core updateIf this WordPress 6.9.3 mess is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Update now
Don’t sit on this. Even if your site survived 6.9.2, you are running a version with a known regression, so WordPress 6.9.3 is the only way to keep the security patches and a working front end at the same time. Put the upcoming 7.0 on a staging server too, because Core is not going to get any looser about types.
