WordPress errors after a PHP upgrade can make a simple maintenance change feel much bigger. The public page shows a critical error, the host reports that PHP started correctly, and somebody suggests disabling every plugin at once.
Pause before adding more changes. First establish what changed, which request fails and what the earliest relevant error says. A useful diagnosis narrows the problem. It does not create five new variables while the original evidence disappears.
This guide is for authorised troubleshooting of a site you manage. It follows the failure from the hosting runtime into application code, then explains how to recover without casually overwriting fresh orders or enquiries.
Establish the last known working state
Record the previous and current PHP versions, the time of the change and any plugin or configuration updates made with it. Confirm whether the failure affects production, staging or both.
Ask what still works. Can static assets load? Does the homepage fail only when the cache is bypassed? Can a customer complete an action while an administrator screen fails? Those distinctions help locate the next useful check.
Keep the initial symptom and the timeline in one incident note. If several people are working, name the person coordinating changes. Otherwise, a host reload, a plugin update and a database restore can happen independently and leave nobody sure which action changed the result.
Avoid treating every problem discovered that day as a new regression. Compare against the baseline tests or previous logs where available. An existing export failure needs a different explanation from a fatal error first seen after the runtime switch.
Check the runtime before editing the application
Confirm the PHP version that serves the website. Then inspect command-line PHP separately if scheduled jobs or WP-CLI form part of the workflow. A hosting selector may change one service without changing the other.
# Read-only checks for the command-line environment.
php -v
php --ini
php -m
# Application inventory, if WordPress can bootstrap successfully.
wp core version
wp plugin list --fields=name,status,version,updateThese commands describe the environment in which you run them. Compare their output with the web runtime recorded by Site Health or the hosting provider. Keep private paths and configuration details out of public support comments.
Ask the host whether the correct handler is active and whether its required extensions loaded. A missing extension or a wrong service mapping is not repaired by changing a WordPress function call.
Use the symptom to choose the next source of evidence
A visible status code is a starting clue. It does not identify the cause by itself. Use the hosting and application logs that correspond to the same request and timestamp.
| Symptom | First area to investigate | What to avoid assuming |
|---|---|---|
| Critical error or HTTP 500 | First relevant PHP fatal error and stack context | Every active plugin is defective |
| HTTP 502 or 503 | Web-server upstream and PHP worker availability | WordPress content needs restoring |
| One missing feature | Its extension, permissions and integration path | The whole PHP release is incompatible |
| Browser works, scheduled task fails | Job executable, configuration and environment | The web runtime proves CLI is correct |
| Warnings appear in output | Diagnostic settings and the affected call | Hiding the text fixes the underlying code |
| Cached pages work, uncached requests fail | Actual PHP execution behind the cache | The site is healthy because the homepage loads |
Use the table to form a hypothesis, then verify it. For example, a gateway error can follow a worker problem, but the web-server error log must establish which upstream failed before you change its settings.
Keep diagnostic output private
The WordPress debugging guide describes the debugging constants and their behaviour. Apply them deliberately, preferably on staging, and avoid exposing detailed errors to visitors.
Here is a staging-oriented example for an existing wp-config.php file:
// Staging diagnostics: replace existing definitions, do not duplicate them.
// Use a real private path outside the public document root.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/absolute/private/path/wp-php-upgrade.log');
define('WP_DEBUG_DISPLAY', false);The path is a placeholder. The process needs permission to write to the real location. The responsible administrator should control access and retention because logs can contain application data and private paths.
Check server-level logging too. If PHP fails before WordPress loads, a WordPress debug setting may never run. Ask the host for the relevant worker or web-server error rather than repeatedly refreshing the same critical-error page.
Remove temporary diagnostics or return them to the agreed maintenance policy after the investigation. A successful repair should not leave a growing public debug file behind.
Read the first relevant fatal error
Start with the error that corresponds to the failed request, not the final line in a large log. Later messages can be consequences of the earlier failure.
A missing function may point to an absent extension, an unavailable helper or a changed loading order. A class-loading error may involve a bundled dependency. A type or value error needs the actual argument and call context, not a guess based on the function’s name.
Compare the affected code with the relevant PHP migration guide. If the upgrade crossed several branches, inspect each relevant migration boundary. A change introduced before 8.5 can still be the first one an old application encounters.
Preserve a useful extract with the timestamp, file and call chain. Redact secrets and personal data before sharing it with a vendor. Give the vendor a reproduction and exact installed version rather than sending an entire production log by default.
Separate fatal failures from deprecations
PHP deprecations identify behaviour that needs maintenance. They are not automatically fatal errors. However, application error handlers and diagnostic settings can affect what users observe, so review the actual environment.
The PHP 8.5 deprecation notes explain examples such as older cast names and calls whose resource lifecycle changed. Use the specific note to plan a repair rather than suppressing every diagnostic globally.
If warning output corrupts a JSON response or document download, turning off public display can restore the expected response format while the underlying repair proceeds. Record both actions clearly. Concealing a message does not establish compatibility.
For custom code, repair the source and add a meaningful check for the affected behaviour. For a vendor package, obtain the supported update or an agreed patch that can survive future releases. Avoid undocumented edits in installed files that the next update will replace.
Isolate the component on a safe copy
Reproduce the failure on a recent staging copy with the same relevant runtime and dependencies. Protect customer data and prevent real payments or notifications before testing.
Change one relevant component at a time. If a suspected add-on is disabled, repeat the precise failing action and record the result. Then restore the dependency context needed to test the actual business workflow.
Disabling all plugins can sometimes help establish a broad boundary, but it can also remove the very conditions that trigger the problem. A form that disappears entirely cannot prove that its integration now works.
Include must-use plugins, snippets and drop-ins in the investigation. They may remain active when ordinary plugins are disabled. If the site uses Composer packages or generated code, check those sources rather than assuming the plugin screen shows the whole application.
Recover service without discarding live records
If the site cannot perform a critical function, use the pre-agreed recovery route. A runtime rollback to a previously verified, supported patched build may be sufficient when only PHP changed. Confirm the available options with the host.
Do not confuse that with restoring an old database. A store or lead-generation site may have received legitimate records since the backup. An external payment or CRM action may already exist even if WordPress is then restored to an earlier state.
Before a database restore, agree what data it would overwrite and how the team will preserve or reconcile it. If plugin updates changed the database schema, assess that separately from the PHP setting.
Also consider security when choosing the fallback. Reverting to an exposed runtime can reintroduce the reason for the upgrade. Ask the host for a supported patched recovery option or temporary containment while the compatibility repair proceeds.
Verify the repair through the original journey
Repeat the failing action with representative data and inspect the resulting record. A page that loads after the fix is only the first check. The form entry, approved test order, generated file or completed background job provides stronger evidence.
Test adjacent paths that share the repaired code. A type-handling change for one API response may also affect an empty response or an older stored record. Keep the tests focused on those behaviours rather than reproducing every line of the implementation.
Then confirm the active runtime and relevant logs again. Note what changed, why it fixed the problem and which versions now form the supported baseline. Assign follow-up work if the immediate recovery left a dependency replacement outstanding.
What to send when requesting help
Send the old and new PHP versions, WordPress and plugin versions, the action that fails and a redacted error extract. State whether the issue reproduces on staging and what recovery options the host has confirmed.
My WordPress security handover guide covers the baseline around inherited sites. You can request PHP upgrade troubleshooting with those non-sensitive details.
WordPress errors after a PHP upgrade are easier to resolve when each change answers a specific question. Establish the environment, follow the error, repair the responsible layer and prove that the original business task works again.
