Upgrading PHP on a WordPress Site Without Breaking It

Changing the PHP version takes one dropdown in the hosting panel and about a minute. Everything that matters happens before that click. To upgrade the PHP version of a WordPress site without an outage, you need to know which plugin, theme file or old snippet still calls something the new version no longer accepts, and you need to find out on a copy of the site.

The order that works: pick the target, bring the code up to date, scan what has no vendor, test on staging with the log open, then switch the live site.

Choose the target from the support calendar

PHP follows a fixed pattern. A new branch arrives late each year, receives bug and security fixes for two years, then security fixes only for two more, and then nothing. The supported versions page on php.net shows the current dates.

As this is written, 8.5 is the newest stable branch and has active support until the end of 2027. PHP 8.4 has active support until the end of 2026. PHP 8.3 receives security fixes until the end of 2027 and 8.2 only until the end of 2026. Everything older is end of life.

WordPress itself is rarely the limit. Current core runs on every supported PHP branch, and the WordPress requirements page recommends 8.3 or greater. Your plugins decide. A practical rule: choose the newest branch that every plugin you depend on says it supports, which is often the one just behind the newest. Avoid a target with less than a year of security support left, or you will repeat this job within months.

Find every PHP version the site uses

A server can run several PHP versions at once, and one site can touch more than one of them.

• The web version. Tools > Site Health > Info > Server shows the version that serves pages, along with the installed extensions.
• The command line version. Over SSH, php -v and wp --info show what WP-CLI and scripts use. It is often different from the web version.
• Cron jobs. Run crontab -l and look for lines that call php by a versioned path. A backup or import script pinned to an old binary keeps running old PHP after you switch the site.

Note where the setting lives, too. Most panels set PHP per domain, so a staging subdomain has its own value. On some Apache hosts the choice is written into .htaccess as an AddHandler line, and a leftover line from a previous host is the usual reason a change in the panel appears to do nothing.

Update the code before you update PHP

Compatibility fixes for new PHP versions reach you through plugin and theme updates. Old plugin versions on new PHP are the main source of fatal errors, so apply every pending update while the site is still on the old PHP version. Then go through the plugin list with three questions:

• Is it still maintained? A plugin with no release in years will not have been tested on a current PHP version. Decide now whether to replace it.
• Is the license active? A premium plugin with an expired license stopped receiving updates on the day it lapsed. You may be several versions behind without any notice in the dashboard.
• Is it encoded? Some commercial plugins ship encoded with ionCube and need a loader extension built for the exact PHP version. Ask the host whether that loader exists for your target.

What remains is code with no vendor behind it: the theme's functions.php, a child theme, files in wp-content/mu-plugins, entries in a code snippets plugin, and custom plugins. Nobody will send you an update for those.

Scan custom code for incompatibilities

PHP_CodeSniffer with the PHPCompatibilityWP ruleset reads PHP files and reports functions, syntax and behavior that changed between versions. Install it with Composer as the project's README describes, then point it at your own code and name the target:

vendor/bin/phpcs -p wp-content/themes/your-theme wp-content/mu-plugins \
  --standard=PHPCompatibilityWP --extensions=php \
  --runtime-set testVersion 8.3-

The trailing hyphen in 8.3- means "8.3 and above". Treat the report as a head start. A static scan finds removed functions and syntax problems, but not errors that depend on run-time data, and its rules can trail the newest PHP release.

Upgrade the PHP version on staging and read the log

Copy the live site to a staging site, switch only that copy to the new version and turn on logging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Now use the site the way people do. Load the home page and a few templates, log in, open the editor and save, submit each form, place a test order, run the scheduled tasks with wp cron event run --due-now. Then open wp-content/debug.log. The lines you find fall into a small number of families.

The log line contains	What it means	Usual fix
Call to undefined function with create_function(), each() or get_magic_quotes_gpc()	The function was removed in PHP 8.0	Update or replace the plugin. In your own code, use a closure, a foreach loop, or delete the check.
Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array	PHP 8 stops with an error where PHP 7 only warned	Make sure the value is an array before counting it
Deprecated: Creation of dynamic property	Allowed but discouraged since 8.2	Declare the property in the class, or wait for the plugin's update
Deprecated: ... Passing null to parameter	Allowed but discouraged since 8.1	Give the value a default or cast it to a string
Deprecated: Implicitly marking parameter ... as nullable	Allowed but discouraged since 8.4	Write the type as ?Type

Anything that starts with "Fatal error" has to be fixed before the live switch. Lines that start with "Deprecated" mean the code still runs and will stop running in a future major version, so they go on a list with an owner and a date.

Deprecation notices cause one real problem today. If they are printed into the page, they corrupt the JSON that AJAX and REST requests return, and buttons in the admin stop responding for no visible reason. Keep WP_DEBUG_DISPLAY off, and switch the debug log off again when the test is done so it does not grow without limit.

Settings and extensions that change with the version

On most hosts each PHP version has its own configuration, so custom limits do not travel with you. After the switch, compare these values with the old ones in Site Health: memory_limit, max_execution_time, upload_max_filesize, post_max_size and max_input_vars. The last one is easy to miss. When it is too low, large menus and product variation screens save only part of the form and show no error on screen.

Extensions are installed per version as well. Site Health lists missing recommended modules such as imagick, intl and zip. If the site uses a persistent object cache, confirm that its PHP extension exists for the new version before switching. A cache drop-in that cannot find its extension can take the whole site down.

Switch the live site and keep the way back open

1. Pick a quiet hour and take a fresh backup of files and database.
2. Change the version in the hosting panel, and update any cron jobs that name the old binary.
3. Clear the page cache and repeat the short version of the staging test.
4. Watch the server error log for the next week. Monthly reports, renewals and imports run code that your click-through never reached.

The way back is the same dropdown, and it works within a minute as long as the code still supports the old version. For that reason, do not combine the PHP switch with major plugin upgrades. Give the new version a week before you install anything that raises its own minimum PHP requirement.

When the upgrade needs a developer

A site with current, maintained plugins and little custom code usually passes the staging test on the first attempt, and you can do the whole job yourself. Get help when the log shows fatal errors in a custom theme or plugin, when an abandoned plugin has to be replaced without losing its data, or when the site is jumping from a very old version and the list of errors is long. Fixing and retesting that code is routine work under a WordPress maintenance plan, and a plugin nobody maintains is often better rebuilt as a small custom plugin than patched again. If the same server also runs a custom application outside WordPress, treat that as its own PHP migration and upgrade project with its own test plan.

Frequently asked questions

Which PHP version should a WordPress site run?

WordPress.org recommends PHP 8.3 or greater. Within that, choose the newest branch that all of your important plugins support, and check its end-of-support date on php.net so you know when the next upgrade is due.

Will a newer PHP version make my site faster?

Often, yes. Newer versions generally execute the same code more efficiently, which shows most in the admin and on pages that cannot be cached. It will not cure slow database queries, heavy plugins or oversized images.

Can I jump several PHP versions in one go?

Yes. There is no need to stop at each version in between. The more versions you cross, the more removed and changed features the code can run into, so the staging test matters more.

What if a plugin I need does not support the new PHP version?

Check for a newer release and ask the author about their plans. If there is no answer, replace the plugin or have a developer take over the code. Staying on an older PHP branch is acceptable only for as long as that branch still receives security fixes.