Something is happening on the site and thirty-one plugins could be responsible. Here is the honest breakdown of the three ways people go about finding out.
Deactivating plugins one at a time is free, needs nothing installed, and eventually works. It costs you a site that is broken in front of real visitors for as long as the test runs, and it answers a narrower question than people think: it tells you which plugin's absence makes the symptom stop, not what that plugin was doing. On a problem that only appears on upload, only for logged-in users, or only when cron fires, the bisection stretches across days. Query Monitor is an excellent profiler and most developers should have it installed. It shows you the hooks that fired, the queries that ran and the HTTP calls that went out — then leaves you to map that back to which of your plugins caused it. WP Plugin Detective (this site) starts from the plugin instead: it resolves every hook callback and every file write back to the code that owns it, measures whether each callback actually changed anything, and states a conclusion with the file, the line and the before-and-after value.
These are different jobs, not competitors. Query Monitor is a permanent fixture on a development install. This is the thing you reach for on the day a client says their images keep turning into a format nobody asked for.
| What you need | WP Plugin Detective | Deactivating one by one | Query Monitor |
|---|---|---|---|
| Names the plugin responsible | ✓ Named, with a confidence level | ◐ Eventually, by elimination | ◐ You work it out yourself |
| Shows the exact line of code | ✓ File and line number | ✗ No | ◐ Sometimes, for queries |
| Shows what the value became | ✓ Before and after | ✗ No | ✗ No |
| Separates listening from responsible | ✓ Only actual changes count | ✗ No | ✗ Lists every subscriber |
| Visitors unaffected while testing | ✓ Nothing is switched off | ✗ Site breaks while you test | ✓ Read-only |
| Catches raw PHP file writes | ✓ With a trace to the line | ✗ No | ✗ No |
| Works on cron, REST and AJAX | ✓ Scoped per investigation | ✗ Difficult | ◐ Limited |
| Stops on its own | ✓ Hard expiry, 15 min default | ✗ Until you remember | ◐ Always on |
| Client-ready branded report | ✓ Branded PDF and email | ✗ No | ✗ No |
| Admits what it cannot see | ✓ Reports the gap honestly | ✗ n/a | ✗ n/a |
| Plain-language explanation | ✓ Written verdict, AI optional | ✗ You write it up | ✗ Raw data only |
Deactivating still wins when the site is already down and you need it up in the next two minutes. Nothing beats switching everything off. Query Monitor still wins as a day-to-day development companion — it is broader, it is free, and it shows you far more about the request as a whole. This wins when the site is working fine except for one specific behaviour, you cannot take it offline to investigate, and you need to be able to tell somebody afterwards what was wrong and why.
Plenty of plugins now advertise AI. In that approach the feature is the AI: you describe a symptom, the plugin sends your description to a model, and the model guesses at a cause from general knowledge about WordPress. The answer sounds authoritative and is only as good as the guess, because nothing measured your site.
This works the other way round. The verdict is produced on your own server by rules, from evidence collected on your site — a plugin either changed image_editor_output_format or it did not, and that is a fact, not an opinion. The AI never finds the culprit. All it does is read evidence that has already been gathered and explain it in a paragraph you could forward to a client. Turn it off and you lose the paragraph, not the answer.
| This plugin | The AI-first approach | |
|---|---|---|
| Who reaches the conclusion | ✓ Rules, on your server | ✗ The model, remotely |
| Works with no API key | ✓ Fully — AI is off by default | ✗ Key required, it is the product |
| What the answer is based on | ✓ Measured evidence from your site | ✗ Your description of the symptom |
| Data leaves the site | ✓ Only when you press send, per case | ◐ On every request the feature makes |
| You see the payload first | ✓ Shown in full before sending | ✗ Rarely |
| Redaction before sending | ✓ URLs, emails, paths, key-shaped strings | ◐ Varies |
| Answer if the AI is wrong | ✓ The evidence is still there to check | ✗ The guess was the whole answer |
| Ongoing cost | ✓ None unless you use it | ◐ Credits or subscription |
Which is the honest way round for a diagnostic tool. If a piece of software is going to tell a client what was wrong with their website, the reasoning behind it should be checkable — and it is: every finding lists the events it was drawn from, whether or not you ever switch the AI on.
Ours too, and it answers the other half of the question. WP Conflict Radar finds the plugin that breaks the site, by bisecting the active set in a session that only applies to your own admin browser. Plugin Detective finds the plugin that performs an action, by watching it happen. Broken site: Radar. Working site behaving oddly: Detective. Plenty of agencies run both.
It will not see a write made by a library that bypasses PHP entirely — an image editor built on Imagick writes through its own C code, and no PHP tool can watch that happen. Rather than guess, the report lists files that appeared with nothing claiming responsibility and names any plugin that replaced the image editor, which is nearly always the answer. It will not fix anything for you: it names the culprit and tells you where its setting lives. And it will not record anything at all unless you start an investigation, which then stops by itself.