Plesk Problems
Plesk PHP Version Change Broke Website
Last reviewed
Direct answer
Switching PHP versions in Plesk (Websites & Domains → PHP) broke the site because a plugin, theme, or custom code called a function that was removed or now behaves differently in the new version, or because the PHP handler type changed alongside the version. Revert to the previous version first to confirm that is the cause, then check the domain’s error log for the exact fatal, and update or replace the incompatible code rather than staying on an outdated PHP release indefinitely.
Plesk makes changing PHP version and handler a one-click action, but WordPress, plugins, and custom themes do not always follow PHP’s deprecation and removal timeline. This guide explains how the PHP version and handler settings interact, how to quickly roll back to restore the site, and how to diagnose the specific incompatibility so you can move forward on a supported PHP version instead of freezing on an outdated one.
Key facts
Verifiable numbers and definitions — each claim links to its source.
- Plesk PHP settings docs cover choosing the PHP version, handler, and per-site php.ini directives for a domain. (PHP Settings)
- PHP.net publishes which major PHP branches are actively supported versus end-of-life. (Supported Versions)
- Plesk WP Toolkit docs describe managing WordPress sites from the panel after hosting changes such as PHP version switches. (WP Toolkit)
What the error means
In Plesk, each domain’s PHP version and handler type (FPM application served by Apache/nginx, FastCGI, CGI, or mod_php-style embedded serving) are configured together under Websites & Domains → PHP, and can be set per-domain, per-subscription, or inherited from a hosting plan. Raising the PHP version changes which language features and removed functions are available; changing the handler changes how PHP processes are spawned and can affect timeouts, memory pooling, and environment variables. A fatal error immediately after either change usually means code somewhere in the stack — core, a plugin, a theme, or a custom script — calls a function, class, or syntax construct that no longer exists or behaves differently on the new version, or relies on a php.ini directive that reset when the handler switched to PHP-FPM.
Common symptoms
- White screen, “There has been a critical error on this website”, or a raw PHP fatal error immediately after the PHP version was changed
- Site loads but specific pages, plugins, or admin screens throw errors while others work fine
- Error log shows “Call to undefined function”, “Call to undefined method”, or a deprecated/removed feature notice tied to the new version
- wp-admin is reachable but the front end is broken, or the reverse
- A previously working custom PHP script or cron job now fails silently or logs a parse error
- Uploaded custom php.ini directives (memory_limit, upload_max_filesize) appear reset to defaults after switching to PHP-FPM
- Site works when the PHP version is reverted, confirming the version change as the trigger
Most likely causes
- 01 Plugin, theme, or custom code using a function or feature removed in the new PHP major version (common around PHP 7→8 and within 8.x releases)
- 02 Handler type changed at the same time as the version (for example FastCGI to PHP-FPM), resetting per-domain php.ini overrides
- 03 Outdated plugin or theme that has not been updated to declare compatibility with the newer PHP version
- 04 A required PHP extension (mysqli, gd, imagick, mbstring) not enabled for the new version even though it was enabled for the old one
- 05 OPcache or a cached autoloader referencing the old PHP binary path after the switch
- 06 Strict typing or deprecation notices now surfacing as visible errors because `display_errors` is on for the new version’s configuration
- 07 Composer-managed dependencies (in custom or headless builds) compiled against an incompatible PHP version
What changed before the problem started
- PHP version was changed for the domain, subscription, or hosting plan in Plesk → Websites & Domains → PHP
- PHP handler type switched (for example from FastCGI/CGI to PHP-FPM) alongside or instead of the version
- A hosting plan-level PHP setting was updated centrally, changing every subscription that inherits from it
- Plesk itself was updated and changed available PHP versions, deprecating an older one the site depended on
Troubleshooting steps
- 01
Revert to the previous PHP version to confirm the cause
In Websites & Domains → PHP, switch back to the version that was working before. If the site immediately recovers, you have confirmed the PHP change is the trigger and can now investigate on a copy or staging domain instead of live production.
- 02
Read the exact fatal error from the domain error log
Under Websites & Domains → Logs (or the domain’s error_log via File Manager), find the line matching the time of the outage. “Call to undefined function” or “Uncommand class” errors name the exact file and function causing the break — that is the plugin or theme to update, not a random guess.
- 03
Update the named plugin, theme, or core before re-attempting the PHP change
Once the log names the offending component, check its changelog or support page for PHP compatibility notes. Update it to the latest version, or temporarily deactivate it, before switching PHP versions again on the live domain.
- 04
Re-check PHP-FPM specific settings after a handler change
If the handler moved to PHP-FPM, re-apply any custom memory_limit, max_execution_time, or upload_max_filesize values under the PHP page’s “Additional configuration directives” — FPM pools do not automatically inherit values set for a different handler.
- 05
Confirm required PHP extensions are enabled for the new version
Each PHP version in Plesk has its own extension list under Tools & Settings → PHP Settings → (version) → Extensions. A plugin depending on `imagick`, `gd`, or `mbstring` will fatal if that extension is not checked for the version you switched to.
- 06
Test on a staging subdomain before repeating the change on the live site
If WP Toolkit or a staging copy is available, apply the target PHP version there first, work through every fatal, and only repeat the change on production once the staging copy loads clean end to end.
When to stop troubleshooting
Stop making further version or handler changes on the live domain once you have confirmed which PHP version broke the site — additional changes without reading the log first tend to compound confusion. Escalate if the failing component is WordPress core itself, a paid plugin/theme with no available update, or the fatal persists after updating everything named in the log; bring the exact error text, the old and new PHP versions, and the domain’s error log.
Information to collect before requesting help
- 01 PHP version before and after the change, and the handler type (FPM, FastCGI, CGI)
- 02 Exact fatal error text and file/line from the domain error log
- 03 Whether the change was made on the domain, subscription, or hosting-plan level
- 04 List of active plugins/theme (for WordPress sites) or key dependencies (for custom PHP apps)
- 05 Whether the site recovers when reverted to the previous PHP version
- 06 Whether staging or WP Toolkit cloning is available for safe testing
- 07 Any custom php.ini directives previously set for the domain
How a professional repairs the problem
A technician reproduces the fatal on a staging clone, reads the exact stack trace from the domain error log rather than guessing, and identifies whether the break is a removed PHP function, a missing extension, or a reset php.ini directive from a handler change. They update or patch the specific incompatible component, verify required extensions are enabled for the target version, and move production forward one supported PHP version at a time with a rollback plan at each step.
Frequently asked questions
Why did changing PHP version break the site instead of speeding it up? +
Should I just switch back to the old PHP version permanently? +
Does changing the PHP handler type matter as much as the version? +
Can WP Toolkit help avoid this next time? +
Why does one plugin break but the rest of the site works fine? +
Is this the same as a general 500 Internal Server Error? +
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.
Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.