TroubleLens – Conflict Detector

No. A troubleshooting session applies to requests that carry your session cookie. Every other request — every visitor, bot, cron run and other logged-in user — loads the site normally.

The session only affects you, so a mistake stays with you. If you switch off something your admin screens need, the recovery link on the troubleshooting screen ends the session before any plugin loads, so it works even when the site is returning a fatal error.

In order of how little needs to be working: use the recovery link shown on the troubleshooting screen; clear this site's cookies in your browser; wait for the session to expire; add define( 'TROUBLELENS_DISABLE', true ); to wp-config.php; or delete wp-content/mu-plugins/troublelens-conflict-detector-loader.php. Deactivating the plugin does the last two for you.

Yes, for plugins hosted on WordPress.org, and once TroubleLens has seen the plugin updated. The earlier version is downloaded when you press the button and loaded for your session only; visitors keep the installed version. It runs against your real database, so anything it writes is written for everyone. Take a backup first, especially for shop, membership and course plugins whose updates change their data.

Only if you switch on Watch after updates. Then, a minute after each update, it requests the pages you chose the way a visitor would, and shows a notice if one that passed before now fails. Everything else happens when you press a button.

No. The session is tied to your user account, and a request that is not you ends it. This is deliberate: it is what stops a leaked cookie applying to anybody else.

Must-use plugins load before any code that could filter them, including this one. The same is true of drop-ins like object-cache.php. The overview screen lists them so you know what is outside the test.

Because they declare that they require it. WordPress deactivates dependents when a dependency goes, and a session does the same, or those plugins would be running against something that is not there — producing an error that looks exactly like the conflict you are hunting. The screen tells you which ones went and why.

You can deactivate a plugin you have not hidden. What is blocked is a plugin deactivating itself, which many do when a dependency is missing. Without that block, hiding WooCommerce for your own session would make its extensions switch themselves off for every visitor.

On multisite, only network administrators can start a session, and only the current site's own active plugins can be switched off. Network-activated plugins are listed and flagged but cannot be toggled.

From the WordPress debug log, when WP_DEBUG_LOG is enabled, and from the extensions WordPress itself paused after catching a fatal error. The plugin will not enable debugging for you, because that means editing wp-config.php. The diagnostics screen lists exactly what this approach cannot see.

The screens, the diagnostics, the findings and the report are all open to a plugin that wants to add to them, through documented filters and actions with tests that prove each one fires. Whatever an add-on contributes to a report is redacted along with everything else, and a finding it adds carries the observations behind it like any other. See docs/EXTENDING.md in the plugin folder.

The icons and the two illustrations in this plugin were generated with AI rather than taken from an icon set, so nothing here carries a third party licence. They are distributed under the same GPLv2 or later as the rest of the plugin.