Upgrade WordPress to PHP 8.3 Safely: Step-by-Step Guide

- Back up files and database, and keep a copy off the server.
- Update WordPress core, theme and plugins first, and replace any plugin that is abandoned.
- Test PHP 8.3 on a staging copy, then switch the live site and check the error log.
Many WordPress sites stay on PHP 7.4 or 8.1 for one reason: someone is afraid an old plugin will break. That fear is fair, but staying on old PHP is now the bigger risk. The official PHP fixes for PHP2Shell cover 8.5.12, 8.4.27, 8.3.36 and 8.2.35, while 8.1 and older get no official release. This guide shows a safe, beginner-friendly way to move to PHP 8.3 and roll back quickly if something goes wrong.
Which PHP version should you move to?
| Your PHP now | Status | What to do |
|---|---|---|
| 8.4 or 8.5 | Fixed release exists | Stay, and update to 8.4.27 or 8.5.12 (or newer). |
| 8.3 | Fixed release exists | Good target. Make sure you are on 8.3.36 or newer. |
| 8.2 | Ends Dec 31, 2026 | Patch to 8.2.35 now, then plan the move to 8.3 or 8.4. |
| 8.1, 8.0, 7.4 | No official release | Only a vendor or host backport helps. Upgrade to 8.3 or newer. |
| 7.3 and older | No fix | Upgrade as soon as possible. Do it in steps with a staging copy. |
A panel label such as “PHP 8.3” does not show the patch level. Ask your host to confirm the PHP2Shell fix is installed, and double-check support dates on php.net before you plan.
The safe upgrade order
Step-by-step
WordPress: Tools → Site Health → Info → Server shows your PHP version. Note your WordPress, theme and plugin versions too.
wp core version php -v wp plugin list --fields=name,status,version,update_version
Use your host’s one-click snapshot or a backup plugin, and keep a copy off the server. With WP-CLI you can also export the database:
wp db export before-php-upgrade.sql
A backup you have never restored is only a hope, so try restoring it on a staging copy.
For each plugin, open its WordPress.org page and check three fields:
- Last updated: no update in about two years usually means abandoned (rule of thumb).
- Tested up to: should match a recent WordPress version.
- Requires PHP: must not demand something older than 8.3.
Pay extra attention to login and security plugins and backup or database plugins, because a break there can lock you out or stop your backups. Also search each one in the Patchstack or Wordfence vulnerability database.
wp core update wp plugin update --all wp theme update --all
Delete plugins and themes you do not use. Replace anything abandoned with a maintained alternative before you touch PHP.
Most good hosts offer a one-click staging copy. If yours does not, use a subdomain clone. On the staging copy, switch PHP to 8.3 (or 8.4) and turn on logging by adding this to wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Then visit the homepage, a post, the login page, search, contact forms and (for stores) the cart and checkout. Errors go to wp-content/debug.log. Remove the debug lines when you are done.
- Shared hosting: pick PHP 8.3 or 8.4 in cPanel MultiPHP Manager, Plesk or your host’s dashboard. The switch also restarts PHP for your site.
- VPS: update packages, then restart PHP-FPM (or Apache with mod_php).
- Docker: use a fixed tag such as
php:8.4.27-fpmand rebuild.
sudo systemctl restart php8.3-fpm
Do the switch at a quiet time of day, and keep the panel open so you can change back.
Check Tools → Site Health for the new version, then repeat your checks: login (including 2FA and social login), forms, checkout, scheduled backups. Read the PHP error log for new warnings. Finally, ask your host to confirm the PHP2Shell patch is installed, since the version label alone does not prove it.
Fix common errors after the upgrade
| What you see | Likely cause | Fix |
|---|---|---|
| White screen or “critical error” message | A plugin or theme does not support the new PHP | Read debug.log for the file name. Rename that plugin’s folder in wp-content/plugins through File Manager or FTP to switch it off. |
| Locked out of wp-admin | A login or security plugin broke | Rename its folder the same way, log in, then update or replace it. |
| “Deprecated” warnings in the log | Old code that still works for now | Not urgent. Tell the plugin author, or plan a replacement. |
| Checkout or payment fails | Old payment, shipping or courier plugin | Update it, ask the developer for a PHP 8.3+ release, or roll back PHP and replace it. |
| Backups stopped working | Old backup plugin | Update or replace it, and test a new backup and restore. |
- Switch PHP back to the previous version in your panel.
- Confirm the site works again.
- Fix the plugin on staging.
- Try the upgrade again.
Going back is only a short break. If you must stay on old PHP for a while, ask your host about a vendor-patched build and keep a firewall such as Cloudflare in front of the site.
If your site ran unpatched PHP on or after October 21, treat passwords and keys as possibly exposed. Change WordPress admin, hosting, SFTP and database passwords, refresh the security salts, and rotate payment and API keys. Full list in the main PHP2Shell guide.
Frequently asked questions
Will PHP 8.3 break my site?
Only if something on it is old. Well-maintained themes and plugins usually work. That is why you update first and test on staging before touching the live site.
Can I skip straight from 7.4 to 8.3?
You can, but test carefully, because old code has had more time to break. Use a staging copy, and if it fails, try 8.2 as a stop on the way, then move on.
Is 8.3 or 8.4 better?
Both have fixed releases (8.3.36 and 8.4.27). 8.4 lasts longer, 8.3 is more widely compatible. Pick the newest one your plugins handle on staging.
Does upgrading PHP alone make my site safe?
It closes the PHP2Shell hole only if the build is the patched one. You still need to update plugins, use two-factor login and keep backups.
My host only offers old PHP.
Ask for a vendor-patched package in writing. If they cannot provide one, move to a host that supports current PHP.
Next, read the full PHP2Shell protection guide for host status, the 12-point checklist and what to do if you were already hit.
This guide is general information, not a security audit. For business-critical or breached sites, involve your host or a security professional.

Comments