How to change the PHP version for your WordPress site

Your host just sent you a warning that your PHP version is old and "no longer supported". You have a WordPress site that works fine. You want to upgrade without waking up tomorrow to a white screen, a broken checkout, or a pile of fatal errors in the logs. This article is the safe path from "my site runs on PHP 7.4" (or 8.0, or 8.1) to a modern, supported PHP version, with the plugin-compatibility audit, the exact click paths for the two control panels you most likely use, the CLI-versus-web-server gotcha that trips up WP-CLI users, and the rollback procedure in case something breaks anyway.

The article assumes you do not have a developer-grade staging environment yet. If you do, skip to the compatibility audit and use your existing staging workflow for the upgrade. If you do not, the staging step is non-negotiable, and the WordPress staging environment guide covers four ways to set one up in an hour.

In short

• The target version in April 2026 is PHP 8.3 for most production WordPress sites (security support through December 2027, fully stable in WordPress, broad plugin compatibility). PHP 8.4 is the better choice for new sites or those with well-maintained plugin sets. PHP 8.5 is too new for production.
• Every PHP version below 8.2 is end-of-life and receives no security updates: 7.x (all branches), 8.0 (EOL November 2023), 8.1 (EOL December 2024). These are not acceptable targets, only starting points you are trying to leave.
• Do not upgrade blindly. Run a plugin/theme compatibility scan first, then test on staging, then flip production during a low-traffic window, and monitor the error log for 24 to 48 hours.
• The rollback button exists. On cPanel, Plesk, and most managed hosts, changing the PHP version takes one click. If the site breaks after the change, you can revert it just as fast. Knowing where the revert button lives before you click the upgrade button is the cheapest form of insurance.

Why PHP version matters for WordPress

Every WordPress request runs through a PHP interpreter. When that interpreter is old, three things go wrong that you cannot fix from inside WordPress.

Security. Out-of-support PHP versions stop receiving patches for newly discovered vulnerabilities. The PHP Supported Versions page tracks the active and security-support status for each branch, and as of April 2026 every PHP 7.x branch is fully end-of-life: PHP 7.4 reached EOL on 28 November 2022. Running an EOL branch means that every new CVE affecting your PHP version is a permanent vulnerability in your stack. You cannot patch it without upgrading.

Performance. PHP 8.x is substantially faster than PHP 7.x. Kinsta's PHP benchmarks measured WordPress 6.1 on PHP 8.1 at roughly three times the requests per second of PHP 5.6, and each 8.x minor version has continued to trim execution time. The PHP 8.0 release notes document the JIT compiler added in that release. The practical effect on a busy WordPress site is lower TTFB, lower CPU, and more headroom per PHP worker.

WordPress compatibility. Every WordPress version declares a minimum and a recommended PHP version, and new core features occasionally depend on language features only present in newer PHP. The WordPress PHP compatibility and versions table is the source of truth for this mapping. Running too old a PHP version eventually blocks you from upgrading WordPress itself, which blocks security patches on the WordPress layer too.

What PHP version WordPress recommends in 2026

The official WordPress requirements page recommends PHP 8.3 or greater. As of WordPress 6.9, PHP 8.4 is listed as fully supported in the core PHP compatibility table, and PHP 8.5 is listed as beta-supported.

Here is what that means in practice, broken down by the PHP versions a real WordPress site might currently be running and the versions you might be considering as a target.

One correction worth calling out because it appears in a lot of older how-to posts: WordPress 6.6 dropped support for PHP 7.0 and 7.1, not WordPress 6.7. WordPress 6.7's minimum is still PHP 7.2.24, and the January 2026 core post announcing the next drop explains that the next step is WordPress 7.0 (April 2026) raising the floor to PHP 7.4. If a tutorial tells you "WordPress 6.7 dropped PHP 7.x", it is conflating "EOL according to PHP.net" with "dropped by WordPress core". These are different events with different timing.

Prerequisites

• A full backup of files and the database. Not yesterday's scheduled backup. An on-demand backup taken right before you start, with a restore you have actually verified. A PHP upgrade is the single server change most likely to produce a white screen, and the backup is your rollback insurance in case the revert toggle alone does not restore you.
• A staging environment that mirrors production. Same server, same database, same WordPress version. The staging environment guide covers four ways to set one up. Skipping staging on a live site is how small PHP bumps turn into incident recovery.
• Admin access to WordPress for installing the compatibility checker plugin and reviewing the output.
• Control panel access (cPanel, Plesk) or SSH access to the server, depending on your host.
• Knowledge of which PHP version the site is running right now. Tools, Site Health in wp-admin shows it under "Info > Server > PHP version". WP-CLI's wp --info shows it too. If both sources report the same number, you are looking at the web SAPI version. If they disagree, see the CLI-versus-FPM section below.

Step 1: Check your current PHP version

Before you change anything, write down the exact PHP version you are on. You need it for the rollback plan.

The two reliable sources are:

From wp-admin: go to Tools, Site Health, Info, expand the Server section, and read the PHP version line. This reflects the PHP version the web server is using for WordPress.

From the hosting panel: in cPanel, open "Select PHP Version" or "MultiPHP Manager". In Plesk, open "Domains, your domain, PHP Settings". Both show the current version at the top.

Do not rely on <?php phpinfo(); ?> in a custom file during this phase unless you remember to delete it afterwards: the output contains internal paths and environment details you do not want publicly reachable on a live site.

Step 2: Audit plugin and theme compatibility before touching the PHP version

This is the step people skip and regret. A compatibility audit takes twenty minutes and catches the plugins that will produce fatal errors on the new PHP version before you have to troubleshoot them on a broken live site.

There are two tools worth using, depending on how much control you have.

Option A: PHP Compatibility Checker plugin (for site owners on shared hosting). WP Engine's PHP Compatibility Checker is a free WordPress plugin that scans every installed plugin and theme against a target PHP version from inside the WordPress admin. Install it, pick your target version in the dropdown (for example, "PHP 8.3"), pick whether to scan active or all plugins/themes, and run the scan. The output is a list of files and line numbers with any compatibility issues found.

The plugin is an old wrapper around the PHPCompatibility ruleset maintained by the community, so it occasionally flags false positives on very new PHP versions before the ruleset catches up. Treat its output as "here are the things worth looking at", not "here is everything that will break". Any plugin the scanner flags with an error is a real problem; warnings are worth reviewing but sometimes benign.

What to do with the results:

• Errors in plugins you actively use: check if the plugin has an update available. Most well-maintained plugins have shipped PHP 8.3/8.4 compatibility fixes by now. If an update exists, update the plugin first, then re-run the scan.
• Errors in plugins that have not been updated in over a year: replace the plugin or remove it. An unmaintained plugin that breaks on modern PHP is a permanent liability.
• Errors in themes: if the theme is commercial, check for an update or a support-ticket response. If the theme is a child of a parent theme, the error might be in the parent, which you should not edit directly.
• Warnings: review them, but most are deprecation notices about dynamic properties (PHP 8.2) or implicitly nullable parameters (PHP 8.4) that do not become fatal errors until PHP 9.0. You can ship with warnings; you cannot ship with errors.

Option B: PHPCompatibility on the command line (for developers). If you have SSH access and your plugins are in version control, running PHPCompatibilityWP directly through phpcs gives you more control and cleaner output than the plugin wrapper. Install it into a Composer project, point it at your wp-content/plugins and wp-content/themes directories, and run it against the target version:

phpcs -p . --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3 \
  --extensions=php \
  wp-content/plugins wp-content/themes

The --runtime-set testVersion 8.3 flag tells the ruleset which target PHP version to check against. You can also use a range like 7.4-8.3 to catch anything that works on 7.4 but breaks anywhere in the 8.x series.

Whichever tool you use, do not interpret a clean report as "the upgrade will be smooth". Static analysis does not execute code, and a plugin that uses runtime type coercion or variable function calls can still fail at runtime even when its files pass the scanner. Staging is the check that catches the rest.

Step 3: Test on staging

Clone the site to a staging environment (see the staging environment guide for the methods) and change the PHP version on staging to your target version using the steps in the next section. Then walk through the site like a visitor:

1. Homepage loads.
2. A blog post or product page loads.
3. Site search works.
4. A form submits (contact form, checkout, newsletter signup, whatever the site actually uses).
5. You can log in to wp-admin.
6. The dashboard loads without errors.
7. Plugin and theme update screens are reachable.
8. If the site is a WooCommerce store, you can add a product to the cart, reach checkout, and the test-mode payment completes. If the site has a booking plugin, you can create a test booking.

After the walkthrough, check the error log. On cPanel, that is "Metrics, Errors". On Plesk, "Logs". On self-managed servers, it is whatever file your PHP-FPM pool or Apache mod_php writes to. Deprecation notices that appear for the first time are expected; fatal errors, white pages, and 500 errors are not.

If staging passes, continue to step 4. If staging fails, you have the plugin name or theme name that broke it, which is exactly the information the compatibility checker was supposed to surface. Fix, remove, or replace the offender, and re-test.

Step 4: Change the PHP version in your control panel

cPanel (MultiPHP Manager and Select PHP Version)

cPanel exposes two interfaces for the same underlying feature. The MultiPHP Manager documentation is the authoritative reference.

1. Log in to cPanel.
2. In the "Software" section, click MultiPHP Manager (or, on older cPanel installs, Select PHP Version).
3. Tick the checkbox next to the domain whose PHP version you want to change.
4. In the "PHP Version" dropdown at the top right, pick your target version (for example, ea-php83).
5. Click Apply.

The change is effective on the next request. There is no "save and confirm" step: the version swap happens the moment you click Apply. Open your site in a private browser window and verify it still loads.

If the site shows a white screen, a 500 error, or the "There has been a critical error on this website" message, revert the version in the same dropdown back to the previous value. The revert is a single click and also takes effect on the next request. This is the rollback step I referenced at the top. For diagnosing what broke before you upgrade again, see the white screen of death recovery guide.

Plesk

1. Log in to Plesk.
2. Open Domains, click your domain, open PHP Settings.
3. In the "PHP support" section, pick your target version from the PHP version dropdown (for example, PHP 8.3.x).
4. Click OK (or Apply in newer Plesk versions).

Plesk applies the change on the next request. If the site breaks, revert the version from the same dropdown.

The Plesk PHP version documentation covers the per-domain versus server-wide distinction, which matters on Plesk: you can set the PHP version per domain (the usual case for WordPress) or change the default for the whole server.

Managed hosts (Kinsta, WP Engine, SiteGround, and similar)

Managed WordPress hosts typically expose a PHP version dropdown per site in the hosting dashboard, separate from cPanel. The click path is the same in spirit: pick the new version, click save, verify the site still loads.

The specific location varies by host, and the feature is named differently (Kinsta: "Tools, PHP engine"; WP Engine: "Utilities, PHP version"). If your managed host also runs your staging environment, change staging first, verify, then change production.

Self-managed servers (Apache mod_php, PHP-FPM pools)

On a VPS or dedicated server you are managing yourself, the "change PHP version" step is whatever your OS package manager and web-server configuration say it is. There is no single click path. The shape of the work, though, is consistent.

For PHP-FPM on Debian/Ubuntu with multiple PHP versions installed from deb.sury.org: each PHP version runs its own php-fpm service and its own UNIX socket or TCP port. Switching WordPress to a new PHP version means updating the server block (for nginx) or the virtual host (for Apache with mod_proxy_fcgi) to point at the new socket, then reloading the web server.

For nginx pointing at a PHP-FPM socket:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    # was: fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Reload nginx with sudo systemctl reload nginx. The reload is graceful and does not drop in-flight requests.

For Apache with mod_php: mod_php is tightly coupled to the Apache process. Switching PHP versions means disabling the old module, enabling the new one, and restarting Apache. On Debian/Ubuntu:

sudo a2dismod php8.2
sudo a2enmod php8.3
sudo systemctl restart apache2

Restart, not reload: switching PHP modules is not graceful.

For systems that use update-alternatives to pick a default PHP binary for the whole system:

sudo update-alternatives --config php

Pick the new version from the interactive menu. This changes the CLI default only: it does not affect Apache mod_php or PHP-FPM, which each load their own PHP version independently. This is the source of the WP-CLI gotcha in the next section.

Step 5: The WP-CLI versus web server version gotcha

Here is the trap that catches many site owners who use WP-CLI on cPanel, Plesk, or any multi-PHP hosting setup. WP-CLI runs under the command-line PHP binary (/usr/bin/php or whatever php resolves to in your shell). Your WordPress site runs under the web server's PHP, which is a completely separate binary. These are the same piece of software but they can be different versions on the same server.

On cPanel, you can change a domain's PHP version from 7.4 to 8.3 in MultiPHP Manager, the site starts running on 8.3 immediately, and WP-CLI commands keep running under the system PHP from /usr/bin/php, which might still be 7.2 or even 7.0. If you run wp plugin update --all after the upgrade, WP-CLI talks to the WordPress database under an old PHP and the commands can behave differently than they would if a browser had triggered the same code path. Worse, if you were using WP-CLI to verify that the site now runs on PHP 8.3 ("let me run wp php --info to double-check"), you are checking the CLI binary, not the web SAPI.

Confirm which PHP version WP-CLI is using:

wp --info

Look for the PHP binary and PHP version lines in the output. If the PHP version is not your target, WP-CLI is running under the wrong binary.

Fix it by pointing WP-CLI at the target PHP binary for a single command:

WP_CLI_PHP=/opt/cpanel/ea-php83/root/usr/bin/php wp --info

Or permanently for your shell by exporting the variable in your .bashrc / .zshrc:

export WP_CLI_PHP=/opt/cpanel/ea-php83/root/usr/bin/php

The exact path depends on the host. On cPanel, PHP versions live under /opt/cpanel/ea-phpXX/root/usr/bin/php. On Plesk, they live under /opt/plesk/php/X.Y/bin/php. On Debian/Ubuntu with the deb.sury.org repository, they live under /usr/bin/php7.4, /usr/bin/php8.3, and so on.

Why this matters: a WP-CLI command that runs migrations, bulk-updates plugins, or touches the wp_options cache under the wrong PHP version can produce results that differ from the web-triggered equivalent. Matching WP-CLI to the web SAPI version is a small adjustment that eliminates a whole class of confusing bugs.

Step 6: Verify after the change

Once production is on the new PHP version, do a quick check in the same shape as the staging walkthrough.

1. Open the site in a private browser window. Homepage loads, a post loads, the site search works.
2. Log in to wp-admin. The dashboard loads.
3. Tools, Site Health shows the new PHP version under "Info, Server".
4. Check the error log for the first 24 hours. On cPanel, that is "Metrics, Errors". On Plesk, "Logs". On a self-managed server, the error_log directive in your PHP-FPM pool config.
5. New deprecation notices are expected on a version bump and not urgent. New fatal errors or "Uncaught Error" lines are urgent and are the signal to either investigate immediately or roll back.
6. For WooCommerce or booking-heavy sites, check orders or bookings are still being created and processed. A PHP upgrade should not affect these, but silent failures in a scheduled action (like a recurring payment webhook) are worth watching for.

Expected output after step 3 (verifying Site Health):

Site Health under Tools, Info shows PHP version: 8.3.x (or whichever target you picked). The Server section shows the matching values for PHP extensions, memory limit, and execution time that your host exposes.

Step 7: Rolling back if something breaks

If you hit fatal errors or the site looks wrong after the upgrade, roll back first and debug afterwards. The rollback is the same dropdown you used to do the upgrade, in reverse.

On cPanel: MultiPHP Manager, pick the previous version (for example, ea-php74 if that was what you were on), click Apply. The site is back on the old PHP on the next request.

On Plesk: Domains, your domain, PHP Settings, pick the previous version in the dropdown, click OK.

On managed hosts: the dashboard typically lets you revert in one click.

On self-managed servers: revert the nginx or Apache change you made, reload the web server, verify.

If the rollback does not restore the site (rare but possible if the upgrade also triggered a failed plugin migration), restore from the backup you took at the start. The recovery path is the same as any white screen of death incident: get the site back to a known-good state, then diagnose the difference in a staging environment where you are not under pressure.

Once you have rolled back, read the error log. Almost every failed PHP upgrade I have seen traces back to one or two specific plugins or to a hand-edited snippet in functions.php. Identifying the offender on a staging environment, fixing or replacing it, and re-running the upgrade is the normal recovery path.

Common things that go wrong and how to read them

"Uncaught Error: Call to undefined function create_function()". create_function() was removed in PHP 8.0. A plugin or theme still calling it needs to be updated or replaced. This is the single most common PHP 7 to 8 upgrade failure and it has been fixable for years, but unmaintained plugins still carry the old code.

"Deprecated: Creation of dynamic property ...". PHP 8.2 deprecated dynamic properties: assigning a property on a class that did not declare it now emits a deprecation notice. WordPress core is fine (it added the #[AllowDynamicProperties] attribute, tracked in Trac #56034). Plugin code that has not been updated produces these notices in the log. They are not fatal in PHP 8.2, 8.3, or 8.4, but they become fatal in PHP 9.0, so treat them as a signal to update the plugin.

"Deprecated: ... implicit conversion from nullable type". PHP 8.4 deprecated implicitly nullable parameters: function foo(string $x = null) now emits a deprecation notice. The fix is function foo(?string $x = null). WordPress core is tracking this in Trac #60786. Third-party plugins are uneven, so expect some of these in the log after moving to 8.4. Not fatal yet; will be in PHP 9.0.

500 Internal Server Error with no PHP error in the log. This usually points at mod_php, PHP-FPM, or the hosting panel itself being misconfigured, not at your WordPress code. See the 500 Internal Server Error article for the server-level diagnosis.

"Maximum execution time of N seconds exceeded" right after the upgrade. A slow plugin that was already slow got caught by the PHP error reporter once you enabled WP_DEBUG_LOG. The fix is in the execution-time article, not in the PHP version.

When to escalate

If you have rolled back and you still cannot get the site stable, collect this information before asking for help:

• Exact WordPress version (from wp-admin or wp-includes/version.php).
• Exact PHP version before and after the upgrade attempt.
• The hosting control panel in use (cPanel, Plesk, Kinsta, WP Engine, something else).
• The first 30 lines of the error log from the moment the site broke.
• Any plugin or theme name that appears in the error log's stack traces.
• Whether the compatibility checker flagged the same plugin or theme before the upgrade.
• The exact text of any error shown on screen, or a screenshot.
• What you have already tried (which PHP version you rolled back to, whether plugin deactivation changed anything).

Send that to your host's support or to a WordPress developer. "The site is broken after a PHP upgrade" is not diagnosable; the list above is.

Planning the next upgrade

Once the upgrade is in place and stable, set yourself a calendar reminder for the next one. The PHP supported versions page gets updated when a branch moves from active support to security-only support to EOL. A rough rule that has served me well: when your current PHP version enters its final year of security support, plan the next upgrade. You are not trying to be on the bleeding edge; you are trying to never be on an EOL version.

For April 2026, that means: PHP 8.2 sites should plan a move to 8.3 or 8.4 well before December 2026. PHP 8.3 sites have more runway, through December 2027. PHP 8.4 sites have through December 2028 and are comfortably current. If you are still on 7.4, 8.0, or 8.1 today, the upgrade is overdue and this article is the path forward.