- Run a PHP version that is still receiving security support. An unsupported version is an unpatched one, whatever else it does.
- Check yours under Tools, Site Health, Info, Server in the WordPress admin. No plugin needed.
- Newer PHP is faster on the same code, usually by a meaningful margin, at no cost beyond the upgrade itself.
- Test on a staging copy first. Almost every upgrade problem is one abandoned plugin, and you want to find it there.
- If a plugin blocks the upgrade, that plugin is the problem to solve. Staying on unsupported PHP to keep it running is the worse trade.
Which PHP version should WordPress run on?
The newest version that your plugins and theme support and that still receives security updates. PHP releases get two years of active support followed by one year of security-only fixes, then nothing. Running past that final date means known vulnerabilities in your language runtime with no fix coming.
| Version status | What it means for you |
|---|---|
| Actively supported | Bug fixes and security fixes. The version to be on |
| Security support only | Security fixes only. Fine, but plan the next move |
| End of life | No fixes at all. Upgrade is the only response |
| PHP 7.x | All branches are end of life. Upgrade regardless of anything else |
Check the current dates at php.net/supported-versions before deciding. They move every year.
"It still works" is not the same as "it is supported"
An end-of-life PHP version keeps running perfectly. That is the problem: nothing tells you it has stopped receiving patches, and a vulnerability disclosed after the end date is never fixed. Some hosts backport a handful of fixes, which is not the same as upstream support.
# From the command line
php -v
# The version PHP-FPM is actually serving, which can differ from the CLI
php-fpm8.3 -v
curl -sI https://example.com/ | grep -i x-powered-by
# Via WP-CLI
wp eval 'echo PHP_VERSION . PHP_EOL;'
# In the admin: Tools, Site Health, Info, ServerHow much faster is a newer PHP version?
Enough to be worth the upgrade on its own. Every release since PHP 7.0 has improved throughput on the same unchanged code, and PHP 8.x added the JIT plus a long list of internal optimisations. On WordPress the practical gain is fewer CPU seconds per request, which means more concurrent visitors on the same server.
You change no code. The same WordPress install simply uses less CPU per request on a newer runtime.
Measure it on your own site rather than trusting a benchmark, because your plugin mix is what decides the real number. Time a page before and after on a staging copy with the same content and cache state.
# Time to first byte, cache bypassed, ten runs
for i in $(seq 1 10); do
curl -s -o /dev/null -w '%{time_starttransfer}\n' \
"https://staging.example.com/?nocache=$RANDOM"
done | awk '{s+=$1; n++} END {printf "avg TTFB: %.3fs over %d runs\n", s/n, n}'
# CPU time for a WordPress bootstrap
time wp eval 'echo "ok";'?nocache= parameter defeats page caching so you are timing PHP rather than a static file.Leave the JIT off
PHP 8's JIT helps compute-heavy workloads and does very little for a web request dominated by database and I/O time. It has also produced hard-to-diagnose shared memory faults on PHP 8.3 in production, which is why we keep it disabled across our platform. Keep OPcache on, which is a large and reliable win, and leave the JIT alone.
How do I upgrade PHP safely?
On a staging copy first, always. The upgrade itself takes minutes; finding out on the live site which plugin does not survive it takes considerably longer and costs you traffic while you work it out.
- 1Update everything else first. WordPress core, all plugins and the theme, the same discipline as patching the server underneath. Half of PHP compatibility problems disappear at this step, because the fix already shipped and was never installed.
- 2Check for abandoned plugins. Anything not updated in over a year is the likely blocker. Find replacements before the upgrade, not during it.
- 3Clone to staging and switch that copy to the new PHP version.
- 4Run a compatibility scan with PHPCompatibility, then actually exercise the site: checkout, forms, admin, media upload, and any integration.
- 5Watch the error log while you do it. PHP 8 turned many old notices into fatal errors, so a warning you ignored for years may now be a white screen.
- 6Switch production during a quiet window, and keep the old version installed so you can switch back in seconds.
# Ubuntu, using the ondrej PPA
sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install -y php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-bcmath php8.3-imagick
# Both versions installed side by side. Point the site at the new socket:
# fastcgi_pass unix:/run/php/php8.3-fpm.sock;
sudo nginx -t && sudo systemctl reload nginx
# Switching back is one line and a reload
# fastcgi_pass unix:/run/php/php8.1-fpm.sock;Do not forget the extensions
Installing php8.3-fpm alone gives you a PHP with almost nothing in it. WordPress needs mysql, curl, gd or imagick, mbstring, xml and zip at minimum. Missing mbstring produces broken characters; missing gd breaks image resizing. Check with php -m before switching anything over.
# PHPCompatibility via composer
composer global require phpcompatibility/php-compatibility
phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.3 \
--extensions=php --ignore='*/vendor/*,*/node_modules/*'
# Or from inside WordPress
wp plugin install php-compatibility-checker --activate
# Plugins not updated in over a year: the usual blockers
wp plugin list --fields=name,version,update,statusWhat breaks when upgrading to PHP 8?
PHP 8 was stricter than 7.x in ways that turn long-tolerated sloppiness into fatal errors. Five patterns account for most of what you will see, and all five are in plugin or theme code rather than WordPress core.
| Error | Cause | Fix |
|---|---|---|
| Uncaught TypeError: passed null | Passing null where a string was expected | Update the plugin; it is a known PHP 8 change |
| Cannot use function return value in write context | Old syntax removed in PHP 8 | The plugin needs updating |
| Call to undefined function | An extension is not installed | Install the missing php8.3-* package |
| Deprecated: Required parameter follows optional | Argument order PHP 8 rejects | Update the plugin |
| White screen, nothing in the browser | A fatal error with display_errors off | Read the PHP error log, not the page |
The recurring theme is that the plugin needs updating. If no update exists, that plugin is the actual problem.
# Follow the PHP error log while you reload the page
sudo tail -f /var/log/php8.3-fpm.log
sudo tail -f /var/log/nginx/error.log
# Turn on WordPress debug logging (staging only)
# in wp-config.php:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);
tail -f wp-content/debug.logOne abandoned plugin should not pin your PHP version
If a plugin only runs on an unsupported PHP version, the cost of keeping it is running an unpatched language runtime on a public server indefinitely. Replace the plugin, or pay someone to patch it. Staying behind is the more expensive option, it just does not present a bill until something goes wrong.
Once you are on a current version, the next gain is in how PHP is configured rather than which one it is. Tuning PHP-FPM for performance covers worker sizing and OPcache. On G7Cloud you can switch PHP version per site from the dashboard, with both versions available and a rollback that takes seconds. See our WordPress hosting.
Frequently asked questions
What PHP version should I use for WordPress?
The newest version that still receives security support and that your plugins and theme work with. Check the current dates at php.net/supported-versions. Anything on the PHP 7 branch is end of life and should be upgraded regardless of other considerations.
How do I check which PHP version my WordPress site uses?
In the admin, go to Tools, Site Health, Info, and open the Server section. On the command line, php -v shows the CLI version, which is often different from the one the web server uses. curl -sI https://yoursite.com | grep -i x-powered-by shows the serving version.
Will upgrading PHP break my WordPress site?
It can, and it is almost always one abandoned plugin rather than WordPress itself. Update everything first, test on a staging copy, and keep the old PHP version installed so switching back takes one config line and a reload.
Is PHP 8 faster than PHP 7 for WordPress?
Yes, measurably, on the same unchanged code. The gain shows up as less CPU per request, which means more concurrent visitors on the same server. Measure it on your own site with a staging copy, since your plugin mix decides the real figure.
Should I enable the PHP JIT for WordPress?
No. A WordPress request is dominated by database and I/O time rather than computation, so the JIT gains little, and it has caused shared memory faults on PHP 8.3 in production. Keep OPcache enabled, which is a large reliable win, and leave the JIT off.
What PHP extensions does WordPress need?
At minimum mysqli, curl, gd or imagick, mbstring, xml and zip, with intl and bcmath needed by many plugins and by WooCommerce. Installing php8.3-fpm alone leaves you without them. Check what is loaded with php -m before switching the site over.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →
