Last week my phone would not stop ringing. A client called mid-afternoon, voice tight with panic. Their host had pushed a PHP 8.5 update and their WooCommerce store had fallen over. It wasn’t a full white screen of death, but there were enough critical warnings to make checkout look like a minefield. At that point it stops being an abstract question about “PHP 8.5 WordPress compatibility” and becomes about staying online and keeping the money coming in.
I get why people want them. PHP updates matter: you get the performance gains, the security patches, the newer syntax. But on WordPress, especially a heavily customized site, hitting the “update PHP version” button blind is a gamble with your business. The rest of the stack, your themes, plugins, and custom code, doesn’t always keep pace with PHP itself, and that’s usually where things go wrong.
PHP 8.5 and WordPress 6.9 compatibility
With WordPress 6.9 RC2, the core team has addressed all the reported PHP 8.5 issues, which is good news. The catch that trips people up is what support means at first: it usually starts as beta support. As make.wordpress.org/core explains, full support isn’t declared until at least 10% of all WordPress sites run that version, since WordPress almost never runs on its own. Your theme, your plugins, and your custom snippets all have to cooperate. PHP 8.5 and 8.4 will ship with WordPress 6.9 as beta supported, while 8.3 down to 7.2 stay fully supported.
My client’s first instinct, and honestly what I see all the time, was to switch the PHP version in cPanel and see what happened. Then, when errors showed up, they tried to “fix” them by disabling plugins at random or, worse, silencing the PHP warnings. Silencing warnings is like putting tape over the check engine light: the problem is still there, just hidden, waiting to take the site down during peak traffic. The actual fix had to happen at the compatibility level, and it starts with proper diagnostics.
How to update PHP without breaking things
So how do you move to PHP 8.5, or any future version, without losing your mind or your revenue? It takes discipline more than anything. You test first, on a staging environment that mirrors your live site as closely as you can make it, and you turn on debugging properly.
<?php
/**
* The base configuration for WordPress
*
* @link https://wordpress.org/documentation/article/editing-wp-config-php/
*
* @package WordPress
*/
// ... other constants ...
/** Enable bbioon debugging for development. */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // Log errors to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Hide errors from public view
@ini_set( 'display_errors', 0 ); // Ensure errors are not displayed by PHP
define( 'SCRIPT_DEBUG', true ); // Enable script debugging
define( 'bbioon_WP_CACHE', false ); // Disable caching during debugging
// ... rest of wp-config.php ...
On a staging site, this block in your wp-config.php does the heavy lifting: WP_DEBUG set to true, WP_DEBUG_LOG on as well, and WP_DEBUG_DISPLAY set to false. That logs every deprecation notice and fatal error to a file instead of showing them to your visitors. Then you work through that debug.log file and find the plugins, themes, or custom code behind the errors. Update what you can. If an update isn’t available, look for an alternative or get a developer to patch the incompatibility. That is how you actually get your PHP 8.5 compatibility solid.
So what’s the point?
The point is that WordPress Core preparing for new PHP versions is only part of it. Your whole stack has to be ready too. Don’t let the promise of better performance outweigh the risk of an unstable site. Test first and deploy later. It saves you the headaches, and it saves your clients from making those frantic phone calls.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
