Igor
To find which WordPress plugin broke a site, work on a staging copy, switch to a default theme, then deactivate plugins in halves until the problem stops, and read the PHP warning if there is one, because its file path usually names the plugin. A faster route is to know what changed: recent plugin updates, and the versions running at the moment the client saw the fault. Below is the manual method, the shortcut with Troubleshooting Mode, and a way to get the evidence from the client's own report without logging in.
Before you touch anything
A live client site is not the place to deactivate plugins one at a time. Take a backup, and if you can, clone the site to staging. If you must test on production, do it at a quiet hour, and note the active plugins first so that you can put them back. A shop that stops taking orders for ten minutes while you test costs more than the bug did.
Start with what changed
Most conflicts follow a change. Ask three questions:
- Which plugins, themes or WordPress itself were updated recently?
- Did the problem start after a specific update, a new plugin or an edit to the theme?
- Did the host change the PHP version? A plugin that worked on PHP 8.1 can fail on 8.3.
The dashboard's Updates screen and the host's panel often show this. If the bug started on Tuesday and a checkout plugin updated on Tuesday, you have your first suspect without disabling anything.
Read the PHP warning
If the page shows an error, or the site fails with a white screen, there is often a PHP warning or fatal error behind it. Look at the path in the message. A line such as wp-content/plugins/checkout-plus/cart.php on line 88 names the plugin: the folder after plugins/. A path in wp-content/themes/ points at the theme, and a path in wp-includes/ points at WordPress core, where the cause is usually a plugin passing it bad data.
To see these on a staging site, turn on logging in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );The messages are written to wp-content/debug.log. Turn it off again when you are finished; do not leave debug logging on a live site. Also open the browser console on the broken page: a JavaScript error with a file in wp-content/plugins/ names a plugin in the same way.
Deactivate in halves
If the warning does not name the culprit, use a binary search:
- Switch to a default theme such as Twenty Twenty-Five. If the problem disappears, the theme is involved, and you can stop looking at plugins.
- Deactivate half the plugins. Reload the page that failed.
- If the problem is gone, the culprit is in the half you switched off; reactivate half of those. If not, it is in the half that is still active. Repeat.
- When you reach one plugin, reactivate the rest and confirm that switching that one on and off toggles the fault.
With 30 plugins, this takes about five rounds, not thirty. Some plugins depend on each other (a WooCommerce add-on needs WooCommerce), so deactivate the add-ons first and the parent last. A conflict is sometimes between two plugins, not one; if the fault disappears with either one off, you have found the pair.
Troubleshooting Mode
The free Health Check & Troubleshooting plugin from WordPress.org adds a Troubleshooting Mode. It disables all plugins and switches to a default theme only for your own session, so visitors still see the normal site. You can then enable plugins one by one and watch for the fault. It is much safer than changing the live site for everyone, and it is the first thing to try when you cannot clone the site.
The theme and the builder
Page builders and themes add their own scripts and styles to every page. Elementor, Bricks and Divi are common, and the version of the builder matters: a builder update can break a theme that has not caught up. When a layout breaks but nothing errors, the cause is more often CSS or script from a builder, a theme or an optimisation plugin (caching, minification) than a PHP fault. Clear the cache and switch off minification and combining of scripts as one test before blaming a plugin.
Get the evidence from the client's report
The slow part of all of this is not the test; it is finding out what the site looked like when the client saw the problem, without a login to their wp-admin. This is what the SnagRelay WordPress plugin is for. The client clicks Report on the page, points at what broke and writes what they expected. The ticket then carries a snapshot of the site with the report:
- the WordPress, PHP and MySQL versions, and whether the site is multisite
- the active theme and parent theme, with versions
- the active plugins with versions, and the plugins and themes updated recently
- PHP warnings and fatals from the request that was reported, and notices when
WP_DEBUGis on - the name and version of Elementor, Bricks or Divi when one is active
- WooCommerce details, such as the version, currency, cart item count and payment method id, when WooCommerce is active
With the "recently updated" list and the warning's path, the first suspect is often named before you open the site. The client needs no WordPress login and no SnagRelay account. If you work with a coding agent, it reads the same ticket over MCP and can work on the plugin or theme in your own repository; it does not get a login to the live site. See the WordPress plugin page.
What this does not do
- It does not read
debug.log. It records warnings and fatals from the reported request only. - The snapshot is fetched over the internet, so the site must be publicly reachable. Local sites and sites behind a firewall or an HTTP login send the report without the snapshot.
- It names the likely culprit; it does not decide it. You still confirm with a test on staging.
- It does not fix the conflict. A developer or an agent working from the ticket does that.
FAQ
How do I know if a plugin conflict is causing my WordPress problem?
Switch to a default theme and deactivate plugins in halves on a staging copy. If the fault disappears at some point, a plugin or the theme is involved. A PHP warning with a path in wp-content/plugins/ names a plugin directly.
What is a white screen of death?
A blank page, usually caused by a fatal PHP error. Turning on WP_DEBUG_LOG on a staging site shows the error and the file, which names the plugin or theme behind it.
Can I test for conflicts without affecting visitors?
Yes. Use a staging copy, or Troubleshooting Mode from the Health Check plugin, which changes only your own session.
Should I update all plugins at once?
No. Update on staging first, a few at a time, and test the pages that matter (checkout, forms, login). If something breaks, you know which update did it.