How to find which plugin update broke your WordPress site

Your site worked yesterday. Today the checkout fails, or the layout is wrong, or you get the white screen. Something changed. The hard part is that WordPress does not give you a list of what.

This page shows how to find the change by hand, in order, with the steps that cost the least first. Then it shows a faster way for next time.

Step 1: Get into the dashboard, or skip it

If you can still open wp-admin, go on to step 2.

If you get "There has been a critical error on this website", check the inbox of the site's admin email address. WordPress usually sends a message with a recovery mode link and names the plugin or theme that caused the error. Open the link, log in, and you are in a safe mode where the broken item is paused.

If no email came, you can still stop a plugin from outside WordPress. Connect by FTP or your host's file manager, open wp-content/plugins/, and rename the folder of the plugin you suspect (add -off to the end). WordPress treats a plugin with a missing folder as inactive. Reload the site. If it comes back, you found it.

Step 2: Ask the question "what changed, and when?"

Work out when the site last worked. Even a rough guess helps: "Friday afternoon" or "after the 2am backup".

Now list what changed since then. WordPress gives you four partial sources:

• Dashboard > Updates shows what is waiting for an update now. It does not show what was updated.
• The Plugins screen shows each plugin's current version. It does not show the version before.
• Email from WordPress. If automatic updates are on, WordPress emails the admin address after it updates a plugin, theme or core. Search your inbox for the site name and the day it broke.
• Your host's panel. Many hosts keep a log of automatic updates, backups or file changes. Look for an activity or change log.

From these, write a short list on paper: the item, the old version if you know it, the new version, the day.

Step 3: Turn on the error log

If the site shows an error, the error often names the file. In wp-config.php, set:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the broken page, then open wp-content/debug.log. A line such as PHP Fatal error ... in /wp-content/plugins/some-plugin/... points at the plugin. Turn debugging off again when you are done. Do not leave it on a live site.

Step 4: Test one change at a time

If the list from step 2 has several items, turn them off one at a time. Start with the one closest to the time the site broke. Deactivate it from the Plugins screen, then check the broken page.

On a live store, do this on a staging copy if you have one. Deactivating a payment or shipping plugin on a live site can lose orders.

If your host offers WP-CLI, it is quicker:

wp plugin list --fields=name,status,version
wp plugin deactivate some-plugin

Step 5: Check the rest

Not every break is a plugin update. Also look at:

• A theme update or switch. Check Appearance > Themes and your child theme.
• A WordPress core update. The version is at the bottom of the dashboard, and under Dashboard > Updates.
• A change nobody made in WordPress. A developer who uploaded files over FTP, a deploy from git, or a host that changed the PHP version leaves no trace in wp-admin.
• A user. Someone with admin access may have turned a plugin off. WordPress does not record who.

Step 6: Fix it

Once you know the item, you have three choices: roll back to the old version, wait for a fix and keep it off, or contact the plugin's developer with the version numbers. The version numbers matter. "It broke when 5.1 became 5.2" gets a faster answer than "it broke".

Rolling back changes code on a live site, so take a backup first.

Why this takes so long

Every step above exists because WordPress does not keep a readable history of changes. You rebuild one from emails, memory and guesses, usually while the site is down.

The faster way: keep the history before you need it

What Changed? records the history as it happens. It is a free plugin from Noble Strategies.

When the site breaks, you open Tools > What Changed and the "What changed?" tab. Pick the last 24 hours, 7 days or 30 days. You see a short list of:

• every plugin, theme and WordPress core install, update, activation, deactivation, deletion and theme switch
• the from and to version on each update
• who did it: a named user, an automatic update, WP-CLI, or "changed outside WordPress"
• failed updates, in red, with the error message

Steps 2 and 5 become one screen. The details:

Outside changes. Once a day the plugin compares the versions on disk with its history. If a plugin's version changed through FTP, git or your host, it adds a row marked "changed outside WordPress". That covers the cases WordPress itself never sees.

Failed updates. If an update does not finish, the row shows the error. In our test, an update that could not remove the old plugin folder was recorded with the message "Could not remove the old plugin."

Crash marker. When WordPress reports a fatal error from a plugin or theme, the history shows it next to that item's latest change. This is a hint, not a guarantee. A crash that happens before the plugin loads may not be reported. Pro has an opt-in switch that catches those too.

Deleted plugins keep their name. The plugin stores the name and version at the time of the change, so a plugin you deleted last month is still readable.

What it does not do

It does not roll anything back. It does not show changes from before you installed it; it takes a snapshot when you activate it and records from then on. It will not catch every crash.

Free and Pro

The free version keeps your full history, with no limits on rows or time. Pro is for telling other people: email, Slack and webhook alerts when something changes or fails, a monthly white-label client report, CSV export, notes on rows, and changelogs between versions from wordpress.org. Pro costs $49 a year for 1 site, $99 for 5 sites or $199 for 20 sites, with a 14-day refund and 10% off every renewal.

A habit worth keeping

Install the plugin while the site works. It records from the day you activate, so the next break has a history to read.