Test a PHP upgrade on a WordPress staging site first

Why test on staging

A PHP upgrade changes how the code of every plugin and theme runs. On the live site, a fatal error means visitors see “There has been a critical error on this website.” until you switch back. On a staging copy the same error costs nothing. The WordPress documentation itself says debug tools “are meant for local testing and staging installs” (developer.wordpress.org): staging is where you can look closely.

The plan

Check the code first. Before you copy anything, check every plugin and theme for the PHP version you’re moving to. It finds what you won’t think of clicking: an admin page you never open, an import that runs once a month.
Create the staging copy. In your hosting panel if it offers staging; otherwise with a backup plugin that clones, or a copy on your computer.
Mark it as staging (next section), so it can’t send emails to customers or end up in search results.
Switch PHP on the staging copy only, in its own PHP setting. Checking and changing your PHP version shows where.
Turn on a log that visitors can’t see: the WordPress debug log.
Test what matters: home page, every page template, forms, search, checkout with a test order, the admin screens you use, logged in and logged out.
Read the log. Fatal errors first, then warnings, then notices.
Fix, update or replace what broke, on staging, and test again.
Switch the live site at a quiet time, then watch its log for a few days.

Mark the copy as staging

WordPress knows four environment types. Its documentation: “Possible values are ‘local’, ‘development’, ‘staging’, and ‘production’. If not set, the type defaults to ‘production’.” (developer.wordpress.org) Our test site, without the setting:

Terminal · WP-CLI 2.12.0 on our test site (WordPress 7.1.2), 9 October 2026; real output

$ wp eval 'echo wp_get_environment_type(), "\n";'
production

On the staging copy, set it in wp-config.php, so plugins that respect it behave like a test site:

wp-config.php · the constant from the WordPress documentation; add it above the “stop editing” line of the staging copy only

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Also, on the staging copy:

Settings → Reading → Discourage search engines from indexing this site, unless your host already blocks staging from search.
Stop real emails: a shop or membership plugin on staging can email real customers. Many hosts block email from staging; check, or use a plugin that catches outgoing mail.
Turn off scheduled payments or syncs to other services (newsletters, accounting).

New to wp-config.php? How to edit it safely

Make a copy first. Download the file, or duplicate it, so you can put it back if something goes wrong.
Open the file. In your hosting control panel, open the File Manager and go to your WordPress folder (often called public_html). wp-config.php is usually there, next to the wp-admin and wp-content folders. You can also use an FTP program with the FTP details your host gives you.
Find the right place. Add new lines above the line /* That's all, stop editing! Happy publishing. */ (on older sites it ends with “Happy blogging”). If a line with the same name is already there, for example define( 'WP_DEBUG', false );, change that line instead of adding a second one.
Save, then reload your site. If it shows an error, put your copy back.

Not comfortable doing this? Ask your host’s support to make the change; it’s a routine request.

What staging can’t tell you

Staging shows the pages you open and the forms you send. It doesn’t show code you didn’t run: a monthly report, an import, an admin screen nobody opened that day. That’s why step 1 is a check of every plugin’s code: it reads all of it, whether you click it or not. Some problems depend on real data and appear only on the live site; “Undefined array key” is a typical one, which is why you watch the live log for a few days after switching.

Key takeaways

Use the host’s staging feature if it has one; it copies files and database and keeps PHP settings separate.
Mark the copy as staging: WP_ENVIRONMENT_TYPE set to “staging”, search engines discouraged, emails to customers stopped.
Switch PHP on the staging copy only, then test the pages and forms that matter, logged in and out.
Read the error log on staging: notices and warnings show up there first.
Staging shows what you test; check every plugin’s code for the new version too, since you can’t click everything.

Frequently asked questions

My host has no staging. What can I do?

A backup plugin that can clone the site, or a local copy on your computer, works for testing. The key is a separate copy whose PHP version you can change without touching the live site.

How long should I test on staging?

Long enough to try every page type and form, logged in and out, and to let scheduled tasks run once. For a shop, put a test order through.

Do I need to copy staging back to live afterwards?

Not for a PHP upgrade: you only change the PHP version of the live site once staging is clean. Copy files back only if you fixed or replaced plugins on staging.

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.

Get CompatNav on wordpress.org How it works

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.