Upgrading WordPress to PHP 8: what breaks, how to test, and why you should not wait.
PHP 7.4 reached end of life in 2022. PHP 8.1 reached end of life in December 2025. If your WordPress site is still running old PHP, you are losing performance and security. Here is how to upgrade without breaking your site.
PHP 7.4 reached end of life in November 2022. PHP 8.0 followed in November 2023. PHP 8.1 reached end of life in December 2025. If your WordPress site is running any of these, you are running unsupported PHP with no security patches.
Most hosts still offer PHP 7.4 because site owners never upgraded. But running EOL PHP is like leaving your front door unlocked. It is not a matter of if, but when.
Here is how to upgrade to PHP 8.2 or 8.3 without breaking your site. I have done this migration on 50+ WordPress sites, and the process is the same every time.
Why upgrade (besides security)
PHP 8 is significantly faster than PHP 7.4. Just-in-time compilation, optimized internal functions, and better memory management mean WordPress pages load 10-30% faster on PHP 8.2 vs 7.4. That is a free speed optimization just for upgrading.
Also: plugin developers are dropping PHP 7.4 support. The newest versions of WooCommerce, Elementor, and WP Rocket require PHP 7.4 minimum, and many require PHP 8.0+. If you stay on old PHP, you will be stuck on old plugin versions, which are themselves security risks.
What breaks when you upgrade
PHP 8 introduced strict type checking, removed several deprecated features, and changed how some functions behave. The most common things that break in WordPress:
create_function()- removed in PHP 8.0. Old plugins and themes used this for dynamic callbacks. Replaced by anonymous functions (closures).strip_tags()with null - behavior changed in PHP 8.1. Plugins passing null as the second argument get a deprecation warning.array_key_exists()on objects - deprecated in PHP 8.1. Was used in some old plugins to check object properties.- Implicit float to int conversion - PHP 8.1 warns when you pass a float where an int is expected. Very common in old WooCommerce code.
- Named arguments breaking - PHP 8 introduced named arguments, which can break functions that use
func_get_args().
The result: you upgrade PHP, and your site shows a white screen or a fatal error. Usually one or two old plugins are the cause.
Step 1: Scan for compatibility (before touching anything)
Install the PHP Compatibility Checker plugin by WP Engine (free). Run a scan. It reads every PHP file in your plugins and themes and reports which ones use deprecated or removed functions.
The scan takes 5-10 minutes. When it finishes, you get a list: "Plugin X has 3 compatibility issues." Those are the plugins you need to fix or replace before upgrading.
Alternatively, use WP-CLI: wp plugin scan-php-compatibility (if you have the compatibility checker installed via CLI).
Step 2: Update everything
Before upgrading PHP, update WordPress core, all plugins, and your theme to their latest versions. Many plugin developers have already fixed PHP 8 compatibility in recent updates. An outdated plugin on PHP 7.4 might break on PHP 8, but its latest version might be fully compatible.
But be careful: updating 20 plugins at once can cause plugin conflicts. Update on staging first.
Step 3: Test on staging
Create a staging copy of your site. On staging, switch PHP to 8.2 (or 8.3 if available). Your hosting control panel usually has this option (cPanel - MultiPHP Manager, or in your host's dashboard).
Then test:
- Homepage loads
- Inner pages load
- Admin dashboard loads
- Contact form submits
- WooCommerce checkout works (if applicable)
- Check
debug.logfor deprecation warnings (they do not break the site, but indicate old code)
If something breaks, check debug.log. The error will name the plugin and the function. Fix or replace that plugin, then test again.
Step 4: Fix the incompatible plugins
For each incompatible plugin, you have three options:
Option A: Update. Check if the plugin has a newer version that supports PHP 8. If yes, update it.
Option B: Replace. If the plugin is abandoned (not updated in 12+ months) and does not support PHP 8, replace it with a maintained alternative. This is the best long-term option.
Option C: Patch. If you know PHP, fix the specific deprecated function call. For example, replace create_function('$a,$b', 'return strcmp($a,$b);') with function($a, $b) { return strcmp($a, $b); }. This is a temporary fix, the next plugin update will overwrite it.
Step 5: Switch PHP on production
Once staging works perfectly on PHP 8.2, switch production. Do this during low-traffic hours (late evening or weekend). After switching:
- Check the homepage
- Check
debug.logfor the first 30 minutes (any new errors?) - Check error logs in your hosting control panel
If something breaks that did not break on staging, roll back to PHP 7.4 immediately. The difference is usually a plugin that behaves differently with production data vs staging data.
Step 6: Verify performance improvement
Run PageSpeed Insights before and after the PHP upgrade. You should see a 10-30% improvement in server response time (TTFB). This is free performance, no code changes needed.
Which PHP version should you use?
As of 2026:
- PHP 8.2 - recommended. Stable, widely supported, active security patches until December 2026.
- PHP 8.3 - good if your host offers it. Active support until December 2026, security patches until December 2027.
- PHP 8.4 - newest. Some plugins may not be compatible yet. Test on staging first.
- PHP 7.4 or 8.0 - do not use. End of life. No security patches.
- PHP 8.1 - end of life as of December 2025. Avoid.
The cost of waiting
Every month you stay on PHP 7.4 or 8.1, you accumulate risk: security vulnerabilities, plugin incompatibility, and performance loss. The upgrade takes 2-4 hours including testing. The cost of not upgrading: one hack, one broken checkout, one 500 error during a traffic spike.
If you need help upgrading PHP on your WordPress site, including compatibility scanning and fixing broken plugins, message @wpservicelab on Telegram. See my migration service for pricing (PHP upgrade is technically a migration).
Have a site to recover?
Send the domain and a Wayback link. Honest scope and price before any work starts.