How to Upgrade the PHP Version on WordPress Safely

To upgrade the PHP version on WordPress safely, first check which version you run and which ones are still supported, then scan your plugins, theme and custom code for compatibility, test the new version on a staging copy, and only then switch the live site with a rollback plan ready. Most sites upgrade without trouble. The ones that break usually have old plugins or untested custom code, and testing finds those problems before your visitors do.

Why PHP version matters

PHP is the programming language WordPress runs on. Your host installs a specific version of it on your server. Each PHP version gets about four years of support from the PHP project: two years of bug and security fixes, then two more years of security fixes only. After that, it reaches end of life and gets no fixes at all.

Running an end-of-life version means any new security hole in PHP itself stays open on your server. It also means plugin developers gradually stop testing against it. Newer PHP versions are also often faster, though the gain depends on your site.

Which PHP versions are supported right now

Here is the status as of October 2026, from the official PHP supported versions page and the PHP end-of-life list:

The WordPress requirements page recommends PHP 8.3 or greater. WordPress still runs on PHP 7.4, but the same page warns that older versions have reached end of life and may expose your site to security vulnerabilities.

If you are on PHP 8.2, it stops getting security fixes at the end of this year. If you are on 8.1 or older, you are already past end of life. In both cases, plan the upgrade now. We usually recommend moving to 8.3 or 8.4. You can check which PHP versions the current WordPress release supports on the WordPress PHP compatibility table.

Step 1: Find your current version

In the WordPress dashboard, go to Tools > Site Health > Info and open the Server section. It lists the PHP version. Site Health will also warn you on its Status tab if your version is outdated.

While you are there, note the database version too. An old MySQL or MariaDB version is often a sign the whole server needs attention, not just PHP.

Step 2: Take an inventory

List every plugin and theme, its installed version, and when it was last updated. Pay close attention to:

• Plugins not updated in two years or more. These are the most likely to break on newer PHP.
• Plugins removed from the WordPress.org directory. Removal can mean a security issue or that the author stopped maintaining it.
• Premium plugins with expired licenses. You may be several versions behind without knowing it.
• Custom code. A custom theme, a site-specific plugin, or snippets in functions.php. Nobody has tested these against new PHP except you.

This inventory is part of what we measure in a technical debt review. Our guide on how to measure WordPress technical debt explains how we score it.

Step 3: Scan code for compatibility

You can scan code for known PHP compatibility problems with PHP_CodeSniffer and the PHPCompatibilityWP ruleset, which is tuned to avoid false alarms from code WordPress already handles. Run it from a development copy of the site:

composer require --dev phpcompatibility/phpcompatibility-wp:"*"
vendor/bin/phpcs -p wp-content/plugins wp-content/themes \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3- \
  --extensions=php

The testVersion 8.3- setting means “check compatibility with PHP 8.3 and newer.” A scan finds many issues, but not all of them. It cannot see problems that only appear at runtime, which is why testing in Step 4 still matters.

What usually breaks

When we upgrade older sites, the problems tend to fall into a few groups. Each PHP release lists its changes in the php.net migration guides.

• Removed functions. PHP 8.0 removed functions like create_function() and each(), which old plugins still use. Calling them causes a fatal error.
• Stricter errors. PHP 8.0 turned many old warnings into errors. Code that “worked” by accident can stop working.
• Deprecations. Later versions deprecate patterns such as passing null to many built-in functions (PHP 8.1) and creating dynamic properties (PHP 8.2). Deprecations do not break the site yet, but they fill your error log and will become errors in a future version.

Step 4: Test on staging

Create a staging copy of your site on the new PHP version. Many hosts let you pick the PHP version per site from the control panel. Then:

1. Turn on error logging in wp-config.php so you can see problems without showing them to visitors.
2. Click through every important page type and feature: homepage, posts, shop, cart, checkout, forms, search, login, and the admin dashboard.
3. Run any scheduled tasks, imports or integrations by hand.
4. Read the PHP error log and sort issues into fatal errors, warnings and deprecations.

// wp-config.php on staging
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Manual clicking misses things. We run automated browser tests and unit tests against both the old and new PHP versions and compare the results. Our guide to automated WordPress testing with Playwright and PHPUnit explains how that works. For the broader process, see safe WordPress updates with staging and tests.

Step 5: Fix what you find

For each problem, choose the simplest fix:

• Update the plugin or theme. Most compatibility fixes already exist in newer versions.
• Replace it. If a plugin is abandoned, find a maintained alternative that does the same job.
• Patch custom code. Fix the specific lines. These fixes are usually small once you know where the problem is.
• Ask the vendor. For premium plugins, report the error with the exact message from the log.

Avoid “fixing” errors by hiding them. Turning off error reporting makes the log quiet, but the code is still broken.

Step 6: Upgrade the live site

When staging runs clean:

1. Take a full backup of files and database, and confirm you can restore it.
2. Pick a low-traffic time.
3. Switch the PHP version in your hosting control panel, or update the PHP-FPM pool on your own server.
4. Clear all caches: page cache, object cache and OPcache.
5. Check the key pages and features from your staging list.
6. Watch the PHP error log closely for the next 24 to 48 hours.

Your rollback plan is simple: switch the PHP version back. On most hosts this takes a minute, which is why you should know exactly where the setting is before you start.

If you manage your own server, check that all the PHP extensions your site needs are installed for the new version. Extensions like imagick, intl and redis are installed separately for each PHP version, and a missing one is a common cause of errors after an upgrade. Our article on WordPress server tuning covers PHP-FPM and OPcache settings worth revisiting at the same time.

Make PHP upgrades routine

PHP releases a new version every year, so upgrades are not a one-time project. Sites that upgrade every year or two have small, easy jumps. Sites that wait until a version is years past end of life face many breaking changes at once.

Keep plugins updated, remove ones you do not use, and keep custom code under test. Then each PHP upgrade becomes a routine maintenance task instead of an emergency.

Need help upgrading PHP?

We upgrade PHP on WordPress sites as part of regular maintenance, including sites with years of custom code. We test against the new version first and fix what breaks before it reaches your visitors. Learn more about our WordPress maintenance service or contact us to check where your site stands.