GetWordPressPlugins
Home › Guides

Troubleshooting Plugin Conflicts

Updated 26 September 2026 · 5 min read

A plugin conflict is two pieces of software disagreeing: both want to change the same checkout field, both load two versions of a JavaScript library, or one assumes a function another just renamed. The site might show a white screen, a fatal error in wp-admin, a feature that silently stops, or a layout that collapses only on one page. This guide covers symptoms, staging and safe mode, the deactivate-all-then-reactivate method, recovery mode email, renaming a plugin folder, the debug log, and how to report a useful bug. Work slowly. Random extra plugins “to fix the error” usually add a second error.

Recognize the symptoms

Common patterns:

  • White screen of death (blank page) after activating a plugin or updating one.
  • A PHP message at the top of the site or in wp-admin: undefined function, memory exhausted, cannot redeclare class.
  • One feature dies: forms stop sending, cache never clears, login loops, checkout total stuck.
  • The front looks fine but wp-admin does not, or the reverse.
  • Only one browser, or only logged-in users, or only mobile — which often means cache or a minified script, not destiny.

Write down what changed last: a new plugin, an update, a PHP version bump, a theme change, a host migration. If nothing changed, still note when you first saw it. Then take a backup if you can still reach the tools; see WordPress backups explained. Do not troubleshoot without a way back.

Prefer staging; use a maintenance window on live

Staging is the copy of the site where you can deactivate everything without taking the shop down. Clone first if the host offers it. If you must work on production, pick a quiet hour, enable a maintenance notice if you have one, and tell anyone else with wp-admin access to wait.

Caching will lie to you. Purge plugin cache, host cache, and CDN cache, and test in a private browser window. Otherwise you will “fix” something and still see the old broken page.

Deactivate all, then reactivate one by one

The classic isolation method:

  1. In wp-admin → Plugins, deactivate all plugins (on staging). If the problem vanishes, a plugin was involved. If it remains, switch to a default theme (a current default theme from WordPress) to see whether the theme is the other half of the fight.
  2. Reactivate plugins one at a time, starting with must-haves (the shop, the membership, the security plugin you actually use). Test the broken path after each activation.
  3. When the problem returns, the plugin you just turned on conflicts with something already on — or it is broken on its own. Deactivate it, confirm the site recovers, then try it with a smaller set to see its partner in the conflict.

Two plugins that both provide page cache, SEO sitemaps, or contact forms are usual suspects. So are “optimize everything” tools that rewrite JavaScript. The categories map in essential plugin categories is there to prevent this pile-up before it starts.

If you cannot reach Plugins because wp-admin is dead, skip to folder renaming below. Do not keep refreshing hoping for a different error.

WordPress recovery mode

When a fatal error happens in a plugin or theme, WordPress may catch it and email the admin address a link to enter recovery mode. That link logs you into wp-admin in a special session where the failing plugin is paused so you can deactivate it. Use the link from the inbox, not a search-result copy. It expires.

Check the spam folder. If the email never arrives, the site cannot send mail, or the admin email is wrong (Settings → General, when you can see it). Recovery mode is not a fix; it is a door. Once inside, deactivate the offender, then decide whether to replace it or report the bug.

If recovery mode itself fails, you still have the file system.

Rename the plugin folder via file manager or FTP

Using hosting file manager or SFTP:

  1. Go to wp-content/plugins.
  2. Find the plugin’s folder (the slug in the URL of its directory page is a clue; it may not match the brand in ads).
  3. Rename it, for example broken-plugin.disabled. WordPress will treat it as missing and deactivate it.
  4. Reload the site. If it comes back, you found a culprit or at least bought time.

Rename one folder at a time if you can guess; if you cannot, rename several suspects, restore the site, then bring folders back one by one. Do not delete until you have a backup. A similar trick exists for themes in wp-content/themes if the theme is the fatal error (WordPress should fall back if the active theme folder disappears, but have a default theme present).

This is also how you disable a cache plugin that locked you out, which pairs with caching and performance plugins explained.

Turn on the debug log (then turn it off)

On a copy of the site, you can ask WordPress to write PHP errors to a file. In wp-config.php, the usual pattern is:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

That logs to wp-content/debug.log without printing errors to visitors if display stays false. Reproduce the bug, then read the end of the log. You want a file name and line, not a screenshot of a blank page. When you are done, set WP_DEBUG back to false so the log does not grow forever or leak paths.

Never leave WP_DEBUG_DISPLAY true on a public site. Error messages can show plugin paths and query fragments. If you are not comfortable editing wp-config.php, ask the host or a developer rather than guessing quotes.

Report a useful bug to the developer

Good reports get better answers. Include:

  • WordPress version, PHP version, and the plugin version (from the listing or the plugin header) — facts from your dashboard, not guesses.
  • Exact steps, expected result, actual result.
  • Whether it happens with a default theme and only that plugin active (the “clean install” test on staging).
  • The relevant lines from the debug log, not a 40 MB file.
  • Whether it started after an update of this plugin or of another.

Use the plugin’s support forum on WordPress.org for directory plugins, or the author’s documented support channel for paid ones. Do not paste passwords. Do not demand a timeline. If two plugins fight, tell both authors; sometimes only they can decide who should load first.

While you wait, keep the site running with the conflicting plugin off, or with a simpler alternative. A dead checkout is worse than a missing convenience feature.

Checklist

  • Note the last change; back up if possible; purge caches.
  • Isolate on staging: default theme, plugins off, then one by one.
  • Use recovery mode email when it arrives.
  • Rename the plugin folder if wp-admin is unreachable.
  • Log errors privately, then turn debug off.
  • Send a factual report; run the site without the offender until there is a fix.

When the site is stable, remove the plugin you do not need instead of leaving it deactivated. The next conflict is easier to solve on a short list.

Related guides

Independent information; we are not affiliated with WordPress or any plugin developer. Always back up before changing plugins.