PHP Version Upgrades: What Breaks and How to Prepare

If a PHP upgrade breaks a WordPress site, the usual cause is not PHP itself but code that was already out of date: a theme, plugin, or custom snippet using functions the newer version no longer tolerates. The safest way to prepare is to test on a staging copy, update everything first, and keep a rollback plan ready before you switch versions.

This matters because many hosts now move sites onto newer PHP versions automatically or strongly encourage the change. That is usually a good thing for security and speed, but it can expose old code that has been quietly working for years. If you want the shortest path to a safe upgrade, start with a full backup, check your error logs, and review anything custom before you click the version change.

What a PHP version upgrade changes

PHP is the language WordPress runs on. When your host upgrades PHP, it changes how the server executes WordPress core, your theme, your plugins, and any custom code in your site. WordPress itself is generally built to work with current supported PHP versions, but older extensions and hand-written code may not be.

The key point is that the upgrade does not “break WordPress” in one single way. It usually breaks a specific piece of code, and the site only looks unstable because that code is central to the page being loaded.

Common symptoms include:

• A white screen or a critical error after switching PHP versions
• The admin area loading, but parts of the site failing
• Forms, sliders, builders, or checkout steps stopping unexpectedly
• Warnings or deprecation messages in logs, even if the front end still works
• Slow requests or repeated fatal errors from one plugin or theme file

If your site is already showing a generic crash message, that overlaps with broader WordPress failure modes. These guides may help too: There Has Been a Critical Error on This Website: What It Means and How to Fix It and How to Fix the WordPress White Screen of Death.

What usually breaks after a PHP upgrade

Here are the issues I see most often when a site moves to a newer PHP version.

1. Old plugins using deprecated or removed code

Plugins are the most common failure point. A plugin may still be installed and active, but its code was written for an older PHP version. Newer PHP releases are stricter about bad syntax, outdated functions, and unsafe assumptions about data types.

That can show up as fatal errors, missing features, or warnings that only appear under load. Sometimes the plugin works on one page and fails on another because only certain functions are called.

2. Theme templates or custom snippets

Custom themes and child themes often contain older PHP patterns, especially if someone edited files directly years ago. A change that looks harmless, like a conditional, array access, or string operation, can fail under stricter PHP rules.

Custom code in functions.php, a site-specific plugin, or snippets added through a builder or code manager can also be the source. If your site has been customized heavily, treat the upgrade as a code review event, not just a hosting setting change.

3. Plugins that depend on server extensions

Some plugins need PHP extensions such as image libraries, internationalization support, or database drivers. If your host changes the PHP version and the matching extensions are not enabled, the plugin may partially fail even though WordPress itself loads.

4. Cached errors that make the site look broken longer than it is

Sometimes the code issue is fixed quickly, but page caching, object caching, CDN caching, or browser caching keeps serving a broken version. That is why a careful test should include clearing caches after the change.

How to prepare before upgrading PHP

Use this order. It is the safest path for most WordPress sites.

1. Back up the site completely. Save both files and the database. If the upgrade fails, you need a restore point, not guesses.
2. Check what PHP version you are on now. Note the current version and the version your host recommends or requires.
3. Update WordPress core, plugins, and themes first. Old software is more likely to fail on a newer PHP version.
4. Review custom code. Look for child theme files, custom plugins, mu-plugins, snippets, and anything added directly to theme files.
5. Test on staging if possible. Clone the site and change PHP there first. This is the best way to see what breaks before visitors do.
6. Check logs before and after. PHP error logs and server logs often show the exact file causing trouble.
7. Have a rollback plan. Know how to switch back to the previous PHP version quickly if the site fails.

If you need help with the update process itself, this guide pairs well with a broader safe-update workflow: Safe WordPress Updates Without Breaking Your Site. If your site already broke during a maintenance change, see WordPress Site Broke After an Update? Here's What Happened and How to Fix It.

How to test PHP safely

Testing is where most site owners save themselves a lot of trouble. If your host offers staging, use it. If not, at least test during a low-traffic window and keep your backup ready.

On the test copy, do this:

• Switch PHP only on staging first.
• Load the homepage, a few key pages, and the admin dashboard.
• Test forms, login, search, checkout, and any custom post types.
• Click through pages that rely on your main theme templates.
• Check any custom blocks, widgets, or shortcodes.
• Look at error logs immediately after each test.

If something fails, do not guess. Disable plugins one by one, switch to a default theme on staging if needed, and retest. The goal is to identify the exact dependency before you touch the live site.

How to find the broken piece quickly

If the live site breaks after a PHP change, the fastest path is usually elimination. Start with the most likely cause and work outward.

1. Switch back to the previous PHP version if the site is down and you need immediate recovery.
2. Read the error log. Look for file paths that point to a specific plugin or theme.
3. Deactivate recently changed plugins. Start with anything updated close to the PHP change.
4. Temporarily switch to a default theme if the issue appears theme-related.
5. Disable custom snippets if the logs point to your child theme or custom plugin files.

Do not keep a broken site on an unsupported PHP version just because rolling back “fixes” it. That only postpones the problem. The real fix is to identify what needs updating or replacing, then move forward cleanly.

What safe code looks like

You do not need to be a developer to spot risky patterns. In general, sites are safer when code is maintained by the plugin or theme author, kept current, and free of custom edits in core files.

Higher-risk signs include:

• Plugins that have not been updated in a long time
• Theme files edited directly instead of via a child theme or custom plugin
• Snippets copied from old tutorials without checking PHP compatibility
• Commercial plugins with no clear support history
• Custom code added years ago and never reviewed again

If your site depends on theme-file edits, this older habit is worth fixing now: Never Edit WordPress Theme Files Directly. It makes PHP upgrades much harder to manage later.

How to prevent future breakage

The best prevention is boring, repeatable maintenance.

• Keep WordPress, plugins, and themes updated on a schedule
• Remove unused plugins and themes instead of leaving them installed
• Prefer well-maintained plugins with clear compatibility notes
• Use a child theme or custom plugin for site-specific code
• Test major changes on staging before live rollout
• Keep backups that you have actually tested restoring
• Review PHP error logs after updates, not only when something fails

If you run WooCommerce, membership, booking, or other business-critical functionality, be extra careful. A PHP upgrade can affect checkout, login, or payment flows even when the homepage looks fine.

When to call a professional

Call a professional if the site is already down, if the error log points to multiple files, or if you are not sure which plugin or theme is responsible. It is also worth getting help if the site is revenue-critical and you cannot risk extended downtime while experimenting.

If you want a fast diagnosis without guessing, Mend can inspect the failure, test safely on a backup-first workflow, and give you a flat price before any work starts. You can begin with a free diagnosis at /start/diagnosis, or go straight to /start/emergency if the site is urgent. Every paid fix includes a plain-English report of what broke and exactly what changed.

For owners who would rather not manage this maintenance cycle themselves, Mend also offers a Care Plan for updates, backups, security, and uptime monitoring. If you need secure access without sharing passwords, use /connect.

Bottom line

A PHP version upgrade is usually safe when the site is current, tested, and backed up. The sites that break are usually the ones with old plugins, custom code, or theme edits that have not been reviewed in years. Prepare first, test on staging, and use the logs to find the exact dependency before making changes on the live site.

If you are stuck or the site is already broken, do not keep poking at random settings. Get the diagnosis, fix the real cause, and move the site onto a supported PHP version with confidence.