A plugin not working in WordPress can be a conflict with another plugin or your theme, and a few quick tests find the culprit.
We tested every method in this guide in October 2026 on a WordPress 7.1 test site, using two pairs of conflicting plugins we wrote ourselves. One pair clashes in PHP, and the other clashes in JavaScript.
This guide covers three ways to check for plugin conflicts. It also shows how to read the debug log and the browser console. It ends with the way back in when a conflict locks you out of your dashboard.
Plugin Not Working in WordPress? Rule Out the Easy Causes First
A plugin not working in WordPress is not always a conflict. Cached pages, an outdated plugin, a wrong setting, or a blocked script can look exactly the same. Spend five minutes ruling these out before you start switching plugins off.
Work through this list first:
- Reproduce the problem: Note the exact page, the action you took, and the message you saw. A fix you cannot repeat is a fix you cannot verify.
- Clear every cache: Purge your caching plugin and your host cache. Then reload the page in a private window.
- Check compatibility: Open the plugin’s page in the WordPress plugin directory and read the Tested up to field. The Health Check plugin page shows how that looks, with a version tag and a warning when a plugin lags behind the latest releases.
- Update everything: Update WordPress, your theme, and the plugin, one at a time, and test after each update.
- Read the message: An error that names a file inside wp-content/plugins points straight at that plugin.
The next table matches what you see to the test that finds the cause.
| What you see | Likely cause | Where to look |
|---|---|---|
| A button or feature does nothing and shows no error on screen | A JavaScript error | The browser console |
| A white screen or a critical error message | A PHP fatal error | The debug log |
| Plugin could not be activated because it triggered a fatal error | Two plugins using the same function name | The debug log |
Back up your files and database before any test. Deactivating a plugin keeps its settings, because WordPress runs a plugin’s uninstall routine only when you delete it, according to the plugin developer handbook.
What Is a WordPress Plugin Conflict?
A WordPress plugin conflict happens when two pieces of code try to use the same name, hook, or resource. The code usually comes from two plugins, or from a plugin and your theme. One or both break, from a dead feature to a site that will not load.
We built both common kinds for our tests. In the PHP clash, two plugins each define a function named demo_format_price(). WordPress cannot load the second plugin and stops with a fatal error.
In the JavaScript clash, one plugin replaces a global variable that another plugin’s Subscribe button depends on. The button stops working, and nothing appears on screen to say why.
WordPress blocks a clashing plugin at activation and shows a short notice. The screen below is what we saw when we activated the second plugin.
Three Ways to Check for Plugin Conflicts
You can check for plugin conflicts with Troubleshooting Mode, by deactivating plugins by hand, or with WP-CLI. Troubleshooting Mode is the safest on a live site because only you see the change. Manual deactivation suits a staging copy, and WP-CLI suits a site you cannot open.
The infographic compares the three. Pick the first one unless you are locked out.
Method 1: Use Troubleshooting Mode in Health Check
Troubleshooting Mode disables every plugin and switches to a default theme for your login only. Visitors keep seeing your normal site. You then enable plugins one at a time from the admin bar, and the plugin that brings the problem back is your suspect.
The mode comes from the free Health Check and Troubleshooting plugin. Its plugin page lists version 1.7.1, more than 200,000 active installs, and a last update in July 2024. It also warns that the plugin has not been tested with the latest three major WordPress releases.
It worked on WordPress 7.1 in our test. The plugin’s own screen says Troubleshooting Mode will become a standalone plugin in the future. It also says must-use plugins stay active during a session. A host’s must-use plugin can therefore still cause trouble.
- Install the plugin: Go to Plugins > Add Plugin, search for Health Check and Troubleshooting and click Install Now. Then click Activate.
- Start the mode: Open Tools > Site Health > Troubleshooting tab and click Enable Troubleshooting Mode.
- Reload the broken page: The page now loads with every plugin off and a default theme, and only you see it. Our test page showed the raw
[demo_button]text instead of a button.
- Enable plugins one at a time: Open the Troubleshooting Mode menu in the admin bar, choose Plugins, and enable one plugin. Reload the page and test again.
- Watch for the break: In our test, the Subscribe button worked with its own plugin enabled. It broke again the moment we enabled the second plugin, which named the pair.
- Turn the mode off: Choose Disable Troubleshooting Mode from the same menu.
Health Check checks that your site still loads after each change. If that request fails, it reverts the change and offers an Enable anyway link. We also confirmed that a logged-out request still loaded every plugin’s script while the mode was on.
Method 2: Deactivate All Plugins and Test by Hand
To deactivate every plugin by hand, open the Plugins screen, tick the box at the top of the list and choose Deactivate from Bulk actions. Click Apply and test the problem. If it disappears, reactivate the plugins one at a time until it returns.
Every visitor sees the plugins disappear while you test. Do this on a staging copy of your site. On a store, deactivating WooCommerce takes checkout offline too.
Reactivate the plugin you suspect least first, and test after each one. The plugin that brings the problem back is half of the answer. Write down its name and version before you move on.
Method 3: Switch to a Default Theme
Switching to a default theme rules your theme in or out. Go to Appearance > Themes and activate Twenty Twenty-Five or Twenty Twenty-Four. If the problem stays after the switch, your theme is not the cause. You can look at the plugins again.
In our test, the Subscribe button stayed broken under both default themes. That told us the conflict sat between the two plugins and not in the theme.
Switching themes changes your site for every visitor. Use the Themes menu inside Troubleshooting Mode instead, because it swaps the theme for your login only.
How to Find Which Plugin Is Causing the Conflict
To find the culprit among many plugins, enable half of them, test, and keep halving the group that still breaks the site. Ten plugins need at most four rounds. A conflict between two plugins appears only when both are enabled.
That last point changes how you read the results. If you enable half the plugins and the problem vanishes, its partner may be sitting in the other half. In our pair, neither plugin was faulty alone, and the break showed only with both on.
So when halving points to one plugin, enable it together with the plugins you trust least. Write down every combination you tested, because a conflict you cannot reproduce will come back.
Read the Debug Log to Find a PHP Conflict
The debug log records PHP errors that never appear on your screen. Add three lines to wp-config.php to turn it on: WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY set to false. WordPress then writes every error to wp-content/debug.log, as the debugging guide explains.
Paste these lines above the comment that says to stop editing:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
The same guide advises against these settings on live sites. Use a staging copy or switch them off afterward. Then open Tools > Site Health > Info and expand WordPress Constants to confirm the values.
Reproduce the problem and then open the log and search for the word Fatal. A notice or a deprecation message is not a failure, and our log filled with them. Even Health Check 1.7.1 logged notices about translations loading too early on WordPress 7.1.
Our PHP clash left this line. We trimmed it so the folder paths are shorter:
PHP Fatal error: Cannot redeclare function demo_format_price() (previously declared in .../plugins/demo-price-format/demo-price-format.php:7) in .../plugins/demo-cart-totals/demo-cart-totals.php on line 7
The line names both plugins and the function they share. That is everything you need to report the conflict.
If your own plugin calls code from another plugin, test if a plugin is active before you use its functions.
Check the Browser Console for a JavaScript Conflict
A JavaScript conflict shows up in the browser console and not in the PHP log. Open DevTools with Control+Shift+J on Windows or Command+Option+J on Mac and then reload the page. Look for red messages because Chrome logs page errors at the Error level.
Our broken button logged a TypeError that said window.demoLib.greet is not a function. One plugin had defined that global, and a second plugin later replaced it with text.
The error pointed at the script that crashed, which was the Subscribe plugin’s file. The plugin that caused it was the other one. Treat the file name as a clue and not as a verdict.
Filter the console to Errors if it is crowded, and test with one plugin on at a time. The Chrome docs say a missing file shows as a 404 and a bad script call shows as an uncaught TypeError.
What to Do When a Conflict Locks You Out of the Dashboard
If a conflict takes down your dashboard, you have three ways back in. Use WordPress recovery mode, WP-CLI, or a renamed plugin folder over SFTP or your host’s file manager. Each one turns off the broken plugin without the dashboard.
A fatal error on the front end shows this message to visitors. We reproduced it by loading the second plugin of the PHP pair.
Recovery mode starts with an email. WordPress core developers describe the recovery mode email as holding a secret link that sets a cookie and pauses the failing plugin for you alone.
On our test site the email went out when we opened the login page. A front-end page load did not send it. The subject was Your Site is Experiencing a Technical Issue.
The link opened a session with the broken plugin paused and a notice naming the fatal error. From there we could deactivate it or resume it.
WP-CLI works without any email. Running wp plugin deactivate demo-cart-totals failed on our site, because WP-CLI loads the plugins and hits the same fatal error. Adding the --skip-plugins flag, which the WP-CLI handbook describes as skipping plugin loading, fixed it:
wp plugin deactivate demo-cart-totals --skip-plugins
WP-CLI answered with Success: Deactivated 1 of 1 plugins. Renaming the plugin’s folder inside wp-content/plugins does the same job. When we renamed one, WordPress deactivated it on the next admin load and showed the notice Plugin file does not exist.
How to Fix a Plugin Conflict Once You Find It
Once you know the two plugins, update both, check each changelog for the clash, and test again. If it persists, report it to both developers with your versions, your PHP version, and the exact error line. Keep the plugin you cannot live without and replace the other.
A good report names the two plugins, their versions, the WordPress version, and the steps to reproduce the problem. The debug log line or the console message goes in as proof. Developers fix what they can reproduce.
If the conflict touches checkout or a live store, you may not want to test it yourself. Our WordPress maintenance services include developer time for plugin conflicts, and we test updates on a staging copy first. Our posts on the white screen of death and fatal errors that block the admin help when the site is already down.
Our guide to the plugin could not be activated fatal error walks through the notice we showed earlier.
How to Avoid Plugin Conflicts
You avoid most plugin conflicts by testing updates on a staging copy, updating one plugin at a time, and keeping your plugin list short. Each of those habits removes a way for two plugins to meet for the first time on a live site.
- Test on a copy: Build a staging site or a local WordPress setup and try updates there first.
- Update one plugin at a time: If a site breaks, you know which update did it. Our post on disabling automatic updates shows how to take control of the timing.
- Keep the list short: Every plugin adds code that can clash. Remove the ones you no longer use. Our post on how many plugins is too many covers the trade-offs.
- Keep a rollback ready: A fresh backup turns a conflict into a ten minute restore. A WordPress care plan can cover updates and backups for you.
Conclusion
For a plugin not working in WordPress, rule out the easy causes and then check for plugin conflicts with Troubleshooting Mode. Turn plugins off by hand only on a staging copy and use the debug log and the browser console to name the cause.
If you are locked out, use recovery mode or WP-CLI with --skip-plugins. Write down the two plugin names, the versions, and the error line before you report the conflict.
Frequently Asked Questions (FAQs)
Q1. How do I know a plugin conflict is causing my problem?
The problem disappears when you turn the other plugins off and returns when you turn them back on. If it persists with every plugin off and a default theme, the cause lies elsewhere, such as your server or a cached page.
Q2. Will deactivating plugins delete my settings?
No. According to the plugin developer handbook, WordPress runs a plugin’s uninstall routine only when you delete the plugin and not when you deactivate it. Back up first anyway.
Q3. Is there a WordPress plugin conflict checker?
Health Check’s Troubleshooting Mode is the closest tool. It does not scan for conflicts on its own. It lets you disable plugins and switch themes for your login only. That way you can test safely.
Q4. Can a theme conflict with a plugin?
Yes. Switch to a default theme such as Twenty Twenty-Five and test again. If the problem goes away, your theme is part of the conflict.
Q5. Can I check for plugin conflicts on a live site?
You can, with Troubleshooting Mode, because the changes apply only to your login. The Health Check plugin page says all plugins appear inactive and a default theme loads for your session. Visitors still see the live site.
Q6. What if two plugins conflict and I need both?
Update both and then send the developers your versions and the exact error. Check each plugin’s settings for options that load a script or function twice. If neither developer can fix it, replace one plugin.
