Tracedown Culprit Finder

Yes, as long as you can still reach wp-admin. Start a session, choose “Find it for me”, and Tracedown probes your front page with different subsets of plugins loaded until it has the smallest set that still reproduces the error. A PHP fatal error, a 500, a white screen and a blank page all count as broken. If the error is also on the admin side and you cannot log in, see the next question.

Tracedown needs wp-admin to run. If WordPress cannot start at all, rename the plugins folder over SFTP or your host’s file manager to get back in, then let Tracedown name the culprit so you only have to remove one plugin instead of guessing.

Run a session. Tracedown tests the plugins that are active right now and returns the minimal set that reproduces the fault, so a plugin that only breaks in combination with another one is still caught. The report lists the plugin name, file and version so you can roll it back or report the bug.

Three ways. It is faster: a deterministic halving search needs a handful of probes instead of one per plugin. It is safer: nothing is ever written to the active plugin list, so there is no “I deactivated everything and now I cannot remember what was on” moment. And it is correct for pairs: two plugins that only break together are found, where a one-at-a-time check reports every single plugin as fine.

Same family of idea, different architecture. Both use a must-use plugin to filter the plugin list for one administrator. Tracedown additionally never writes the active_plugins option on any code path, so there is no restore step that can fail and leave plugins deactivated. It also runs the search for you and names a minimal set instead of leaving the toggling to you.

No. The filter only applies to requests carrying your signed session cookie. Tracedown also marks its own responses as uncacheable so a page cache or CDN cannot store a safe-mode response and serve it to someone else. There is a button in the session bar that opens a logged-out preview so you can see this for yourself.

The session ends by itself. Expiry is evaluated every time the safe-mode file loads, so it needs no cron job, no scheduled task, no traffic and no action from you. Nothing was written to the database, so when the session ends the site is exactly as it was.

If WordPress cannot start at all, no plugin can help you, including this one. Add define( 'TRACEDOWN_DISABLE', true ); to wp-config.php or delete wp-content/mu-plugins/tracedown-safe-mode.php , and you are back to the state you were in before Tracedown was involved.

No. It changes what WordPress loads for one request, for one person. The stored list of active plugins is never modified, which is also why Tracedown complies with the WordPress.org rule that a plugin may not change the activation status of other plugins.

Yes, and safe mode never applies to WP-CLI. wp tracedown status , wp tracedown abort , wp tracedown restore and wp tracedown nuke are registered from the safe-mode file so they keep working even while the plugin itself is filtered out of the active list.

Refused in this version, with a message explaining why. Network, site and subsite activation are three separate states and a partial implementation would be worse than none.