When PHP 8 arrived, my first thought was not to upgrade a live WordPress site.
Major PHP releases are exciting from a development perspective, but a production WordPress website usually has more involved than core code. Themes, plugins, custom functions, composer packages and hosting configuration all affect whether an upgrade is safe. I wanted to understand what would break before going anywhere near the live server.
Creating A Separate Test Environment
The first step was creating a separate environment that matched the live site closely enough to be useful. That meant copying the theme, plugins, uploads and database into a local or staging setup, then switching only that environment to PHP 8. I did not want to test PHP 8 and a dozen unrelated changes at the same time because that would make the results harder to trust.
Once the environment was running, I turned on logging and started checking the obvious areas first: the home page, key templates, forms, admin screens and any custom functionality that had been built specifically for the site.
Checking The Theme
The theme was the easiest place to start because it was code I could control. I looked for deprecated patterns, older function calls and places where PHP warnings might appear because a value was not being checked before use. A small example would be assuming an array key exists without verifying it first.
// Risky if the key is missing.
$title = $settings['title'];
// Safer for compatibility testing.
$title = isset($settings['title']) ? $settings['title'] : '';That kind of change is not glamorous, but it removes avoidable noise. Compatibility work is much easier when the logs are not filled with warnings from code that could have been written more defensively in the first place.
Testing Plugins In Isolation
Plugins needed a different approach because I did not control all of that code. I updated what could be updated, then tested the site with the full plugin set active. If errors appeared, I disabled plugins one at a time to identify the source. That process is slower than guessing, but it gives a clearer answer.
I also paid attention to plugins that handled forms, payments, caching or custom fields because those tend to sit close to important site behaviour. A front-end animation failing is inconvenient. A form or checkout failing is a much bigger problem.
What I Took From It
Retrospectively, PHP 8 testing was less about the language release and more about discipline. The safest upgrades are usually the ones where the site is already maintainable. Clean theme code, up-to-date plugins and a reliable staging environment make the process much less stressful.
I still wanted to move forward, but not by treating a major runtime change as a routine button click. The better approach was to test, document what failed, fix what I controlled and delay the production upgrade until the whole stack was ready. That is not the fastest route, but it is the one I would trust with a client website.