A PHP upgrade can expose removed functions, stricter type handling, incompatible encoded plugins or missing extensions. A downgrade may restore service temporarily, but leaving unsupported PHP in production creates its own security and support risk.
Record the old and new runtime before changing it again. cPanel/Plesk can assign different PHP versions to web requests, CLI and individual domains.
Confirm the active runtime
Use the hosting panel or a temporary protected diagnostic to identify PHP version, handler and loaded configuration for the failing domain.
error_log( 'Diagnostic PHP: ' . PHP_VERSION . ' / ' . php_sapi_name() );Remove the diagnostic after use. Do not publish phpinfo() because it exposes paths, modules and environment data.
Check WP-CLI separately; it may invoke another binary.
Capture the first compatibility error
Match the failing request with PHP logs. Common messages include undefined functions, incompatible declarations, type errors and ionCube/extension loading failures.
Record the component path, line and call stack. Do not focus on deprecation notices when a later fatal actually stops the request.
Preserve logs before switching runtimes, because the old version may produce different evidence.
Check WordPress and extension requirements
Compare WordPress core, theme, plugins and custom code with the target PHP version. Use vendors’ current compatibility statements and changelogs.
Abandoned plugins may claim broad compatibility but contain code paths not exercised by automated scanners. Reproduce the actual site functions in staging.
Do not rely solely on a plugin compatibility badge.
Build a compatibility matrix
List current and target PHP beside WordPress core, the active theme, every business-critical plugin and site-owned code. Mark vendor support, latest tested release and the feature path verified.
Prioritise authentication, editor, scheduled tasks, email and integrations—not just page rendering. For closed-source plugins, confirm any required loader has a build for the target PHP version before the production window.
Verify required PHP extensions
Different PHP versions can have different module sets. Check cURL, mbstring, XML, ZIP, GD/Imagick, intl and database drivers needed by the site.
An extension may be installed for PHP 8.1 but not 8.3. Use cPanel/Plesk or package management supported by the server.
Do not install arbitrary binaries or disable TLS verification to work around a missing network module.
Inspect handler and configuration changes
The new PHP version may use another FPM pool, memory limit, upload limit, disable_functions, timezone or filesystem user.
Compare effective configuration rather than copying the old php.ini wholesale. Deprecated directives can prevent the new service from starting.
Check OPcache and socket paths; the web server may still point to the previous FPM socket.
Restore service safely
If production is down, temporarily select the last known working supported PHP version through the host while preparing a forward fix. Document the rollback and its deadline.
Do not restore the database to reverse a PHP runtime change; content is unrelated and could be lost.
If the previous runtime is end-of-life, limit exposure and prioritise compatibility work.
Repair the incompatible component
Update or replace the named plugin/theme, correct site-owned PHP and install required extensions. Use a child theme or maintained custom plugin rather than editing vendor files.
Test syntax and behaviour in staging on the target PHP. Remove suppressed errors that conceal invalid logic.
Clear OPcache after deploying corrected code.
Run a full acceptance pass
Test public templates, login, editor, media, email, cron, REST API and each business-critical integration. Inspect logs for new warnings that indicate future breakage.
Recurring care should inventory runtime requirements and test PHP upgrades before the host enforces them. A successful upgrade means the whole application path works on a supported runtime, not just the homepage.