How to update the PHP version of a WordPress site

PHP is the language WordPress, its plugins and its theme are written in, and the server runs one version of it for your site. That version belongs to the hosting account. You change it in the hosting control panel, or the host changes it for you. Nothing inside WordPress can.

As of October 10, 2026, WordPress 7.1 is listed as compatible with every PHP version php.net still supports. The risk in a move is old code in a plugin or a theme, and an extension the new version was never given. So do the work in this order: see what the site runs now, bring everything up to date, try the new version on a copy, switch, check the site, and know the way back before you need it.

See which PHP version the site runs

If the dashboard cannot be reached, the check file in how to fix "Your PHP installation appears to be missing the MySQL extension" prints the website's PHP version without WordPress.

What WordPress tells you about your PHP version

WordPress asks WordPress.org about the PHP version it finds itself on, and repeats the answer in two places.

On the Dashboard, an administrator sees a box headed "PHP Update Recommended" or "PHP Update Required". It opens with one of these sentences, with the site's own version in the brackets:

Each has a shorter form that leaves out the words about security updates, for a version that still receives them. The box ends with a button, "Learn more about updating PHP".

Under Tools, Site Health, on the Status tab, one result is about PHP:

Each version in the two tables is one that draws that sentence on WordPress 7.1, going by what WordPress.org answered about it on October 10, 2026.

Where the thresholds come from

Almost all of it is WordPress.org's answer, not a figure in WordPress's code. WordPress sends its PHP version to api.wordpress.org/core/serve-happy/1.0/ and keeps the answer for a week. The answer holds a recommended version, a minimum version, and three yes-or-no answers: whether the version is still actively supported, whether it still receives security updates, and whether it is acceptable. The box on the Dashboard appears when "acceptable" is no.

One figure is in the code. WordPress 7.1 counts any PHP lower than 8.0 as below the minimum a future WordPress will need. For those versions it shows "PHP Update Required" whatever WordPress.org answers.

On October 10, 2026, WordPress.org answered with a recommended version of 8.3 and a minimum of 7.4. Its requirements page said the same that day. It recommends "PHP version 8.3 or greater", and says WordPress "also works with PHP 7.4+", with a warning that these older versions "have reached their official End Of Life and may expose your site to security vulnerabilities".

An old PHP also holds updates back. On the Updates screen, a WordPress release that needs a newer PHP shows a sentence that begins "You cannot update because" and names the PHP version it requires. Under a plugin on the Plugins screen, the line begins "There is a new version of", names the plugin, and goes on "available, but it does not work with your version of PHP."

Which PHP versions still get fixes

php.net supports each PHP branch for four years. For two years from its first stable release a branch is fully supported: faults and security issues are fixed. For two more it gets fixes for critical security issues only. Then it is end of life.

As its Supported Versions page read on October 10, 2026:

• PHP 8.4 and 8.5 are in active support.
• PHP 8.2 and 8.3 get security fixes only, and 8.2's end on December 31, 2026.
• PHP 8.1 and every older branch is end of life.

Those dates move on every year. The WordPress and PHP end-of-life checker lists the PHP versions with both of their dates, read from php.net twice a day, and says where the version you choose stands today.

Which version to move to

Choose a version that passes four tests.

• php.net still supports it, and preferably for years to come, so that you are not doing this again in a few months.
• It is at least the version WordPress recommends, which was 8.3 on the day above.
• Your WordPress runs on it. WordPress's compatibility table lists PHP 7.4 to 8.5 for WordPress 7.0 and 7.1, and stops at PHP 8.4 for WordPress 6.7 and 6.8. If the site is behind, update WordPress before PHP.
• Your host offers it.

That table is about WordPress alone. It says the core software "is tested and compatible with the versions in this list", and notes that WordPress is rarely used without a theme or plugins. Those are what the next section is for.

Before you switch

The two commands list each plugin's and each theme's "Requires PHP":

Read the result for what it can tell you, which is less than it seems.

• "Requires PHP" is a minimum. WordPress checks only that the server's PHP is at or above it. No header says how new a PHP the code runs on, so a plugin that declares 5.6 can still stop on 8.3.
• An empty value means the author declared nothing. Together with a plugin that has not been updated in years, that marks the ones to watch on the staging copy.
• unavailable in the update column means a newer release exists and needs a higher PHP than the one WP-CLI is running on. When an update is waiting and WordPress.org says what it needs, the requires_php column shows that, not what the installed release declares.

WordPress.org's own page on updating PHP still suggests a plugin named PHP Compatibility Checker for this step. That plugin's listing says it "is no longer actively maintained", that it checks compatibility "up to PHP 8.0", and that it "cannot detect runtime compatibility issues" because it does not run your code. Do not count on a scan. Run the site on the new version, on the copy, and read what PHP says.

Turn the debug log on

In wp-config.php, replace the line define( 'WP_DEBUG', false ); with these three, above the line that says "stop editing". They write every message to wp-content/debug.log and keep it off the pages.

With WP-CLI:

How to turn on WordPress debug mode explains each line, and how to keep the log out of public view on a live site.

Switch the version at your host

The switch is made in the hosting account. WordPress.org says so on its page about updating PHP: "PHP is installed on your website's server, so updating it involves either interacting with your host's settings or asking your provider to do it for you."

In most hosting control panels it is a menu: find the PHP settings for the domain, choose a version from the list, and apply. The name of the screen differs from host to host.

• cPanel's MultiPHP Manager lists the account's domains with the PHP version each one uses. Its documentation gives the steps: select the checkbox for the domain, select the version from the "PHP Version" menu, and click Apply. A version that is not in the menu is not installed on the server or not available for your account. The host can also switch this screen off.
• On hosts that use CloudLinux's PHP Selector with cPanel, the screen is "Select PHP Version", in the Software section. Its documentation describes it as the place to manage "PHP extensions and options for the particular PHP version", and says changes are saved automatically.
• Anywhere else, look for "PHP" in the panel or the host's help pages, or ask the host. WordPress.org's page links to a list of hosts' own instructions and has a short message you can send.

Three things do not change the PHP version.

• The WordPress dashboard. The buttons in the PHP box are links. "Learn more about updating PHP" opens WordPress.org's page, or a page of the host's if the host has set one. A second button, "Update PHP", shows only when the host has given WordPress the address of its own screen for it.
• A plugin. A plugin is PHP code. It runs inside the PHP the server has already started.
• wp-config.php. It is a PHP file too, read after PHP has started. It holds WordPress's settings, not the server's.

On a cPanel server the choice can be recorded in the site's .htaccess file, which the panel writes: cPanel's documentation says that when you set a domain's PHP version "the system creates its .htaccess file". It strongly recommends setting the version only through its own screens, and warns that a version set by hand can behave unexpectedly. So do not write those lines yourself, and do not delete them when you tidy .htaccess.

One version at a time, or straight to the target?

No rule says either. php.net publishes a migration guide for each step, such as 8.2 to 8.3, and each has a list of backward incompatible changes and a list of deprecated features. Going from 7.4 to 8.3 crosses four of those guides at once. On a staging copy, try the version you want to end on. If more breaks than you can sort out, an in-between version that php.net still supports is a place to stop for a while.

After the switch

Do this on the staging copy first, and again on the live site when you switch it.

One missing extension takes the whole site down. If every address shows "Your PHP installation appears to be missing the MySQL extension which is required by WordPress.", the new version has no mysqli. That page has the fix, and nothing is lost meanwhile.

What the log says

A line that begins PHP Deprecated is code that works on this PHP and that a later version is due to stop running:

Nothing is broken yet. The path names the plugin or theme, here one in a folder named example-gallery. This counts the deprecation lines for each plugin and theme folder, the most first:

Update what it names, or send the lines to the author. Lines whose file is inside WordPress's own folders are left out of the count. Read those in the log itself.

A line that begins PHP Fatal error or PHP Parse error is a page that stopped. This prints the last three:

When you are done, set WP_DEBUG back to false in wp-config.php, remove the other two lines and delete wp-content/debug.log. With WP-CLI:

If a page shows a critical error on the new version

"There has been a critical error on this website." is what WordPress shows in place of a page when PHP stops with a fatal error. After a change of PHP version, suspect a plugin or a theme that calls something the new version no longer has. The line in the log looks like this:

PHP 8.0 removed create_function(), so code that still calls it stops on every version from 8.0 on. The path names the plugin, here example-slider. You have three ways forward.

• Set the PHP version back at the host. The site comes back on the old version, and you can deal with the plugin without visitors watching.
• Use WordPress's recovery mode. Open the login page. When the failing file belongs to a plugin or a theme, WordPress emails the site's administrator a link, and through that link the plugin is paused for you alone so that you can log in and deactivate it. How to fix "There has been a critical error on this website" goes through it, and through what to do when no email comes.
• Switch the one plugin off and stay on the new version. With WP-CLI, by the name of its folder:

The two extra options keep WP-CLI from loading the broken code while it runs.

Then update the plugin if a newer release exists, send the line to its author, or replace it. If two plugins seem to be involved, how to find and fix a WordPress plugin conflict shows how to prove which one it is.

Going back to the previous version

Use the same menu and choose the version the site ran before. Changing the PHP version does not rewrite the site's content or its database, so going back needs no restore. Restore the backup only if something was saved wrongly while the site was failing, and set the PHP version back first: that is the order WordPress.org gives.

Two things can stand in the way. A version the host has removed is no longer in the list. And cPanel's documentation says that if the system administrator has limited a domain's PHP version, you cannot use MultiPHP Manager to set the domain back to its original version. In either case, write to the host. WordPress hosting problems: how to tell whether the fault is the host or the site has a message you can adapt.

Treat an end-of-life version as a place to wait, not to stay. Every month there is one more without security fixes, and the plugins and WordPress itself move their minimum up in the meantime.

If a plugin stops on the new version and you cannot find which one or why, a one-time fix from WP Ministry covers one issue on one site and starts with a free diagnosis, which gives you a written cause and a fixed quote.