How to test PHP compatibility on a WordPress staging site
Short answer
A staging copy lets you run your site on the new PHP version without visitors seeing anything. Test in this order: 1. check the code of every plugin and theme for the new version, while staging still runs the old one; 2. switch staging to the new version, with a debug log on and messages hidden; 3. open every kind of page: home, posts, archives, search, forms, checkout, login and the admin area; 4. read the log and fix what appears. When staging is clean, switch the live site the same way. One limit: staging only shows what you click on, which is why the code check comes first.
Why staging
On the live site, a fatal error means visitors see a critical error page until you switch back. On a staging copy, the same error costs nothing. WordPress’s documentation says its debug tools “are meant for local testing and staging installs” (developer.wordpress.org): staging is where you can look closely. How to get a staging copy: staging for a PHP upgrade.
One thing specific to late 2026: a staging copy is reachable on the internet like your live site, so it needs the October security fixes too (which versions).
Step 1: check the code first
Before switching anything, check every plugin and theme for the PHP version you’re moving to. This finds what will break on pages you would never think to open, such as an admin screen of an old plugin. CompatNav, free on wordpress.org, does it on your own server and lists each finding with file and line:
Fix what will break, on staging, before step 2.
Step 2: switch staging, with a log
- Turn on logging, not display:
WP_DEBUGandWP_DEBUG_LOGtotrue,WP_DEBUG_DISPLAYtofalse(the WordPress debug log). - Switch staging’s PHP version in your hosting panel (cPanel, Plesk and others).
- Check that it took effect: Site Health on staging shows the new version.
Step 3: open every kind of page
Pages to open on staging
- Home page
- A post and a page
- A category or archive page, and search results
- A form: contact, newsletter, comment
- Shop pages: product, cart, checkout (in test mode)
- Login, password reset, a member page
- The admin: dashboard, editor, each plugin’s settings page
- Anything with a custom template
To keep it on paper, print this page: the website’s menus are left out.
Step 4: read the log
Each line names a file: the folder after wp-content/plugins/ or wp-content/themes/ tells you which plugin or theme. Lines starting with “Fatal error:” must be fixed before going live; lines starting with “Deprecated:” can wait for updates (the difference). Value-dependent problems, like “Trying to access array offset on value of type null”, show up only here.
When staging is clean, do the same switch on the live site, at a quiet time.
Key takeaways
- Order: check the code first, then switch staging, then click through, then read the log.
- The code check finds what will break on pages you’d never think to open.
- The staging run finds what depends on your data, which no code check sees.
- Hide messages and log them: WP_DEBUG and WP_DEBUG_LOG on, WP_DEBUG_DISPLAY off.
- Staging must run the same patched PHP version as live will, for example 8.4.27 or later.
Frequently asked questions
My host doesn’t offer staging. What now?
Check the code on the live site (a check that only reads files is safe there), fix what it finds, back up, and switch at a quiet time with a way back ready.
Does staging need the October 2026 security patch too?
Yes: a staging copy is a website like any other, reachable on the internet. Run it on a patched version (8.2.35, 8.3.36, 8.4.27, 8.5.12 or later), and remove it when you’re done.
How long should I test?
Until every kind of page has been opened and the log is quiet. Then keep the log on the live site for a week after switching.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.