TroubleLens – Conflict Detector

The usual way to find a plugin conflict is to deactivate plugins one at a time and see what changes. On a live site that means taking features away from real visitors and customers while you experiment.

TroubleLens does the same investigation without that cost. It gives you a private troubleshooting session: plugins you switch off stop loading for your requests only. Everyone else — visitors, customers, other administrators, search engines, scheduled tasks — continues to get the site exactly as it is.

The list of active plugins in your database is never changed.

How it works

Starting a session writes one small must-use plugin and sets a cookie in your browser. On requests carrying that cookie, WordPress is told a different list of active plugins. That is the only supported way to do this: the plugin list is read before any normal plugin has loaded, so the code doing the filtering has to already be running.

What it does

• Troubleshooting mode. Switch any active plugin off for yourself. Nothing is deactivated.

• Theme test. Render your own session with a bundled default theme while visitors keep the live one.

• Guided isolation. Answer “is the problem still there?” a handful of times. It first checks with every plugin switched off, so a problem that is not a plugin at all is traced to your theme or placed outside both rather than pinned on an innocent plugin. Otherwise it narrows twenty candidates down to one by halves, then confirms it by switching that one off and on again.

• Conflict pairs. A conflict usually takes two. Once a plugin is confirmed, the guide keeps it running and finds what else the problem needs: a second plugin, your theme, or nothing at all. The pair is confirmed off and on in the same way, and both appear in the report.

• Diagnostics. REST API, WP-Cron and read-only database checks, plus errors read from the WordPress debug log and grouped by the component they were recorded in.

• WooCommerce checks. Version, required pages, HTTPS, template overrides that have fallen behind, and the scheduled action queue. Only appears when WooCommerce is running.

• Support report. Everything gathered, in text or JSON, with credentials and personal data stripped out.

• Automatic isolation. Describe how to tell the problem apart once and the whole search runs itself, partner search included, fetching the page through your session after each round and keeping what it saw with every answer.

• Isolation in your browser. For problems only a running page shows, such as a JavaScript error, a button that never appears or a request that fails, your own browser loads the page in a hidden frame after each round and answers for you.

• Where they meet. For a confirmed pair, the hooks both use, callbacks one removes from the other, names both register and libraries both load: the places a developer would start looking.

• Test an earlier version. Run the version a plugin had before its last update, for your session only, while visitors keep the installed one.

• Watch after updates. Off until you switch it on. After every update it re-checks a few pages as a visitor sees them, and flags one that stopped working, with the update that came just before.

• Saved sets. Save what you switched off under a name, and switch the same things off again in one click.

• Database queries by plugin. How many queries each plugin runs while a page is built, how long they take, and the slowest one.

• JavaScript errors. Recorded in your browser during a session and attributed to a plugin or theme. These never reach the PHP debug log.

• Duplicate libraries. Two copies of jQuery or Select2 on one page, named with both loaders. Found without reproducing anything.

• Where plugins meet. Hooks with callbacks from more than one plugin, and which plugins detach other people’s callbacks.

• Load cost. What each plugin adds to a page, measured by switching it off for your session and reloading.

• What changed. Real version numbers recorded when WordPress updates something, so “it worked yesterday” has an answer.

What it will not do

This is a diagnostic tool, so it does not change things it is measuring:

• It never writes to the active_plugins option, and it prevents anything else from writing it while a session is running.

• It never switches your real theme.

• It never rolls a plugin back for visitors. An earlier version under test runs for your session only, and is deleted when the test ends.

• It never deletes, optimises or repairs anything in the database, and never clears a transient or a scheduled event.

• It never writes to wp-config.php, including to enable WP_DEBUG.

• It never installs its own PHP error handler. It reads what WordPress already records, and states plainly what that misses.

• It never reports a plugin as the cause of anything. It reports what was observed, with the observations attached, and says “strong candidate” where that is what the evidence supports.

Privacy

TroubleLens has no telemetry, no tracking and no advertising, and contacts no third party service. The HTTP requests it makes go to your own site and nowhere else: to your REST API, to check that it answers, and to your own pages, to time them or to see whether a symptom is still there. If you switch on Watch after updates, it also requests the pages you chose after each update, as a visitor would, and emails the site’s own address about one that stopped working if you asked it to.

There are exactly three exceptions, and each only happens when you press the button that causes it.

The outgoing mail check sends a single message to the email address on your own account, so that a site whose mail is broken finds out before its customers do. It carries nothing about your site beyond its name.

org for the list of checksums published for your exact version, and compares the files here against it. All it sends is the version and language needed to identify which list to return. Your own themes, plugins and uploads are never checked, because nobody publishes checksums for those.

org. The request names the plugin and the version, and nothing else about your site.

Support reports are built and rendered on your server. Nothing is transmitted anywhere; you copy or download the report and send it yourself. Before it is shown to you, passwords, salts, authentication keys, tokens, API keys and payment gateway credentials are removed, email addresses are replaced, and absolute server paths are made relative.