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.
If the fault began with an update, see the plugin update recovery service. A duplicate-function message has its own Cannot redeclare function diagnostic guide.
Start with evidence, not elimination
- Read the relevant PHP or WordPress error log if available. A named file is a lead to check, not proof that removing the whole plugin is the correct fix.
- 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.
- A session-limited troubleshooting mode may help with your browser request. Check its scope: do not assume it isolates scheduled tasks, webhooks or background processing. Agree the impact and recovery route before any live test.
- 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.
Prepare a recovery brief
Record the exact action, first related error, affected versions and combinations already tested. Specify whether checkout, forms or account access are affected and what backup or staging environment is available.
Request a plugin-conflict assessment and review how the recovery is scoped and verified. The next step depends on the actual installation and business impact.
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 →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Why shouldn't I just deactivate all plugins and re-enable them one by one to find a conflict?+
That method is designed for a test site. On a live site it can stop payments, forms, membership access, and tracking while you work, and changing the application state that way can actually obscure the original sequence of events that would have identified the culprit.
What should I check before disabling anything at all?+
Read /wp-content/debug.log for a fatal error naming a specific file, check the browser console for a JavaScript error and its source script, and review exactly what was updated or installed right before the symptom appeared. In many cases this identifies the component without deactivating anything.
If disabling a plugin makes the problem go away, does that confirm the plugin is the cause?+
Not on its own. Two plugins can appear to conflict when the real issue is a PHP version change, a memory limit, or a caching layer. Confirm why disabling it helped before treating removal as the permanent fix, otherwise you lose a feature you need while the actual cause stays in place.
Is it ever acceptable to test by disabling plugins on a live production site?+
Only if staging isn't available, and even then, do it in a low-traffic window using a conflict-testing plugin that disables plugins just for your own session, leaving visitors unaffected. Never casually disable payment, security, or backup plugins as part of this process, and have a verified rollback ready first.