PHP Version Upgrade Broke Site: 5 Fixes (2026)

Check Error Logs Before Making Changes

Most hosting panels put PHP errors in an "Error Log" section under your domain settings. If you have SSH access, check /var/log/php-fpm/domain.com-error.log or /var/log/apache2/error.log depending on your stack. Look for the newest entries after the upgrade timestamp.

Fatal errors tell you exactly what broke. You might see "Call to undefined function mysql_connect" or "require(): Failed opening required" with a file path. Deprecated warnings are less urgent but point to code that will break in the next major version. Write down the error messages verbatim before trying fixes.

If logs show nothing, your application might be suppressing errors. Add these lines at the top of your index.php temporarily:

• error_reporting(E_ALL);
• ini_set('display_errors', 1);
• ini_set('log_errors', 1);

Option 1: Roll Back to the Previous PHP Version

This is the nuclear option when you need the site functional immediately. Most control panels let you switch PHP versions in two clicks. In cPanel it's under Software → Select PHP Version or MultiPHP Manager. Plesk keeps it under Domains → PHP Settings. Shared hosts usually offer PHP 7.4, 8.0, 8.1, and 8.2 as dropdown choices.

Rolling back gets you online in under five minutes but kicks the real problem down the road. If the upgrade was forced because your old version reached end-of-life, you're now running outdated software with unpatched vulnerabilities. Acceptable as a temporary measure while you fix code in staging, dangerous if you leave it rolled back for months.

After rollback, your immediate task is setting up a staging copy of the site on the new PHP version. Fix issues there without time pressure, then switch production once staging runs clean for 24 hours. This is how you should have done the upgrade in the first place.

Option 2: Patch Deprecated Function Calls

If error logs show specific function names, you can patch just those calls and stay on the new PHP version. The mysql_* functions were removed in PHP 7.0, so old WordPress sites and custom scripts fail hard. The fix is replacing mysql_connect with mysqli_connect or switching to PDO entirely.

Each_() was deprecated in PHP 7.2 and removed in 8.0. If you see "each() has been removed" in logs, grep your codebase for each( and rewrite those loops with foreach or current()/next(). Split() was removed too; use explode() instead. These are usually ten-line fixes scattered across a few files.

This approach works when errors point to a handful of function calls. If you see fifty different deprecated warnings, the codebase needs broader refactoring and you're better off rolling back temporarily. Patch only what's blocking the site from loading, then schedule deeper fixes.

Option 3: Reinstall Missing PHP Extensions

PHP upgrades sometimes drop extensions that were compiled into the old version. Common casualties: php-mysql, php-gd, php-mbstring, php-curl, php-xml. Your application won't say "extension missing" directly; you'll get "Call to undefined function imagecreatetruecolor" or "Class 'DOMDocument' not found."

Check loaded extensions by creating a file called info.php with <?php phpinfo(); ?> and visiting it in a browser. Search the page for the extension name your error mentioned. If it's absent, you need to install it. On cPanel, use the PHP Extensions interface under Software. On a VPS, run apt install php8.2-extensionname or yum install php82-php-extensionname depending on your distro.

After installing extensions, restart your web server. Apache needs sudo systemctl restart apache2, nginx usually needs sudo systemctl restart php8.2-fpm. Shared hosting applies changes automatically but may take thirty seconds to propagate. Refresh your site and check if the error disappeared.

Option 4: Update Composer Dependencies

Frameworks like Laravel, Symfony, and WordPress plugins often have version constraints in composer.json. If you upgraded from PHP 7.4 to 8.1, some packages might not support 8.1 yet. You'll see errors like "Your requirements could not be resolved" or runtime class-not-found fatals.

SSH into your document root and run composer update. This pulls newer package versions that declare PHP 8.1 compatibility. If composer itself errors out, you may need to update composer first with composer self-update. For WordPress sites using Bedrock or similar, navigate to the web root and run composer update there.

Sometimes a single package blocks the entire update. Composer will tell you which one. Your choices: find an alternative package, wait for the maintainer to release a compatible version, or (last resort) edit composer.json to relax the PHP version constraint temporarily. The third option is risky because the package may use removed functions. Test thoroughly.

Option 5: Full Compatibility Rewrite

Legacy applications built before PHP 5.6 often need significant rewrites. If you're jumping from PHP 5.6 to 8.2, you're crossing multiple breaking-change boundaries: removal of mysql_*, stricter type handling, changed error reporting defaults, namespace requirements for some built-ins.

Read the official PHP migration guides for each major version between your old and new versions. PHP 7.0, 7.4, 8.0, and 8.1 each have migration appendices in the documentation listing every backward-incompatible change. Make a checklist and grep your codebase for each pattern.

This is a multi-day project. If the site is business-sensitive, roll back to the old version while you work. Clone the site to a local development environment running the target PHP version, fix errors one file at a time, and use version control to track changes. When local testing passes, deploy to staging, then production.

• Set up local environment matching the new PHP version exactly
• Enable strict error reporting to surface all deprecations
• Fix fatal errors first, then warnings, then notices
• Run your test suite after each batch of changes
• Update third-party libraries before rewriting custom code

Compare the Five Methods

Rollback is fastest but leaves you on unsupported PHP. Use it when downtime costs exceed the risk of running outdated software for a week or two. If your host auto-upgraded you without warning and you have no staging environment, rollback while you set one up.

Patching specific functions works when error logs point to two or three clear culprits. If you see a single mysql_connect call and nothing else, replace it with mysqli and you're done. This takes thirty minutes and keeps you on the secure PHP version.

Reinstalling extensions is straightforward if the error message names the missing module. I've seen this most often with gd, imagick, and sodium. Installation takes five minutes, but some hosts don't give you extension control, forcing you to open a support ticket.

Composer updates handle framework and dependency issues. Modern applications built on Laravel or Symfony usually just need composer update and they work on new PHP versions. Older projects without dependency management need manual library updates or rewrites.

Full rewrites are unavoidable for ancient codebases. If you're still on PHP 5.4 and the host is forcing 8.0, you're going to spend days fixing code. Budget for it or hire a developer.

Recommended Approach by Scenario

E-commerce site broke during business hours: Roll back immediately, then fix in staging after hours. Lost sales hurt more than security risk for a few days.

Blog or informational site with low traffic: Patch the specific errors if they're clear, or roll back if logs are confusing. Take time to test properly.

Enterprise application with staging environment: Never let this happen. But if it did, roll back production, fix in staging, deploy the fix within 24 hours.

Legacy custom application on shared hosting: Roll back and start planning a rewrite or migration to a maintained CMS. Band-aid patches will fail again on the next forced upgrade.

Prevent Future PHP Upgrade Breakage

Test every upgrade in staging first. Clone your production site to a subdomain or local environment, switch it to the target PHP version, and click through every feature. Run any automated tests you have. Let it sit for 24 hours under the new version before touching production.

Keep frameworks and CMS platforms updated. WordPress 6.x handles PHP 8.2 fine, but WordPress 4.x doesn't. Staying current with minor updates means you're never more than one major version behind when a forced PHP upgrade arrives.

Monitor your host's PHP version support schedule. Providers usually announce end-of-life dates for PHP versions six months in advance. If you see PHP 7.4 deprecation warnings in your hosting dashboard, start testing 8.0 immediately rather than waiting until the forced cutover.

Enable error logging without display_errors in production. Set log_errors=1 and error_log=/path/to/file.log in php.ini or .htaccess. Review logs weekly so you catch deprecation warnings before they become fatal errors in the next PHP version.

For mission-critical sites, pin PHP versions explicitly if your host allows. Some VPS and cloud hosts let you specify php8.1 in configuration rather than auto-upgrading to the newest available version. This gives you control over upgrade timing but requires you to monitor security bulletins manually.