How to Upgrade the PHP Version of a WordPress Site

Which PHP version for WordPress?

WordPress recommends PHP 8.3 or greater. Choose a supported branch that your entire site supports, rather than upgrading only to the oldest version offered. PHP 8.2 security support ends 2026-12-31; see the current branch support table.

Before changing production

1. Back up the complete files and database. Confirm where the backup is stored and how to restore it.
2. Update WordPress core, themes and plugins. Identify abandoned or custom extensions and ask their maintainers about PHP requirements.
3. Clone the site to staging with access controls and search indexing disabled; keep production indexable.
4. Record the domain's PHP handler, version and extensions. Run php -m for CLI, and inspect Site Health for the web runtime.
5. Test staging on the intended branch and prepare a low-traffic maintenance window and rollback instructions.

WordPress's upgrade guidance explains preparation and contacting the host. A plugin's “Tested up to” field refers to WordPress compatibility; check its PHP requirement separately.

Switch PHP by hosting type

Shared hosting or managed WordPress

Find the domain's PHP selector in the hosting panel, or ask support to make the change. Confirm the build, installed extensions and rollback options. Managed hosting does not remove the need to test your custom plugins.

cPanel

Open MultiPHP Manager, select the domain, select the target PHP version and click Apply. Test every changed domain. See the official MultiPHP Manager instructions.

Plesk

Open Websites & Domains → your domain → PHP. Select the desired installed version and handler, then apply the change. See Plesk PHP settings; contact your administrator if permissions hide the controls.

Self-managed Ubuntu / Debian VPS

Have the administrator install a supported FPM branch and matching extensions from the selected repository. Test it alongside the old pool. Point the domain's Nginx FastCGI upstream or Apache handler at the new FPM socket, validate configuration and reload. Package names and socket paths vary: confirm them from the installed configuration rather than copying a generic path.

Docker

Choose a WordPress image for your tested PHP branch in the Compose configuration, preserve persistent data volumes and record the prior image digest for recovery. Pull and recreate the service; custom images also need a rebuild with --pull.

docker compose pull wordpress && docker compose up -d wordpress
docker compose exec wordpress php -v

Docker documents that pulling does not start the new container. Confirm the running runtime after recreation.

After the switch

Verify the actual website PHP version in Site Health. Test homepage, admin login, forms, uploads, checkout, scheduled tasks and email delivery. Review the host's PHP-FPM error logs without exposing errors to visitors. Follow the CLI and web runtime comparison if the versions differ.

Rollback and recovery

If a critical journey fails, return the domain to the previously tested, patched handler or image, then investigate on staging. Restore the recorded web configuration and verify the runtime. Switching PHP back does not undo plugin database migrations; use the tested files/database restoration plan when needed, accounting for orders or edits made since backup. If the prior runtime is vulnerable, use maintenance mode or restrict access while arranging a supported recovery.