How to Update PHP in WordPress

Who controls PHP on a WordPress site

WordPress is a PHP application. It runs on whatever PHP version the server provides, and it cannot upgrade PHP from the dashboard. Depending on your setup, the PHP version is controlled by:

Shared or managed hosting: a setting in your hosting control panel (cPanel, Plesk or a custom dashboard).
A VPS or dedicated server: the packages installed on the operating system and the PHP-FPM pool your web server uses.
Containers: the base image in your Dockerfile or compose file.

This guide focuses on the first two, which cover most WordPress sites.

Before you start: decide on a target version

Pick a PHP branch that is both supported upstream and supported by your WordPress version.

Check the current WordPress requirements page for the recommended PHP version.
Check the PHP compatibility table in the WordPress Core Handbook. It shows which PHP versions each WordPress release supports and notes where support is still “beta”.
Check PHP’s own lifecycle. As of October 2026, 8.2 receives security fixes only until 2026-12-31, while 8.3, 8.4 and 8.5 are supported for longer. Branches 8.1 and older are end of life. See the PHP security support lifecycle.

In practice, the newest PHP branch that WordPress core fully supports and that your plugins and theme support is the right target. Being one branch behind the newest is fine if your extensions need it.

Step 1: Record what you have now

Go to Tools → Site Health → Info (WordPress 5.2 and later) and note:

Server → PHP version and PHP SAPI
WordPress → Version
Active theme and Active plugins, with their versions

You can click Copy site info to clipboard at the top of the Info tab and save it in a text file. This is your baseline if you need to roll back or ask a developer for help. The how to check your PHP version guide lists other methods.

Step 2: Update WordPress, plugins and themes first

Newer PHP versions remove deprecated features and tighten type handling. Plugin and theme authors usually fix these problems in their own releases, so outdated extensions are the main source of breakage.

Update WordPress core to the latest release.
Update all plugins and themes.
Remove plugins and themes you do not use. Inactive code still runs if someone requests its files directly, and it still has to be compatible.
For each remaining extension, check its WordPress.org page or vendor documentation for a “Tested up to” note or stated PHP requirements. Treat an extension that has not been updated for several years as a risk.

Custom code (a child theme, a site-specific plugin, snippets in functions.php) is your responsibility. If you have a developer, ask them to scan it with PHPCompatibility, described in PHP upgrade planning.

Step 3: Make a full backup

Back up both parts of the site:

Files: the whole WordPress directory, including wp-content and wp-config.php.
Database: a full export.

Use your host’s backup tool or a backup plugin, and confirm that you can download the archive. A backup you have never restored is a hope rather than a plan; if possible, test a restore on a staging copy.

Step 4: Test on a staging site

Many hosts offer one-click staging. If yours does not, create a copy on a subdomain and protect it with a password or block search engines.

Create the staging copy.
Switch staging to the target PHP version (Step 5 shows how).
Enable error logging on staging only. In wp-config.php:
```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
```
Errors are written to wp-content/debug.log instead of being shown to visitors.
Walk through the site: the home page, key templates, forms, search, checkout and account pages if you run a shop, the admin dashboard, and the editor.
Read debug.log. Fatal errors must be fixed before going live. Deprecation notices are warnings about future versions and can usually be tracked and resolved later.

Step 5: Change the PHP version

cPanel: MultiPHP Manager

Open MultiPHP Manager in the Software section.
Tick the domain.
Choose the new version from the dropdown and click Apply.

cPanel: Select PHP Version (CloudLinux)

Open Select PHP Version.
Choose the new version and click Set as current.
Review the Extensions list. WordPress commonly needs extensions such as mysqli, curl, gd or imagick, mbstring, xml, zip and intl. Extensions are configured per version, so they may not carry over automatically.

Plesk

Go to Websites & Domains and select the domain.
Open PHP (or PHP Settings).
Choose the new version and handler, for example an FPM handler, and click Apply or OK.

Your own server (Debian/Ubuntu example)

Install the new version alongside the old, then point the site’s FPM socket at it.

sudo apt install php8.4-fpm php8.4-mysql php8.4-curl php8.4-gd \
  php8.4-mbstring php8.4-xml php8.4-zip php8.4-intl

Package names and availability depend on your distribution and repositories. Then edit the site’s nginx configuration:

fastcgi_pass unix:/run/php/php8.4-fpm.sock;

Copy any custom settings (memory_limit, upload_max_filesize, max_execution_time) from the old version’s php.ini and pool file to the new one, then test the configuration and reload:

sudo nginx -t && sudo systemctl reload nginx

Keep the old FPM service installed until you are confident in the change.

Step 6: Verify on production

Reload Tools → Site Health → Info → Server and confirm the new PHP version.
Check the Status tab for new warnings, such as a missing extension.
Repeat your test walkthrough from Step 4.
Watch your PHP error log and any uptime monitoring for the next day or two.

Rolling back

If something breaks, switch back to the previous version using the same control panel screen. This is usually immediate. Rolling back PHP does not undo database changes made by plugin updates, which is why the backup in Step 3 matters.

Rolling back is a temporary measure. If your previous branch is end of life or close to it, fix or replace the incompatible plugin rather than staying put.

After the update

Keep patching. Your host or package manager should deliver patch releases within the branch, for example 8.4.27 after the October 2026 security release. Confirm the patch level periodically with the PHP version checker.
Hide the version. If your host exposes an X-Powered-By: PHP/... header, ask them to set expose_php = Off, or set it yourself if you control php.ini.
Turn off debug mode on production if you enabled it anywhere.
Review overall hardening. The WordPress security overview covers further steps, and the website security checker inspects your site’s public configuration.