Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

Restoring a site after a failed update

White screen, critical error, inaccessible admin area after an update: the method to get back to a working state without losing orders placed in the meantime.

Describe my issue Send a message

What I check first

A failed update doesn’t always show up the same way, and the symptom points directly to the diagnosis. Before restoring anything, I work out exactly what’s broken: the entire site, only the admin area, or just one specific feature such as the WooCommerce checkout. Restoring a full backup blindly, without this diagnosis, often means fixing a minor problem at the cost of avoidable data loss.

The exact cause is almost always one of three things: maintenance mode stuck on after an interruption, a plugin or theme incompatible with the new version, or a PHP fatal error in code that was never tested against this configuration. Telling these three cases apart before acting avoids restoring a full backup when a simple plugin deactivation would have been enough.

What you see after an update that went wrong

  • White Screen of Death: no page renders, neither on the front end nor in the admin area
  • "There has been a critical error on this website" message, with or without visible technical detail
  • Admin area inaccessible while the public site seems to work normally
  • Public site erroring out while the admin area stays accessible, often a sign of an issue specific to the active theme
  • Site stuck in maintenance mode after an interrupted update, showing the usual "briefly unavailable for scheduled maintenance" message

How I restore a site after a failed update

  1. Reading the debug.log

    I enable or check the debug log to pinpoint the exact cause: maintenance mode stuck on (the .maintenance file not removed), an incompatible plugin, or a specific PHP fatal error with the file name involved.

  2. Isolating via FTP rename

    If the log points to a specific plugin or theme, I disable it by renaming its folder over FTP, bypassing the admin area if it’s inaccessible. WordPress treats a renamed folder as a missing plugin and disables it automatically.

  3. Checking after isolation

    If the site works again after this targeted deactivation, the cause is confirmed. I can then look for a compatible version of the plugin or an alternative, without having touched the database.

  4. Full restore if the cause stays unclear

    If the log doesn’t allow the cause to be isolated quickly, or if several elements seem responsible at once, I restore the database and files backup taken before the update rather than keep searching blindly.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

Can stuck maintenance mode really break everything?
Yes. If an update gets interrupted (network drop, execution timeout), the .maintenance file WordPress creates temporarily can stay in place and lock the whole site behind the "under maintenance" message. The fix is often as simple as deleting that file over FTP.
How do you know if it’s the theme or a plugin at fault?
The debug.log usually names the exact file behind the fatal error, which directly identifies the plugin or theme responsible. Without a clear lead, I disable plugins one by one via FTP rename until the site works again.
Can you avoid losing orders when doing a full restore?
Yes, by extracting the orders placed between the backup and the incident before running the restore, then re-injecting them into the restored database. It’s a manual step that has to happen before, never after.
How long does restoring a site after an incident take?
A targeted plugin deactivation is sorted in a few minutes. A full restore with prior order extraction takes longer, usually from one to several hours depending on database size.

Related pages