A lot of WordPress sites are still running PHP versions that stopped receiving security updates years ago. When I mention this to clients, the reaction is usually the same: “Will upgrading break the site?” It’s a fair question. I’ve seen upgrades go wrong, with white screens, fatal errors and checkout pages that stopped working.
But staying on an old version isn’t safe either. End-of-life PHP versions get no security patches, newer plugins gradually drop support for them and they’re noticeably slower than current releases. The upgrade has to happen eventually. The goal is to make it boring.
Here’s the process I follow to upgrade PHP on WordPress sites safely.
Why upgrading PHP matters
Security
Each PHP version receives active support for about two years, then security fixes for a further period, and then nothing. Once a version reaches end of life, newly discovered vulnerabilities in PHP itself are never fixed for it. You can check current support dates on the official PHP website’s supported versions page.
Performance
Each major PHP release has brought performance improvements. Moving from an old PHP 7 version to a current PHP 8 version often makes uncached WordPress requests noticeably faster, with no other changes.
Compatibility
WordPress core supports a wide range of PHP versions, but plugins and themes increasingly require newer ones. Eventually, you’ll find that updates for a plugin you rely on won’t install because your PHP version is too old.
Step 1: Find out what you’re running
Check your current PHP version in WordPress under Tools, then Site Health, then Info, in the Server section. Or from the command line:
Be aware that the command line PHP version can differ from the version your web server uses. Site Health shows the version WordPress actually runs on.
Also check which target versions your host or server offers. On managed hosting, you usually switch versions from the control panel. On your own server, you’ll install the new version alongside the old one.
Step 2: Choose the target version
Aim for a version that’s actively supported and that your plugins and theme support. Jumping straight to the newest release isn’t always wise. If it was released very recently, some plugins may not have caught up yet. A version that’s been out for several months is usually a safer target.
If you’re on a very old version, consider upgrading in steps, for example from PHP 7.4 to 8.1 and then to a newer 8.x release, rather than jumping several major changes at once. It’s easier to diagnose problems when fewer things change at the same time.
Step 3: Update everything first
Before changing PHP, update WordPress core, all plugins and your theme on a staging copy. Many compatibility issues are already fixed in newer plugin versions. Upgrading PHP while running two-year-old plugins is asking for trouble.
Also remove plugins you don’t use. Every inactive plugin is code that might break, and it’s often the abandoned ones that cause problems.
Step 4: Check plugin and theme compatibility
Look at each plugin’s listing for its required and tested PHP versions. For premium plugins and custom code, check the developer’s documentation or changelog.
Scan the code
For a more thorough check, use PHP_CodeSniffer with the PHPCompatibility standard. It scans code for features that were removed or changed in newer PHP versions:
Focus the scan on custom themes and custom plugins, because those are the most likely to contain outdated code and the least likely to be updated by anyone else. Static analysis can produce false positives, so treat results as a list of things to review, not definite errors.
Step 5: Set up a staging site on the new version
Never upgrade PHP directly on a live site you haven’t tested. Create a staging copy and switch it to the new PHP version.
On many hosts, staging environments let you choose the PHP version independently. On your own server, you can run the staging site in a PHP-FPM pool that uses the new version.
Turn on error logging on staging so you can see warnings and errors:
Errors will be written to wp-content/debug.log.
Step 6: Test thoroughly
Click through the site as a visitor and as an administrator. Focus on:
- The homepage and key landing pages.
- Different templates: posts, pages, archives, search.
- Forms, including submission and email notifications.
- The admin dashboard, editor and plugin settings pages.
- WooCommerce: product pages, cart, checkout with a test payment, order emails and the order admin.
- Membership, booking or LMS features.
- Scheduled tasks and imports.
After testing, read debug.log carefully. Warnings and deprecation notices may not break anything today, but they often become fatal errors in the next major PHP version.
Common PHP 8 problems and fixes
Most issues I encounter fall into a few categories.
Removed functions
Some old functions were removed entirely. For example, create_function and each were removed in PHP 8.0. Code using them causes fatal errors. They need rewriting, usually with anonymous functions and foreach loops.
Stricter type handling
PHP 8 throws errors in situations where PHP 7 only gave warnings, such as passing the wrong type to built-in functions or treating null as an array. Code like count() on a non-countable value now throws a TypeError.
Changed string and number comparisons
PHP 8 changed how strings are compared with numbers. Code that relied on loose comparisons like 0 == “abc” being true may behave differently. These bugs are subtle, so test any custom logic that compares values loosely.
Deprecated dynamic properties
PHP 8.2 deprecated creating properties on objects that weren’t declared in the class. This produces deprecation notices in older plugins. It’s not fatal yet, but it’s a warning that the code needs updating before a future version makes it an error.
Required parameters after optional ones
Function definitions with optional parameters before required ones trigger deprecation warnings in newer versions. Simple to fix in custom code, but worth noticing.
Step 7: Fix or replace problem code
For each issue:
- If it’s in a repository plugin, check whether an update fixes it. If not, report it to the developer or look for an alternative.
- If it’s in a premium plugin, contact the vendor.
- If it’s in your custom code, fix it.
- If it’s in an abandoned plugin, replace the plugin. This is often the moment to finally retire it.
Retest after each fix.
Step 8: Plan the live upgrade
Once staging is clean:
- Take a full backup of files and database.
- Choose a quiet time for the switch.
- Know exactly how to roll back. On most hosts, switching back to the old PHP version takes seconds.
- Switch the live site to the new version.
- Immediately test the same key paths: homepage, forms, checkout, admin.
- Watch error logs for the next few hours and days.
WordPress has a recovery mode for fatal errors. If a plugin causes a fatal error, administrators receive an email with a special link to log in and deactivate the problem plugin. Make sure the admin email address is correct before the upgrade.
Step 9: Clean up
After a week or so of stable running:
- Turn off debug logging on staging and production.
- Update the PHP version in your documentation.
- On your own server, remove the old PHP version if nothing else uses it.
- Set a reminder to check PHP support dates again in a year.
Keep a simple upgrade log
Note the date, old and new versions, what broke and how it was fixed. Next year’s upgrade becomes far quicker when you know which plugins caused trouble last time.
Frequently asked questions
Will upgrading PHP break my site?
It can if plugins, themes or custom code use outdated features. Testing on staging first, with updated plugins and error logging enabled, catches nearly all problems before they reach your live site.
Which PHP version should I use?
A currently supported version that your plugins and theme support, ideally one that has been out for a few months. Check the official PHP supported versions page for dates.
Does WordPress itself support the latest PHP?
WordPress core is usually compatible with new PHP versions quickly, sometimes with beta-level support at first. Plugins and themes are more often the limiting factor.
My host is forcing a PHP upgrade. What should I do?
Ask for a staging environment on the new version, test thoroughly and fix issues before the deadline. If the host allows, upgrade on your own schedule rather than waiting for a forced switch.
Final thoughts
Upgrading PHP is one of the best things you can do for a WordPress site’s security and speed, and with the right process, it’s rarely dramatic. Update everything first, scan custom code, test on staging with error logging, fix what breaks and switch the live site with a rollback plan ready. Make it a yearly habit, and you’ll never be stuck on an unsupported version again.
