Upgrading PHP for WordPress: What Breaks and How to Prepare

Upgrading PHP is one of the highest-leverage things you can do for a WordPress site — newer versions are measurably faster and dramatically more secure. But it's also one of the most reliable ways to trigger a white screen, a critical error, or a broken checkout if you do it blind. The good news: almost every breakage is predictable, testable, and fixable before any visitor sees a problem.

Why PHP Version Matters So Much for WordPress

WordPress is a PHP application. Every page load, every database query, every plugin hook — all of it runs through PHP. The version of PHP your server is running determines which language features are available, which old syntax is tolerated, and how fast the interpreter processes your code.

PHP versions follow a strict end-of-life schedule. Once a version reaches end-of-life, it receives no security patches. Running PHP 7.4 today, for example, means running software with known, publicly documented vulnerabilities and no fixes coming. The WordPress core team strongly recommends PHP 8.1 or higher, and hosting companies are progressively dropping support for older branches.

The jump from PHP 7.x to PHP 8.x is the one that causes the most breakage in the wild, because PHP 8.0 introduced several breaking changes — syntax and behavior that simply throws a fatal error where PHP 7 would have silently continued. PHP 8.1 and 8.2 added further deprecation notices that become errors in 8.3.

What Actually Breaks When You Upgrade PHP

Plugins with outdated code

This is the number-one cause of breakage. A plugin written for PHP 5 or 7 may use functions that were removed in PHP 8, or rely on behavior that changed. Common culprits include:

• Passing null to non-nullable parameters. PHP 8.1 made this a deprecation; PHP 8.3 makes it a fatal error. Many form plugins, WooCommerce extensions, and older SEO tools trigger this.
• Dynamic properties. PHP 8.2 deprecated creating class properties on the fly. PHP 8.3 turns those into fatal errors. Page builder extensions and custom field plugins are often affected.
• Removed functions. create_function(), each(), and ereg() were removed in PHP 8.0. Any plugin still calling them will throw a fatal error immediately.
• Type juggling changes. PHP 8 changed how strings and integers are compared, which can silently corrupt logic in older payment gateway code or membership plugins.

Themes — including child themes

Premium themes that haven't been updated in 12–18 months frequently contain deprecated PHP patterns. Child themes often inherit the problem. The theme's functions.php is parsed on every single page load, so a fatal error there produces a white screen immediately.

Custom code: functions.php snippets and mu-plugins

Code snippets added by developers years ago are the most overlooked risk. Nobody updates them because they're not in the plugins list. Check your wp-content/mu-plugins/ folder and any custom code appended to functions.php carefully.

Hosting-level PHP extensions

Some PHP extensions your plugins depend on — like a particular image library, a SOAP extension, or an old database driver — may not be enabled on the newer PHP version by default, or may have been removed. WooCommerce PDF invoice plugins, for example, sometimes require the GD or Imagick extension in a specific configuration.

Before You Touch Anything: The Preparation Steps

1. Back up completely

Take a full backup — files and database — before changing the PHP version. Your host's control panel usually has a one-click option. Verify the backup actually downloaded or exists in a remote location, not just on the same server. This is not optional.

2. Check PHP compatibility with a plugin scanner

Install the free PHP Compatibility Checker plugin (by WP Engine, available in the official repository) on your live site. Run it against your target PHP version — say, 8.2. It will scan every plugin and theme and flag deprecated or removed function calls, giving you a file-by-file report. Fix or replace flagged plugins before you change PHP versions.

3. Update everything you can first

Update WordPress core, every plugin, and your theme to the latest available version. Most reputable plugin authors have already patched PHP 8.x compatibility. Many breakages are simply a result of running an old plugin version that was fixed upstream months ago.

4. Test on a staging site — this is the real safety net

Clone your site to a staging environment, flip the PHP version there, and walk through every important page: homepage, product pages, checkout, contact forms, admin screens, and any custom post type views. Your host almost certainly lets you set the PHP version per environment in cPanel, Kinsta's staging tool, or similar. If you're not sure how to set up a proper staging workflow, the guide on how to set up a WordPress staging site covers it step by step.

5. Enable debug logging before the switch

On your staging site, enable WordPress debug logging so that deprecation notices and warnings are written to a log file rather than displayed on screen. Add these lines to wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

After switching PHP versions on staging, load each key page and then check wp-content/debug.log. You'll see exactly which plugins and which lines of code are unhappy. For a walkthrough on reading that log, see how to read the WordPress debug log.

Making the Switch on the Live Site

Once staging tests clean, switch production. Most hosts let you change PHP version in cPanel under Software → Select PHP Version, in Site Tools, or through a dashboard toggle. The change takes effect immediately — there's no deploy step needed.

Immediately after switching:

1. Load your homepage. If it renders, that's a good sign.
2. Log into wp-admin. If the dashboard loads normally, core is happy.
3. Click through key pages — shop, checkout, contact, any membership-gated content.
4. Submit a test order or test form to confirm transactional flows work end to end.
5. Check the debug log one more time for warnings you might have missed.

If something breaks, your host's PHP version selector lets you roll back to the previous version in seconds. The backup you took is insurance against anything more catastrophic.

What to Do When Things Break After the Switch

If you get a white screen of death or a critical error after upgrading PHP, the sequence is:

1. Roll back PHP immediately in your host's control panel to restore the site.
2. Read the debug log to identify the exact plugin, theme file, and line number causing the problem.
3. Update or replace the offending plugin. If it's abandoned (no update in 2+ years, no response in the support forum), find an actively maintained alternative.
4. Re-test on staging with the fix in place before trying the live upgrade again.

If the broken code is in a custom plugin or theme and you're not comfortable editing PHP, that's a case for a professional. A one-line type-hint fix or a deprecated function swap is usually a quick job, but only if you know what you're looking at.

How to Prevent This Pain in the Future

The sites that handle PHP upgrades painlessly are the ones that stay current continuously rather than jumping across multiple major versions at once. A few habits make a big difference:

• Keep plugins and themes updated monthly. Compatibility fixes ship constantly.
• Watch the PHP end-of-life calendar. Check php.net/supported-versions and plan upgrades at least three months before a version's active support ends.
• Run a compatibility scan quarterly, not just before an upgrade.
• Don't install plugins that haven't been tested with recent WordPress and PHP versions. The plugin repository shows this clearly on every listing page.

When to Call a Professional

If you've followed the steps above and the site still breaks after the PHP upgrade — or if the compatibility scanner is flagging your entire stack and you're not sure where to start — that's the right time to bring in someone who does this daily. Likewise, if your site handles e-commerce or memberships, the risk of a broken checkout affecting real revenue makes professional help genuinely worth it.

Mend's free Diagnosis will triage your situation, identify exactly what's blocking the upgrade, and give you a flat price before any work starts. If it's a straightforward compatibility fix, a Quick Fix handles it same day. If the whole stack needs upgrading alongside the PHP bump, the team will scope it accurately upfront — no surprises.

A PHP upgrade isn't something to fear or indefinitely defer. It's a maintenance task with predictable risks and well-understood fixes. Prepare carefully, test on staging, and the go-live is usually uneventful. Skip the preparation, and you're gambling with your live site.