Quick answer: A WordPress plugin conflict happens when two plugins, or a plugin and your theme or WordPress core, interfere with each other and something breaks. To troubleshoot, back up first, then work on a staging copy or use the Health Check and Troubleshooting plugin so visitors are not affected. Switch to a default theme and deactivate all plugins, confirm the problem disappears, then reactivate plugins one at a time until it returns. Check the debug log and the browser console for error messages that point to the cause. Then update, replace or report the conflicting plugin.
What a plugin conflict looks like
Conflicts show up in many ways:
- A blank white page or “There has been a critical error on this website”
- A layout that suddenly looks broken
- Buttons, sliders, menus or forms that stop working
- The block editor failing to load or showing errors
- Checkout or payment steps failing
- Admin pages that are very slow or will not save
- Emails no longer being sent
They often appear right after an update to WordPress, a plugin or the theme, or after installing something new. But they can also appear when a third-party service changes, or when your host upgrades PHP.
Why conflicts happen
WordPress lets many pieces of code run together and hook into the same places. Most of the time that works well. Conflicts arise when:
- Two plugins load different versions of the same JavaScript library.
- Two plugins try to modify the same thing, such as the checkout fields or the login page.
- A plugin relies on a function or behavior that changed in a WordPress or PHP update.
- A plugin’s JavaScript throws an error, stopping other scripts on the page from running.
- Two plugins use the same function or class name without proper prefixes.
- Caching or optimization plugins combine or defer scripts in a way another plugin does not expect.
A recent example: WordPress 5.5, released in August 2020, stopped loading the jQuery Migrate helper by default. Older plugins and themes that relied on deprecated jQuery functions started breaking, which is why the WordPress team released the Enable jQuery Migrate Helper plugin as a temporary fix. Further jQuery updates are planned for WordPress 5.6 in December, so expect more of this kind of issue.
Before you start
Take a backup
Make a full backup of files and database before troubleshooting. You will be activating and deactivating things, and you want a clean way back.
Note exactly what is broken
Write down the page, the action and what happens. “Clicking Add to cart on product pages does nothing on mobile” is far more useful than “the shop is broken.” Note when it started and what changed around that time.
Use staging if you can
The safest place to troubleshoot is a WordPress staging site, a copy of your live site where you can break things freely. Many hosts offer one-click staging.
Step-by-step troubleshooting
Step 1: Clear caches
Before anything else, clear your caching plugin, server cache, CDN cache and browser cache. Sometimes the “conflict” is just an old cached file. Test again in a private browser window.
Step 2: Check for recovery mode emails
Since WordPress 5.2, fatal errors trigger recovery mode. WordPress emails the site admin a special link that lets you log in with the broken plugin or theme paused. Check the admin inbox and spam folder. That email usually names the plugin that caused the error.
Step 3: Turn on debug logging
Add these lines to wp-config.php above the line that says to stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Errors will be written to wp-content/debug.log without showing to visitors. Reproduce the problem, then open the log. File paths in error messages often name the plugin responsible. Turn debugging off when you are finished.
Step 4: Check the browser console
For front-end problems like broken sliders, menus or buttons, open the browser’s developer tools and look at the Console tab. A red JavaScript error often includes the file name of the script that failed. One script error can stop every script after it, so the plugin named may be the cause, or may be the victim of an earlier error.
Step 5: Use troubleshooting mode
The Health Check and Troubleshooting plugin, maintained by WordPress community contributors, has a troubleshooting mode that disables all plugins and switches to a default theme for your logged-in session only. Visitors keep seeing the normal site. You can then enable plugins one at a time in that session. Our article on WordPress Site Health covers the related Site Health screen in core.
Step 6: Isolate the conflict
Whether you use troubleshooting mode or staging, the method is the same:
- Switch to a default theme like Twenty Twenty and deactivate all plugins.
- Test. If the problem persists, it is likely core, hosting or the database, not a plugin conflict.
- If the problem is gone, reactivate your theme and test again.
- Reactivate plugins one at a time, testing after each.
- When the problem returns, the last plugin you activated is involved.
- To confirm a conflict between two plugins, deactivate everything except your theme and the suspect, then add others back until it breaks again.
For sites with many plugins, you can speed this up by reactivating half at a time, then halving the group that causes the problem.
Step 7: If you are locked out
If you cannot reach the dashboard, you can deactivate plugins without it:
- Rename the
wp-content/pluginsfolder via FTP or your host’s file manager to deactivate all plugins at once, then rename it back and reactivate from the dashboard. - Rename a single plugin’s folder to deactivate just that plugin.
- If you have command line access, WP-CLI can do it with
wp plugin deactivate plugin-nameorwp plugin deactivate --all.
Our guide to the WordPress white screen of death covers more lockout scenarios.
Fixing the conflict
Once you know which plugins are involved:
- Update everything. The conflict may already be fixed in a newer version of one plugin.
- Check the plugin’s support forum. Others may have reported the same issue, sometimes with a workaround.
- Roll back temporarily. If a recent update caused the problem, reinstalling the previous version buys time. Treat this as short-term, since old versions may contain security fixes you need.
- Adjust optimization settings. If a caching or optimization plugin is involved, exclude the affected script from combining or deferring.
- Use the jQuery Migrate helper. For jQuery related errors after WordPress 5.5, the helper plugin can restore compatibility while the plugin author catches up.
- Report it. Send the plugin author a clear report: versions, steps to reproduce, error messages and the other plugin involved.
- Replace the plugin. If a plugin is abandoned or the author does not respond, find a maintained alternative. Our article on plugin vulnerabilities explains why abandoned plugins are risky anyway.
Preventing conflicts
You cannot remove the risk completely, but you can reduce it:
- Test updates on staging first, especially major WordPress releases and large plugins like page builders and ecommerce.
- Update in small batches so you know which update caused a problem.
- Keep the plugin list lean. Fewer plugins means fewer combinations that can clash.
- Choose maintained plugins with recent updates and active support.
- Be thoughtful with auto-updates. WordPress 5.5 added plugin auto-updates. They are great for security, but enable them selectively on business-critical sites. See our notes on WordPress auto-updates.
- Monitor key pages and forms so you notice breakage quickly.
A regular maintenance routine with backups, staged updates and testing catches most conflicts before visitors do.
FAQ
How do I know it is a plugin conflict and not my host?
If the problem disappears with all plugins disabled and a default theme active, a plugin or theme is involved. If it persists, look at hosting, PHP version, server errors or the database.
Can a theme cause a plugin conflict?
Yes. Themes often include their own scripts and functionality. Always test with a default theme as part of isolating the problem.
Is it safe to troubleshoot on a live site?
With the Health Check plugin’s troubleshooting mode, changes affect only your session. Deactivating plugins normally affects all visitors, so use staging or a quiet time if you must.
Why did a plugin break when I did not update anything?
Your host may have updated PHP, an external service may have changed its API, or an auto-update may have run. Check update logs and your host’s notices.
Next step
Save this process somewhere your team can find it, and set up a staging site before you need it. Most conflicts take minutes to isolate when you follow the steps calmly.
If you would rather hand troubleshooting and ongoing updates to a team that does this every week, our Turn visitors into customers services include WordPress support and maintenance.
