A PHP upgrade is the sort of change I want to make deliberately. A homepage loading successfully tells me very little about what will happen when an editor saves a page, a form sends a message or a scheduled import starts later in the day.
For WordPress work, I think about the whole installation: core, the active theme, plugins, small custom functions and the server extensions those pieces expect. Changing the PHP version underneath all of that deserves more than a quick look at the front page.
In this tutorial: What this check is for; Before you start; 1. Establish a baseline before changing PHP; 2. Read the errors as clues about the data; 3. Exercise the paths that are easy to miss; Check the release and the way back.
What this check is for
This is the process I would use to assess an existing WordPress installation against PHP 8 before changing production. WordPress 5.6 introduced beta support for PHP 8.0; that is not a promise that every theme and plugin in an installation is compatible.
The aim is to find the actual failures, fix the code I own and identify dependencies that need a supported update. I would not use a successful test to claim that every possible journey has been covered.
Before you start
Record the existing WordPress, PHP, theme and plugin versions. Take a database and file backup, and check how to restore both. Keep the original runtime available while evaluating the replacement.
Create a private staging copy with the same relevant extensions and configuration. Prevent it being indexed and isolate external effects. A copied shop must not charge customers, email real recipients or send duplicate requests to production services simply because I am testing it.
1. Establish a baseline before changing PHP
I want to know which notices and failures already occur on the old runtime. Otherwise it is easy to attribute an existing problem to PHP 8 and spend time investigating the wrong change.
Run representative journeys on that baseline: signing in, editing content, uploading media, searching, submitting a safe test form and exercising any custom integration. Record what passed and what failed, including the relevant versions.
Then change the staging runtime and repeat the same checks. Keep the application code stable while comparing it, so the result is not mixed up with a new plugin release or unrelated theme work.
2. Read the errors as clues about the data
PHP 8 turns some previously tolerated situations into clearer failures. Passing an inappropriate value into a function can produce a TypeError rather than a warning and a result the application quietly continues with.
If a function expects an array, I prefer to understand why another value reached it rather than silence the error:
function cn_count_imported_items($items): int
{
if (!is_array($items)) {
throw new UnexpectedValueException('Expected an item array.');
}
return count($items);
}In real integration code, the calling boundary needs to catch that failure and report it appropriately. An invalid API response should not become an empty successful import, especially if an empty import would remove existing records.
I would also review removed functions, changed comparison behaviour and older dependencies against PHP's migration guide. A compatibility checker can help identify code worth inspecting, but it cannot prove that the application behaves correctly.
3. Exercise the paths that are easy to miss
The dashboard needs attention as well as the frontend. I check the actual page editor, metadata fields, media processing and the controls a client uses regularly.
For forms and shops, validation, failed submissions, payment-test flows and confirmation behaviour matter. For scheduled work, trigger a controlled test rather than assuming a job is fine because it did not run during the page checks.
Log errors privately on staging rather than displaying filesystem paths and internal details to visitors. Fix and repeat the affected journey. A cleaner log is useful evidence, but a suppressed log is not a compatibility fix.
Check the release and the way back
Before a production change, compare the final staging setup with the intended server configuration. Keep the deployment small, agree a suitable time and decide which results would make me roll back.
If the change involves files or database updates as well as PHP, a runtime switch alone may not undo it. The recovery plan needs to match the actual changes, and live data created after a backup needs to be protected.
I enjoy improving the foundations of a website. The satisfying result is knowing why it works on the new runtime, rather than getting away with a change that nobody has complained about yet.
References
The contemporary WordPress note on WordPress and PHP 8.0 explains the beta-support context. PHP's migration guide is the starting point for changed language behaviour.