PHP Errors

Website Broke After Changing PHP Version

Intermediate Risk: medium

Last reviewed July 17, 2026

Hosting access often needed Database access usually not needed

Direct answer

The new PHP version rejected code in a plugin, theme, or custom snippet. Switch back to the last working PHP version to restore the site, then update or replace the incompatible code on staging before raising PHP on production again.

Changing PHP in cPanel, Plesk, or a host selector is one of the fastest ways to turn a healthy WordPress site into a critical error, white screen, or HTTP 500. WordPress core may be fine on the new version while an old plugin still uses removed syntax. This guide covers emergency rollback, reading the fatal that names the culprit, and upgrading the stack without stacking blind changes.

Intermediate

What the error means

Each PHP release removes obsolete language features and tightens engine behavior. A hosting-panel PHP change applies immediately to that domain’s handler—there is no gradual rollout unless you tested on staging first. WordPress core may officially support the new version while a third-party plugin still calls removed functions, relies on dynamic properties that now fatal, or ships ionCube-encoded files that need a matching loader. End-of-life PHP versions also stop receiving security patches from php.net, so staying forever on an old “working” version is only a temporary recovery tactic, not a strategy.

Common symptoms

Site broke immediately after selecting a new PHP version in the hosting panel
Critical error message, white screen, or HTTP 500 on the front end and/or wp-admin
Error log shows parse errors, undefined function, type errors, or deprecation fatals timed to the switch
Rolling PHP back one version restores the site within minutes
Only certain plugins fail (page builder, backup, security, licensing) while a default theme works
Encoded or “nulled” plugins throw loader errors on the new PHP handler
Site Health previously warned that PHP was outdated, then the upgrade took the site offline

Most likely causes

01 Plugin or theme not compatible with the new PHP major or minor version
02 Custom code in functions.php, a code-snippet plugin, or an mu-plugin using removed syntax
03 ionCube or other encoded plugins missing a loader that matches the new PHP
04 Required PHP extensions (mysqli, curl, mbstring, gd/imagick, zip, intl) missing on the new handler
05 WordPress core or must-use plugins far behind the host’s target PHP
06 MultiPHP INI values reset so memory_limit or max_execution_time dropped after the switch
07 Plugin updates performed in the same window as the PHP change, obscuring the real trigger

What changed before the problem started

Manual PHP selector change (for example 7.4 → 8.1 or 8.1 → 8.3)
Host-enforced upgrade after an old PHP branch reached end-of-life
MultiPHP INI or PHP-FPM handler change alongside the version bump
Batch plugin updates performed in the same maintenance window
Theme or child-theme edit that only fatals under the newer engine
Staging never tested on the target PHP before production was flipped

Troubleshooting steps

01
Roll back to the last known-good PHP version
In the hosting panel, switch the domain back to the PHP version that worked before the change. Wait a minute, purge page/CDN caches, and confirm the front end and wp-admin load. Restoring service comes before modernization.
02
Capture the fatal while briefly on the broken version
Keep any screenshot or log from the failed attempt. If needed, during a short maintenance window switch to the new PHP once, trigger a single request, copy the fatal file path from the error log, then roll back immediately. That path names the plugin, theme, or snippet to fix.
03
Update or replace the incompatible code on the working PHP
While the site is healthy on the older PHP, update the offending plugin or theme to a release that supports your target PHP. Remove abandoned plugins with no PHP 8-compatible release rather than patching vendor files on production.
04
Test the PHP upgrade on staging first
Clone the site, switch staging to the target PHP, and crawl home, login, checkout, forms, and the page builder. Review WP_DEBUG_LOG with display disabled. Only change production PHP after staging stays clean.
05
Raise production PHP during a low-traffic window
With a fresh backup ready and incompatible code updated, select the new PHP version once. Retest immediately. If anything fatals, roll PHP back first—do not start renaming random plugins while customers are mid-checkout.
06
Re-check MultiPHP INI limits after the move
Confirm memory_limit, max_execution_time, and upload limits match what the site needed before. Handler switches often reset INI values and trade one fatal for silent upload or timeout failures.

Roll back to the last known-good PHP version

In the hosting panel, switch the domain back to the PHP version that worked before the change. Wait a minute, purge page/CDN caches, and confirm the front end and wp-admin load. Restoring service comes before modernization.

Capture the fatal while briefly on the broken version

Keep any screenshot or log from the failed attempt. If needed, during a short maintenance window switch to the new PHP once, trigger a single request, copy the fatal file path from the error log, then roll back immediately. That path names the plugin, theme, or snippet to fix.

Update or replace the incompatible code on the working PHP

While the site is healthy on the older PHP, update the offending plugin or theme to a release that supports your target PHP. Remove abandoned plugins with no PHP 8-compatible release rather than patching vendor files on production.

Test the PHP upgrade on staging first

Clone the site, switch staging to the target PHP, and crawl home, login, checkout, forms, and the page builder. Review WP_DEBUG_LOG with display disabled. Only change production PHP after staging stays clean.

Raise production PHP during a low-traffic window

With a fresh backup ready and incompatible code updated, select the new PHP version once. Retest immediately. If anything fatals, roll PHP back first—do not start renaming random plugins while customers are mid-checkout.

Re-check MultiPHP INI limits after the move

Confirm memory_limit, max_execution_time, and upload limits match what the site needed before. Handler switches often reset INI values and trade one fatal for silent upload or timeout failures.

When to stop troubleshooting

Escalate if the host only offers a PHP version your plugins cannot run, you cannot identify the fatal file, encoded plugins block progress without vendor support, or production cannot tolerate another toggle. Bring logs from both PHP versions and a backup taken before any further changes.

Information to collect before requesting help

01 Previous and new PHP versions (exact selector values)
02 Exact on-screen message and whether front end, wp-admin, or both failed
03 Fatal lines from error_log or debug.log including file paths
04 Whether rolling back PHP restores the site
05 WordPress version and list of outdated or abandoned plugins/themes
06 Hosting panel type (cPanel, Plesk, managed) and provider name
07 Backup timestamp from before the PHP change

How a professional repairs the problem

We restore the last working PHP version to stop downtime, identify incompatible plugins or custom code from the fatals, update or replace them on a staging copy with matching extensions and INI settings, then move production forward on a supported PHP release. The goal is a patched runtime without surprise white screens.

Frequently asked questions

Is it safe to stay on PHP 7.4 forever if it “works”? +

No. End-of-life PHP branches stop receiving security patches from the PHP project. Use the older version only as a temporary rollback while you update plugins and retest on a currently supported release (WordPress recommends modern 8.x versions).

Why did Site Health say PHP was outdated if upgrading broke the site? +

Site Health pushes you toward supported PHP, but it cannot guarantee every third-party plugin is ready. Treat the recommendation as a project: update plugins on staging, then change PHP.

Can a theme alone break after a PHP change? +

Yes. Poorly maintained themes and child-theme functions.php snippets are frequent culprits. Switching to a default theme is a valid isolation test after rollback or during a maintenance window.

Does changing PHP delete my content? +

No. PHP version changes do not wipe the database. They only change how PHP executes your code. Backups are still required in case you edit files while troubleshooting.

Should I change PHP and update all plugins in the same minute? +

Avoid stacking changes. Update plugins on the current PHP first, verify stability, then change PHP. If something breaks, you will know which step caused it.

How is this different from a random 500 with no PHP change? +

A PHP selector change is a hard timeline clue: the same fatal patterns show up, but you have an immediate rollback lever. Use that lever first, then apply the usual plugin/theme isolation once the site is up on the last good version.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.