Broke After An Update

One update ran, and now the site’s broken, and you didn’t touch anything else.

It’s almost always a single plugin. Here’s the test that finds it, even when you can’t reach wp-admin.

It worked yesterday. Something updated. Now it doesn’t. Below: the test, the workaround for when you’re locked out, and the exact point to stop before you make it worse.

Find the guilty plugin

Text 562-726-2287

The test costs nothing. If it doesn’t bring the site back, we quote a fixed price before any work starts.

5 min

To run the test

$0

If deactivating fixes it

~4 hrs

To a written diagnosis if it doesn’t

The short answer

When a site breaks immediately after an update, it’s almost always one of three things: a plugin conflicting with another plugin, a theme that hasn’t caught up with a core update, or your host quietly moving you to a newer version of PHP.

The one thing worth trying yourself: deactivate the plugin that updated last. In WordPress, go to Plugins, sort by the date column if your list shows one, and switch off the most recently updated plugin. If the site comes back, you’ve found it. Leave it off until the developer ships a fix.

Can’t reach wp-admin at all? Most hosts give you a file manager. Renaming the plugin’s folder inside wp-content/plugins deactivates it. Same fix, from outside the building.

If deactivating doesn’t restore the site, stop there. Rolling back badly is the thing that turns a two-hour recovery into a two-day one, because now the original fault and a half-finished repair are tangled together.

Text 562-726-2287 or describe what happened and you’ll have a written diagnosis and a fixed quote in about 4 business hours. Free.

Is this you?

Check you’re on the right page.

If nothing loads at all and no update ran, the site is down is the page you want instead.

It was working yesterday, an update ran, and now it isn’t, and you didn’t touch a thing
You’re staring at a blank white page with no error on it at all
The site loads, but a section is broken, missing or unstyled
wp-admin works and the front end doesn’t, or the other way round
An automatic update you never asked for ran on its own
You’re not deep in WordPress, and every answer you’ve found may as well be another language

What’s actually causing it

Four causes, in the order they usually turn out to be.

01 Most common

A plugin conflict

Two plugins that both worked yesterday now disagree, because one of them changed. This is the most common cause by a wide margin, and it’s why deactivation is the first test.

A theme that hasn’t kept up

WordPress core updated, your theme didn’t, and something it relied on got removed or renamed. More common with older themes, and with anything a previous developer customised heavily.

A PHP version change

Your host moved you from one PHP version to the next, usually with a notice you’d never have spotted. Older code stops running. Nothing on your site changed, which is exactly why this one is so confusing: you didn’t update anything and it broke anyway.

An update that half-finished

The connection dropped or the server timed out, so some files are new and some are old. Shows up as strange, inconsistent behaviour rather than a clean failure.

What you can try yourself

The plugin test, in order.

Step 2 finds the plugin even when you can’t reach wp-admin. Most how-tos skip it, so here it is.

Deactivate the most recently updated plugin

If the site returns, that’s your answer. Leave it off and tell the plugin’s developer what happened.

Can’t reach wp-admin? Rename the folder

Use your host’s file manager to rename that plugin’s folder inside wp-content/plugins. WordPress treats a renamed folder as an absent plugin and deactivates it. Rename it back once you’re in.

Copy the host’s error log somewhere safe

Most control panels have one. The last few lines usually name the exact file that failed. Even if it means nothing to you, it’ll mean something to whoever helps next, and logs rotate.

When to stop

Stop here

If deactivating the plugin doesn’t bring the site back, stop.

Past that point the moves are restoring from a backup, editing files over FTP, or rolling back a core version, and each one makes recovery harder if it happens in the wrong order. The specific risk is a stale backup: restoring one that predates recent content silently deletes work nobody notices for a week.

Also stop if you’re running a store or taking form submissions. Restoring a backup on a live store loses every order placed since that backup was taken.

What we do about it

We reverse the right thing, not everything.