Updating PHP Without Breaking WordPress: A Checklist

PHP updates are one of the highest leverage changes you can make to a WordPress site. Moving from an old PHP version to a current one (PHP 8.1 through 8.3 is the mainstream range right now, with 8.3 plus OPcache a solid default) can meaningfully improve execution speed and closes off known security issues in older PHP branches. But PHP major and minor version bumps also break things, usually because a plugin or theme calls a function that changed behavior or was removed. The fix is not to avoid updates. It is to update with a process. Here is the checklist.

Step 1: Know what you are running and what you are moving to

Start by confirming your current PHP version and your site’s basic health.

wp cli info
wp eval 'echo phpversion();'
wp core version
wp plugin list --update=available
wp theme list --update=available

Update plugins and themes to their latest versions before you touch PHP. Outdated plugins are the single biggest source of PHP compatibility failures, and many maintainers only test against current PHP versions in their latest releases.

Step 2: Run a compatibility scan

Before flipping the PHP version anywhere, scan your active plugins and theme for known incompatibilities. A dedicated compatibility checker plugin will flag deprecated function calls, removed APIs, and syntax that will throw fatal errors on newer PHP. Run the scan, review every plugin marked as an issue, and check whether an update is available that resolves it. If a plugin has not been updated in a long time and shows compatibility warnings, that is a signal to look for an actively maintained replacement, not just a PHP problem to work around.

Also check your theme. Custom themes and older commercial themes with embedded PHP logic are common culprits, especially around array handling, string functions, and object property access, all of which got stricter in recent PHP versions.

Step 3: Test on staging, not production

Never change the PHP version on a live site as your first test. Clone the site to a staging environment (most managed hosts, including ServerBorn, offer one click staging that mirrors your live site’s files and database) and set the staging copy to the target PHP version there first.

With staging on the new PHP version, turn on debug logging so you can see everything:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Then walk through the site like a real visitor and like an admin:

• Load the homepage, a handful of posts or products, and any custom templates
• Submit a contact form, place a test order if it is an e-commerce site, and check any checkout or payment flow
• Log into wp-admin, edit a post, upload a media file, and save settings on your major plugins
• Check any custom code in must-use plugins or the theme’s functions.php

After each pass, tail the debug log:

tail -f wp-content/debug.log

Fatal errors and warnings that break page rendering need to be fixed before you go further. Notices about deprecated functions from third party code that still executes correctly are lower priority, but note them so you can push the plugin author for a fix or plan a replacement.

Step 4: Know which deprecation warnings you can ignore, for now

Newer PHP versions are stricter about things like passing null to non-nullable function parameters, implicit type coercion, and certain string-to-number comparisons. This generates a lot of deprecation notices, and not all of them are urgent.

• Safe to defer: deprecation notices logged in debug.log that do not appear on screen and do not affect front end output or admin functionality. These are warnings about future removal, not current breakage.
• Fix before going live: any fatal error, any warning that appears in visible page output, and anything that breaks a checkout, form submission, or login flow.
• Watch closely: notices tied to plugins that handle payments, user data, or security. Even if the site functions today, these deserve a proactive fix or plugin update rather than being left to accumulate.

A good rule: if WP_DEBUG_DISPLAY is off and a visitor would never see the message, it is a cleanup item, not a launch blocker. If it changes what a real user sees or does, it blocks the update until resolved.

Step 5: Set a rollback plan before you touch production

Even after clean staging tests, keep a rollback plan ready for the production switch. At minimum:

1. Take a full backup of files and database immediately before changing PHP version on production. Confirm the backup completed and is restorable, not just that a job ran.
2. Note your current PHP version somewhere accessible, so you can revert with one click or one support ticket if something goes wrong.
3. Schedule the switch for a low traffic window so you have time to verify before real usage ramps up.
4. Have your object cache and page cache ready to purge. After a PHP version change, clear Redis or Memcached object cache and any LiteSpeed full page cache, since cached output generated under the old PHP version can occasionally behave oddly once the runtime underneath it changes.

wp cache flush
wp litespeed-purge all

Step 6: Go live and verify

Switch production to the new PHP version, then immediately repeat the same manual walkthrough you did on staging: homepage, key templates, forms, checkout, admin login, plugin settings pages. Check the debug log again for a few minutes of real traffic. If everything holds, disable WP_DEBUG_DISPLAY and WP_DEBUG_LOG on production (leave them off day to day; only turn debug logging on when actively investigating something) and monitor error rates for the next day or two.

wp config set WP_DEBUG false --raw
wp config set WP_DEBUG_LOG false --raw

Takeaway

PHP updates reward preparation. Update plugins and themes first, run a compatibility scan, test the real version on staging with debug logging on, and separate genuine breakage from harmless deprecation noise before you decide what needs fixing. Keep a verified backup and a known-good PHP version on hand as your rollback, so if something does slip through, reverting is a quick, calm decision instead of a scramble. Do this once per major PHP jump and you get the speed and security benefits of staying current without the downtime that makes teams avoid updating in the first place.