WP Debug Toolkit 1.1.0 is LIVE. Get $300 discount on the lifetime deal now
Use Discount Code WPDTLTD

Crash Recovery is a feature in the WP Debug Toolkit (WPDT) standalone viewer that lets you disable and re-enable plugins and themes without access to wp-admin. When your site is down and the WordPress dashboard is unreachable, Crash Recovery gives you a way to isolate the problem.

When to use it

Use Crash Recovery when:

  • Your site shows a white screen of death
  • A fatal PHP error prevents wp-admin from loading
  • You cannot log into WordPress after a plugin or theme update
  • WordPress recovery mode did not resolve the issue or the recovery link expired

How it works

The viewer API reads the plugin and theme directories on the filesystem and lists everything it finds. To deactivate a plugin or theme, the API renames its directory — for example, wp-content/plugins/woocommerce becomes wp-content/plugins/woocommerce.disabled. This is the same mechanism WordPress uses internally when deactivating plugins, but done at the filesystem level without requiring WordPress to be running.

Re-enabling reverses the rename, restoring the original directory name.

Step-by-step incident workflow

1. Access the viewer

Visit your standalone viewer URL (e.g., https://example.com/wpdebugtoolkit/) and log in with your viewer password. The viewer works independently of WordPress, so it loads even when your site is down.

2. Open Crash Recovery

Navigate to the Crash Recovery panel. Press the P key or select Crash Recovery from the viewer navigation.

3. Review active plugins and themes

The panel lists all installed plugins and themes with their current status (enabled or disabled). Each entry shows the plugin/theme name and directory name.

4. Disable suspect plugins

If you suspect a specific plugin caused the crash, disable it. If you are unsure which plugin is responsible, disable all plugins and re-enable them one at a time.

To narrow down the culprit:

  1. Disable all plugins
  2. Check if the site loads
  3. Re-enable plugins one by one, checking the site after each
  4. When the site breaks again, the last plugin you enabled is the cause

5. Check the error log

Switch to the error log viewer to confirm which plugin or theme triggered the fatal error. The log entry shows the file path, line number, and error message — the file path identifies the responsible plugin or theme.

6. Fix the issue

Once you identify the problem:

  • Update the plugin or theme if a newer version is available
  • Contact the plugin developer with the error details
  • Replace the plugin with an alternative
  • Remove it entirely if it is no longer needed

7. Re-enable plugins

From the Crash Recovery panel, re-enable each plugin you disabled. Monitor the error log after each re-activation to confirm no new errors appear.

Limitations

Crash Recovery operates at the filesystem level only. It renames plugin and theme directories to deactivate them, but it does not modify the active_plugins option in the WordPress database. This means:

  • WordPress may still list a disabled plugin as “active” in its database. When the directory is renamed back, WordPress picks it up again. If you deactivate a plugin through Crash Recovery and then load wp-admin, WordPress detects the missing directory and deactivates the plugin in the database automatically.
  • Must-use plugins (wp-content/mu-plugins/) are not managed through Crash Recovery. MU-plugins load unconditionally and cannot be deactivated through directory renaming.
  • Drop-in files (db.php, object-cache.php, etc.) are not managed through Crash Recovery.
On this page
Try WP Debug Toolkit
The best error log viewer with amazing developer tools to help you troubleshoot your WordPress site securely and efficiently. Something something more.