A WordPress plugin conflict happens when two pieces of software that work independently interfere with one another when they run together. The symptoms can range from a missing button to a fatal error, broken checkout, failed form or Elementor editor problem.
Prove the conflict before you start replacing plugins.
Reproduce the fault, note recent changes, then test the suspected plugin or theme in a staging environment. If disabling one component removes the problem and re-enabling it brings the problem back, you have useful evidence.
What a plugin conflict can look like
Elementor or block editor will not load or save.
Payment fields, totals or buttons stop working.
CSS, JavaScript or templates display incorrectly.
PHP crashes when two components interact.
A conflict is not the same as one broken plugin
If Plugin A fails even when everything else is inactive, Plugin A may simply be broken. A true conflict appears because two components interact badly. That distinction matters when reporting the problem to a developer.
WordPress.com’s current plugin conflict guidance defines the same principle: each component may work alone, but the combination fails.
1. Record the exact symptom
“The website is broken” is not enough. Note the page, action, device, error text, time and whether the issue affects logged-out visitors. If there is a PHP or JavaScript error, preserve it.
2. Check what changed
Conflicts often become visible after one plugin updates, WordPress changes version, PHP changes or a new extension is installed. The last change is not automatically guilty, but it is the strongest place to start.
3. Use staging whenever the site matters commercially
On a live WooCommerce, booking or lead-generation site, turning off every plugin can break payments, forms, security, cookies and tracking. Clone the site to staging where possible and reproduce the problem there.
4. Test one variable at a time
Disable the most likely component and retest. If the fault disappears, re-enable it and confirm the fault returns. Then test its interaction with the other likely plugin or theme.
The Learn WordPress conflict troubleshooting lesson recommends controlled deactivation and reactivation to identify the source.
Same action triggers it.
Disabling A removes it.
Re-enabling A returns it.
Errors and versions recorded.
5. Check whether the theme is involved
Plugins can conflict with themes as well as other plugins. If the issue disappears with a default theme on staging, the theme or its custom code may be part of the problem.
6. Do not leave business-critical plugins disabled
Once you identify the conflict, decide whether to roll back, update, replace or patch the component. A temporary workaround that disables payments, backups or security is not a finished fix.
What to send the plugin developer
- WordPress version
- PHP version
- Plugin and theme versions
- Exact steps to reproduce
- Error log or console message
- Whether the issue occurs with a default theme
- Which plugin combination triggers it
Clear evidence is far more useful than “your plugin broke my site”.
Preventing plugin conflicts
Keep the site maintained, remove abandoned plugins, test higher-risk updates on staging and avoid installing several extensions that solve the same problem. Our WordPress update guide explains a safer update cadence.
Use our emergency website fixes service. For staged updates and ongoing compatibility checks, see website maintenance and support.
A plugin failing is not always a plugin conflict
A useful distinction from current WordPress troubleshooting guidance is that a true conflict happens when two components work independently but fail when they are active together. If one plugin produces the same fault while every other plugin is disabled, that plugin may simply be broken or incompatible with the current WordPress/PHP environment rather than conflicting with a second plugin.
Use controlled isolation instead of guessing
On staging, reproduce the fault first. Then test the suspected plugin alone, test the second suspected component alone, and finally test them together. On a site with many plugins, you can reduce the search faster by deactivating roughly half the non-essential plugins, retesting, then continuing with the half that still reproduces the problem. Always keep notes so you know which exact combination was active when the fault appeared.
WordPress version, PHP version, plugin/theme versions, exact reproduction steps, the error message or log entry, and the smallest confirmed combination of components that triggers the fault. That is much more useful than saying “your plugin broke my site”.
WordPress.com’s current plugin and theme conflict guidance also recommends confirming each suspected component independently before concluding that two plugins conflict.
How to prove a real plugin conflict
A true conflict means two components work independently but fail when they run together. Deactivating one plugin and seeing the symptom disappear is only a clue; it does not prove which component is defective or whether the interaction depends on the theme, PHP version, cache or request context.
Use staging and preserve the evidence
Clone the fault to staging where possible. Record PHP logs, JavaScript errors, failed REST/AJAX requests and the exact steps that reproduce the issue before changing the plugin stack.
Test the suspected pair deliberately
Run Plugin A alone, Plugin B alone, then both together. If the fault only appears when both are active, you have much stronger evidence to send to the developers.
Check theme, PHP and cache context
Some conflicts only appear with a specific theme, PHP version, object cache or optimisation setting. Keep those variables stable while isolating the plugin interaction.
Choose the least risky permanent fix
The final answer may be an update, rollback, configuration change, code patch or replacement plugin. Leaving a payment, backup or security plugin disabled is a diagnostic state, not a finished repair.
Competitor gap: do not use “disable everything” as the first live-site step
That common advice is intended for controlled testing. On a live WooCommerce, membership or lead-generation site it can stop payments, forms, tracking and security while also changing the state you are trying to diagnose.
FAQ
How do I know which WordPress plugin is conflicting?
Reproduce the issue, then use controlled deactivation on staging until the fault disappears. Re-enable the suspected component to confirm.
Can two plugins both be up to date and still conflict?
Yes. Current versions can still make incompatible assumptions or change the same scripts, hooks or data.
Should I disable all plugins at once?
Only as a controlled diagnostic step where safe. On a live business site, staging is usually the better place for broad conflict testing.