Short answer: plugin conflicts are real, but the usual advice — deactivate everything, then re-enable one by one — is designed for a test site. On a live site it can stop payments, forms, memberships and tracking while you work, and it changes the application state and can obscure the original sequence of events that would identify the culprit.
Start with evidence, not elimination
- Read
/wp-content/debug.log. A conflict producing a fatal error names a file, which usually names the plugin. - Check the browser console for the JavaScript error and the script it came from.
- Establish exactly which action triggers the fault and whether it is reproducible.
- Review what was updated or installed immediately before the symptom appeared.
In many cases this identifies the component without deactivating anything.
If you must test by disabling, do it safely
- Do it on a staging copy whenever possible.
- If it must be live, choose a low-traffic window and use a conflict-testing plugin that disables plugins only for your session, leaving visitors unaffected.
- Change one thing at a time and record each step.
- Never casually disable payment, security or backup plugins.
- Have a verified rollback ready before you start.
Conflict is not always the answer
Two plugins can appear to conflict when the real issue is a PHP version change, a memory limit, a caching layer or an incomplete update. If disabling a plugin makes the symptom disappear, confirm why before treating removal as the fix — otherwise you remove a feature you need and leave the actual cause in place.
Close it properly
Once identified, decide deliberately: update, replace, reconfigure, or report the incompatibility upstream. Re-enable everything you disabled, and re-test the business-critical journeys — checkout, forms, login — before considering the incident closed.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
A conflict test changes application state. Evidence first, staging second and one controlled variable at a time avoid breaking payments, forms or security while diagnosing.
- Read fatal logs, browser console and failed network responses before disabling anything.
- Reproduce the exact action and record recent version changes.
- Clone production state to staging when the affected feature is business-critical.
- Use binary or one-at-a-time isolation and record every activation state.
What must be verified
- The failing action works with the final plugin set.
- Required features remain available after the chosen update, replacement or configuration.
- The result survives cache flush, restart and another controlled test.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →