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.
Choose a test that can reproduce the actual failure
Start with a full files-and-database backup and confirm how it could be restored. Copy the known failure to staging, record the active plugins, theme, WordPress and PHP versions, and keep a working configuration to return to. Prevent staging from sending real customer messages, charging payments or running production integrations.
Per-user troubleshooting has limits
The Health Check & Troubleshooting directory page describes a default-theme session with plugins disabled only for your user until you leave troubleshooting mode or log out. That is different from a separate staging copy, and it does not reproduce an anonymous shopper’s session automatically. It also does not undo changes you save to shared content or settings.
Check the tool’s current maintenance and compatibility status before installing it. When reviewed on 23 October 2026, that directory page warned that Health Check had not been tested with the latest three major WordPress releases. Do not install an unverified diagnostic plugin on a busy live site merely because an older guide recommends it. A compatible staging test is the safer starting point.
Record a minimum working and failing combination
- Write one repeatable action: for example, open this editor, save this field or add this product with these options.
- Test the required base plugin and its dependencies on staging. An add-on that cannot work without its parent cannot meaningfully be tested “alone”.
- Add one component at a time while keeping the theme, PHP version, cache rules and test data stable. Record working, failing or inconclusive for every combination.
- Confirm whether the failure returns when the suspected combination is restored. An intermittent fault needs repeated checks; one successful attempt is insufficient.
If the dashboard is inaccessible
Ask the host or developer to inspect private PHP logs and the named plugin path. A recovery-mode link is private access information. If a targeted plugin folder rename is necessary to regain access, record the original name and the features that will stop; do not delete the plugin or its data. Avoid broadly disabling security or payment components while customers are using the site.
Agree the repair acceptance before paying for a fix
Request the confirmed versions and failing combination, the chosen update/configuration/patch or replacement, a rollback plan and a repeat of the original test. Recheck relevant forms, bookings or checkout and the actual resulting records. Remove temporary diagnostic access and restore normal logging settings afterwards. A file path in an error identifies where a failure appeared; it does not alone prove which supplier is responsible.
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.
If the conflict is breaking basket or checkout behaviour, the WooCommerce checkout troubleshooting steps should be run alongside the plugin-conflict test.
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, testing groups of non-essential plugins can narrow the search, but it is not conclusive when the conflict needs components from different groups. Keep required dependencies active, record each combination and confirm the smallest failing combination afterwards. Do not discard a group just because the fault disappeared when two interacting components were separated. 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.
Keep broad plugin tests away from a live buying journey
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.
How do you test for a plugin conflict safely?
Start with the plugin most closely linked to the problem, especially if the issue began after an update. Do not disable everything on a live business site unless you have a safe reason to do so.
A staging copy makes conflict testing much safer.
- Back up the site first.
- Reproduce the problem.
- Disable one likely plugin at a time.
- Retest after each change.
