# Upgrade WordPress to PHP 8.3 or 8.4 safely

> How to upgrade the PHP version of a WordPress site to 8.3 or 8.4 safely: check compatibility, test on staging, switch PHP-FPM, watch logs and roll back.

Source: https://zopanel.net/blog/upgrade-php-wordpress  
Updated: 2026-10-21

## Key takeaways

- PHP 8.2 stops getting security fixes on 31 December 2026, and WordPress recommends PHP 8.3 or newer.
- WordPress core supports PHP 8.3 since 6.4 and PHP 8.4 since 6.7, so plugins and themes are what usually break.
- The safe order is backup, update everything, test on staging with the debug log on, switch live, watch the logs.
- With PHP-FPM, rolling back means pointing the site back at the old version's socket, which takes seconds.

To upgrade the PHP version of a WordPress site safely, first check your current version under **Tools → Site Health → Info → Server**, take a full backup and update WordPress core, plugins and themes. Then switch a staging copy to PHP 8.3 or 8.4 with the debug log on, test the main pages and flows, and only then switch the live site and watch its error log for a few days. If something breaks, switch the PHP version back: with PHP-FPM that is a one-line change and takes seconds.

This guide covers the upgrade itself: which version to pick, what breaks in PHP 8.x, and how to switch by hand on Ubuntu 24.04 or in ZoPanel. For running several PHP versions side by side, see [multiple PHP versions on one server](/blog/multiple-php-versions).

## Why upgrade PHP now?

PHP 8.2 receives security fixes only until **31 December 2026**, and PHP 8.1 reached end of life on 31 December 2025 ([php.net supported versions](https://www.php.net/supported-versions.php), [php.net end of life](https://www.php.net/eol.php)). After that, new security holes in those versions are not fixed by the PHP project.

WordPress [recommends PHP 8.3 or greater](https://wordpress.org/about/requirements/); older versions down to 7.4 still run it but "may expose your site to security vulnerabilities". WordPress 7.0 dropped PHP 7.2 and 7.3, so it now requires PHP 7.4 or higher ([WordPress PHP compatibility handbook](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/)).

## PHP versions and WordPress support: timeline

The table combines PHP's release and security dates with the first WordPress version that supports each PHP branch, according to the [WordPress core handbook](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/) at the time of writing (October 2026).

| PHP | Released | Active support until | Security fixes until | Supported from WordPress |
| --- | --- | --- | --- | --- |
| 7.4 | 2019 | Ended | End of life 28 Nov 2022 | Minimum for WordPress 7.0 and later |
| 8.0 | 2020 | Ended | End of life 26 Nov 2023 | 5.6 |
| 8.1 | 2021 | Ended | End of life 31 Dec 2025 | 5.9 |
| 8.2 | 8 Dec 2022 | 31 Dec 2024 | 31 Dec 2026 | 6.1 |
| 8.3 | 23 Nov 2023 | 31 Dec 2025 | 31 Dec 2027 | 6.4 |
| 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 | 6.7 |
| 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 | 6.9 |

WordPress used to label new PHP versions "beta support" until 10% of sites ran them, because "WordPress is rarely used in isolation (without any theme or plugins)". The label was retired in May 2026, but the point stands: core support says nothing about your plugins.

### 8.3 or 8.4?

- **PHP 8.4** is the better target for most sites: security fixes until the end of 2028.
- **PHP 8.3** is the safe step if a key plugin is not ready for 8.4. Ubuntu 24.04 ships it in its own archive ([Launchpad](https://launchpad.net/ubuntu/noble/+package/php8.3)), so no extra repository is needed.
- **PHP 8.5** works with WordPress 6.9 and later, but plugin coverage is thinner.

## What breaks when you upgrade PHP for WordPress

Core is rarely the problem. Old plugins, themes, page builders and custom code in `functions.php` are. These are the changes from PHP's own migration guides that most often show up in WordPress error logs:

| From → to | Change | What you see |
| --- | --- | --- |
| 7.4 → 8.0 | `create_function()` and `each()` removed; wrong argument counts to built-in functions throw `ArgumentCountError`; `0 == "not-a-number"` is now false ([PHP 8.0 changes](https://www.php.net/manual/en/migration80.incompatible.php)) | Fatal errors, "critical error" page, odd comparison results |
| 8.0 → 8.1 | Passing `null` to non-nullable parameters of built-in functions is deprecated ([PHP 8.1 deprecations](https://www.php.net/manual/en/migration81.deprecated.php)) | Floods of "Passing null to parameter" notices |
| 8.1 → 8.2 | Dynamic properties deprecated unless the class uses `#[\AllowDynamicProperties]`; `utf8_encode()`/`utf8_decode()` and `"${var}"` interpolation deprecated ([PHP 8.2 deprecations](https://www.php.net/manual/en/migration82.deprecated.php)) | "Creation of dynamic property" deprecation notices |
| 8.3 → 8.4 | Implicitly nullable parameter types (`function foo(T $a = null)`) deprecated; `E_STRICT` constant deprecated ([PHP 8.4 deprecations](https://www.php.net/manual/en/migration84.deprecated.php)) | "Implicitly marking parameter $x as nullable is deprecated" notices |
| 8.3 → 8.4 | IMAP, OCI8, PDO_OCI and PSpell moved out of PHP to PECL ([PHP 8.4 removed extensions](https://www.php.net/manual/en/migration84.removed-extensions.php)) | Plugins that use `imap_*` functions fail unless you install the PECL extension |

Deprecations are warnings: the site keeps working, but they fill logs, hide real errors and point to poorly maintained plugins. Fatal errors, mostly from removed functions and extensions, are what take a site down.

### Is the PHP Compatibility Checker plugin still useful?

WordPress's [Update PHP guide](https://wordpress.org/support/update-php/) still suggests it, but its [plugin page](https://wordpress.org/plugins/php-compatibility-checker/) says it is no longer maintained, checks only up to PHP 8.0 and cannot detect runtime problems. For 8.3 or 8.4, a staging copy with the debug log on is the reliable test.

## Step by step: the safe upgrade order

### 1. Check what you run now

In wp-admin, open **Tools → Site Health → Info → Server** and note the PHP version. On the server, the socket in the site's `fastcgi_pass` line tells you the same; `php -v` shows only the command-line default.

### 2. Back up files and database

Keep a tested backup off the server. Switching PHP back fixes the code side, but a plugin that migrated its data under the new version may need the database restored. See our [website backup strategy](/blog/website-backup-strategy).

### 3. Update core, plugins and themes first

Update on the old PHP version and confirm the site works. Many "PHP upgrade" problems are really outdated plugins. Remove unused ones and replace any plugin with no update in years.

### 4. Make a staging copy and turn on the debug log

Create a staging copy (see [how to create a WordPress staging site](/blog/wordpress-staging)) and add this to its `wp-config.php`:

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

Errors go to `wp-content/debug.log` instead of the screen ([WordPress debugging docs](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)). The docs advise against these tools on production; on live, enable them only briefly.

### 5. Switch staging to the new PHP and test

Switch staging's PHP version (steps below) and click through what matters: home page, a post, search, forms, login, the editor, and for shops the cart and checkout. Then read `debug.log` and fix or replace whatever throws fatal errors.

### 6. Switch live and watch

Switch live at a quiet time, repeat the tests, and watch the logs for a few days: cron jobs and rare checkout options run only occasionally.

### 7. Know your rollback

If live breaks, switch PHP back first and investigate later. Only restore the backup if data was changed in a bad way.

## Manual upgrade on Ubuntu 24.04 with nginx and PHP-FPM

This assumes PHP-FPM behind nginx, as in our [WordPress on a VPS guide](/blog/install-wordpress-on-vps). PHP 8.3 is in Ubuntu 24.04's archive; for 8.4, add the `ondrej/php` PPA. Its [Launchpad page](https://launchpad.net/~ondrej/+archive/ubuntu/php) says Noble (24.04) and Jammy (22.04) can still use it, while newer releases should use `packages.sury.org`. It is a third-party repository, so you are trusting its maintainer with root.

### Install PHP 8.4 with the extensions WordPress uses

```bash
sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install -y php8.4-fpm php8.4-mysql php8.4-curl php8.4-xml \
  php8.4-mbstring php8.4-zip php8.4-intl php8.4-gd php8.4-imagick \
  php8.4-opcache php8.4-redis
```

The [WordPress hosting handbook](https://make.wordpress.org/hosting/handbook/server-environment/) lists `json`, `hash` and `mysqli` as required, and `curl`, `dom`, `exif`, `fileinfo`, `igbinary`, `imagick`, `intl`, `mbstring`, `openssl`, `xml` and `zip` as highly recommended, plus one object cache such as Redis. Compare what the old version has loaded with the new one so nothing is missing:

```bash
diff <(php8.3 -m) <(php8.4 -m)
```

Each version has its own `php.ini`: copy settings like `upload_max_filesize` and `memory_limit` into `/etc/php/8.4/fpm/`.

### Create a pool for the site

Give the site its own pool under the new version, running as the site's user. For example `/etc/php/8.4/fpm/pool.d/example.conf`:

```ini
[example]
user = example
group = example
listen = /run/php/php8.4-example.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 30s
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /home/example/logs/php-error.log
```

```bash
sudo php-fpm8.4 -t && sudo systemctl restart php8.4-fpm
```

### Switch nginx to the new socket

In the site's server block, change only the socket:

```nginx
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    # fastcgi_pass unix:/run/php/php8.3-example.sock;
    fastcgi_pass unix:/run/php/php8.4-example.sock;
}
```

```bash
sudo nginx -t && sudo systemctl reload nginx
```

A reload does not drop open connections. Watch PHP errors with `tail -f /home/example/logs/php-error.log` (the folder must exist and belong to the site's user) together with `wp-content/debug.log`, and the pool itself in `/var/log/php8.4-fpm.log`.

If cron runs wp-cli, call the matching binary, for example `php8.4 /usr/local/bin/wp cron event run --due-now`.

### Roll back

Keep the old pool running. Rolling back is the reverse: restore the old `fastcgi_pass` line, `nginx -t`, reload. Remove the old pool after a week or two without problems.

## Upgrading PHP for WordPress in ZoPanel

ZoPanel gives each hosting account its own PHP-FPM pool per PHP version, so the steps above become a few clicks, on the Free plan too.

1. **Install the version.** An administrator adds PHP versions under **Runtimes**. ZoPanel supports PHP 7.4 to 8.4.
2. **Update first, safely.** On the site's **WordPress** tab, **Update all** snapshots files and database, updates, checks `/` and `/wp-login.php`, and rolls back automatically if the site broke.
3. **Create staging.** **Create staging** copies the site to `staging.<your domain>`. Check its **PHP & config** tab shows the same version as live.
4. **Turn on debug logging.** In the staging site's **Maintenance** card, **Debug logging** turns on `WP_DEBUG` and `WP_DEBUG_LOG` without displaying errors to visitors.
5. **Switch PHP on staging, test, then switch live.** Change the version on the **PHP & config** tab; the pool is updated for you, with no nginx editing. No need to **Publish to live**: change the live site's version the same way, so its database is never overwritten.
6. **Roll back** by choosing the old version on the same tab.

Per-site PHP options set under **Tools → PHP settings for this website** are written to the site's `.user.ini`, so they stay with the site when you change version. Details are in the [WordPress Toolkit docs](/docs/wordpress) and [websites and PHP](/docs/hosting); see also [WordPress features](/features/wordpress).

To be upfront: ZoPanel's supported list currently stops at PHP 8.4. If you want PHP 8.5 today, check the latest release notes first.

## Conclusion

A WordPress PHP upgrade is low risk in the right order: back up, update everything, test on staging with the debug log on, switch live, watch the logs, keep the old version ready. With PHP 8.2 losing security fixes at the end of 2026, PHP 8.4 is the sensible target, with 8.3 as a stepping stone.

For staging, safe updates and a per-site PHP switch in one place, try ZoPanel: the Free plan covers 3 hosting accounts, 10 websites and 10 databases with no time limit. See [pricing](/pricing).

## Frequently asked questions

### Will upgrading PHP break my WordPress site?

Core supports PHP 8.3 since 6.4 and 8.4 since 6.7. Breakage usually comes from outdated plugins, themes or custom code, so test on staging and keep the old version ready.

### How do I check which PHP version WordPress uses?

In wp-admin, open **Tools → Site Health → Info** and expand **Server**. On the server, look at the PHP-FPM socket in the site's nginx config. `php -v` shows only the command-line default.

### Is it safe to skip from PHP 7.4 straight to 8.4?

Yes, if you test on staging. Expect more fixes than a one-version step: PHP 8.0 removed functions such as `create_function()` and `each()`, and later versions added deprecations.

### What should I do if the site shows a critical error after the upgrade?

Switch back to the previous PHP version first; that restores service in seconds. Then use `wp-content/debug.log` on staging to find the plugin or theme at fault, fix it and try again.

### Do deprecation notices mean my site is broken?

No. They warn that code will stop working in a future PHP version; the site keeps running. Log them, keep them off screen, and ask plugin authors to fix them.