If WordPress is broken after a PHP update, preserve the error and identify what changed before switching versions again. A missing extension, a different server handler or incompatible application code can need different repairs. During the October 2026 PHP security incident, blindly reverting to an unpatched runtime can also reopen the vulnerability you were trying to close.
The goal is to restore the affected business function on a verified patched environment. A homepage that loads, a successful administrator login or a lower PHP version is not enough by itself.
First separate a PHP patch from a branch upgrade
Ask the host for the before and after versions, the change time, the domain assignment and any accompanying configuration changes. A move within PHP 8.4 is different from moving a legacy site from PHP 7.4 to PHP 8.4. Neither should be diagnosed solely from the phrase “PHP was updated.”
A branch migration can introduce language changes. The official PHP 8.4 migration guide, for example, documents backward-incompatible behaviour. That does not establish that PHP itself caused your particular failure. Match the error to the actual migration and the code that failed.
For the security background, see the PHP2Shell incident guide. To confirm the environment rather than troubleshoot an outage, use the separate WordPress hosting-patch checklist.
Record one failing request before more changes
Write down the exact page or action, the first known failure time and the message shown. Check whether the public site, wp-admin or only one feature fails. Do not keep retrying an order, payment, import or form submission: a failed screen does not tell you whether an earlier part of the operation completed.
- Everything fails: ask the host to check the web PHP service, handler, required extensions and configuration before disabling unrelated plugins.
- One template or feature fails: preserve the matching fatal-error line and identify which component owns that path.
- The homepage works but checkout fails: test the dynamic path in a controlled environment. Do not accept the cached homepage as recovery proof.
- The failure is intermittent: record each time and ask whether more than one worker, node or runtime assignment is involved.
These are investigation boundaries, not diagnoses. The host’s error log and the changed configuration should decide the next step.
Read the fatal error without exposing it publicly
Start with the provider’s private PHP or application error log around the recorded time. Ask for the error type, affected component and relevant context, with secrets removed. A path in a plugin does not automatically prove that plugin is the sole cause; it can be where a missing dependency or incompatible call first becomes visible.
A message about an unavailable extension calls for comparing the old and new runtime’s extension sets. A type or function error calls for checking the component’s supported PHP range and corrected release. A process-start or configuration failure belongs with the server operator. Treat a deprecation notice differently from a request-stopping fatal error.
The WordPress debugging handbook recommends staging or a suitable backup before modifications and distinguishes logging from displaying errors. Do not enable public debug output, paste raw logs into a forum or leave a diagnostic file reachable on the website. Prefer the existing protected host log over introducing another production debugging change.
Use Recovery Mode if WordPress provides it
Check the site administrator’s mailbox and spam folder for the WordPress recovery email. Confirm the link belongs to your own site before opening it, and do not forward the private recovery URL as a support request.
WordPress Recovery Mode can pause a failing plugin or theme for your administrator session, allowing you to inspect the problem. It does not establish that the public site is repaired. The email may also fail to arrive, particularly when the fatal error interferes with the normal mail path.
Inside Recovery Mode, note the named component and version. If a corrected vendor release exists, test it against the patched PHP environment. If pausing the component is necessary, first establish what it controls: disabling a booking or payment integration can stop the error while removing the business function.
Without dashboard access, ask the host or developer to isolate the identified component through a reversible file-level change. Do not rename the entire plugins directory or delete files simply because a generic guide suggests it.
Choose a recovery that keeps the security fix
Restore a missing dependency or correct the domain assignment
If the new handler lacks an extension or the domain is assigned to the wrong pool, the server operator should correct that specific difference. Ask for the exact change and verify the original request afterward. Reinstalling WordPress does not repair a server package assignment.
Update or repair incompatible application code
If the error points to a theme, plugin or custom integration, obtain its supported update or a scoped development repair. Test the affected function on staging with the intended PHP branch. Avoid editing vendor files live without an exact backup and a way to retain the fix through future updates.
Use another patched runtime only when compatibility and support are confirmed
A different supported branch may be a workable temporary route if the host confirms it contains both incident fixes and the application passes its checks. “Go back to the old version” is not a complete plan. Ask whether that old build is patched, supported and actually assigned to this domain.
If no patched compatible runtime is available, agree on isolation and a repair or migration plan. The WordPress incident notice points owners toward taking affected systems offline when immediate remediation is not feasible. Have the host enforce the boundary; a WordPress maintenance screen can still depend on the vulnerable interpreter.
Worked example: a booking page fails, but the homepage works
Imagine that a host moves a site to a patched newer PHP branch. Its cached homepage still loads. Opening the booking form produces a fatal error referring to a custom booking integration.
The useful next move is to reproduce that booking request on a restricted staging copy with the same runtime and relevant configuration. The developer compares the fatal error with the integration’s supported PHP range and fixes or updates that component. The host retains the security patch.
Before reopening bookings, the owner verifies the complete controlled path: availability selection, submission, the resulting record and the intended confirmation. If the integration was temporarily paused, they also check that the form is no longer silently absent. Only then is normal traffic resumed.
This is a hypothetical diagnostic example, not a reported client incident. It illustrates why changing the whole site back to an unpatched environment can be both less informative and less safe than repairing one failing dependency.
Do not restore the entire database just to undo PHP
A site backup and the hosting runtime are different recovery layers. Restoring WordPress files or its database does not necessarily change the PHP package or domain handler. A full database restore can also remove orders, bookings, enquiries or account changes received since the backup.
Before approving a restore, establish which layer is damaged and what new data must be preserved. Our WordPress backup restore testing guide explains why a recovery route should be checked before an outage. Keep a current protected copy even if an older file version is needed for diagnosis.
What counts as a completed PHP-update repair?
- The host confirms the intended patched runtime and relevant worker replacement.
- The original failing request succeeds outside the recovery session.
- Logged-out pages and wp-admin work, not only cached content.
- The affected form, booking, account or checkout journey passes an agreed controlled test.
- Fresh logs show no recurrence of the diagnosed fatal error during those checks.
- Temporary access, diagnostic files and emergency workarounds are removed or explicitly recorded with an owner and next action.
Use the checkout testing checklist when store payments are involved. Do not improvise repeated real charges. If you need help assigning the problem to the host or developer, the WordPress website repair responsibility guide separates those roles.
Webless’s WordPress development service covers scoped compatibility and integration work. Send the domain, change time, before/after runtime and a sanitised error summary first. Access should be arranged securely after the repair scope is understood.