Skip to content
Website Rescue Rescue

Plugin Errors

WordPress Plugin Conflict

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Two or more active plugins (or a plugin and the theme) are incompatible. Bisect by deactivating half the plugins at a time on staging or via FTP, re-enable until the conflict returns, then keep one package off or replace it—do not confuse a multi-plugin conflict with a single plugin update fatal.

Plugin conflicts cause white screens, critical errors, missing features, or admin tools that fail only when certain combinations are active. This guide separates conflict bisecting from “one update just fataled,” shows how to isolate safely with staging and FTP, and explains how to leave production stable once you know which pair clashes.

Intermediate

What the error means

WordPress loads every active plugin on most requests. Plugins share hooks, rewrite rules, JavaScript globals, REST routes, and database tables. When two plugins assume exclusive control of the same checkout field, admin script, or rewrite, one fatals, overwrites the other, or produces a blank admin screen. A single-plugin update fatal is different: one newly updated slug crashes even with others off. Conflict diagnosis needs a bisect (halve the active set, test, repeat) preferably on staging; blind bulk updates on a live store only add more variables.

Common symptoms

  • Site or feature fails only when two specific plugins are both active
  • Critical error, white screen, or HTTP 500 that clears when half the plugins are off
  • Checkout, forms, page builder, caching, or security tools break in combination but work alone
  • Browser console shows JavaScript errors naming two plugin script handles
  • Admin screen blanks or loses menus only with a particular plugin pair enabled
  • Disabling “everything except WordPress” restores the site; re-enabling in batches recreates the failure
  • Error log fatals alternate between two plugin paths depending on load order

Most likely causes

  1. 01 Two plugins hooking the same action/filter with incompatible expectations
  2. 02 Duplicate functionality (two SEO, cache, security, or form plugins fighting for the same job)
  3. 03 Shared JavaScript global or CSS selector collision in wp-admin or on checkout
  4. 04 One plugin requiring a library version another plugin already loaded differently
  5. 05 Theme functions assuming a plugin API that another plugin replaced or removed
  6. 06 Must-use plugin or drop-in that stays loaded even when you “deactivate all plugins” in wp-admin

What changed before the problem started

  • New plugin installed or an existing plugin activated alongside others
  • One plugin updated while its “partner” stayed on an older major version
  • Theme or child-theme update that changed how plugins enqueue assets
  • Security or optimization plugin settings tightened (script blocking, REST limits)
  • Staging sync that activated a different plugin set than production previously ran

Troubleshooting steps

  1. 01

    Prefer staging for the first bisect

    Clone production to staging with the same PHP and WordPress versions. Reproduce the failure there, then deactivate half the plugins, test, and repeat on the half that still breaks. Staging protects checkout and lead capture while you learn the conflicting pair. Success signal: you can name two plugins (or plugin + theme) that must both be active to fail.

  2. 02

    If production is already down, rename plugins via FTP

    Rename wp-content/plugins to plugins.off to confirm plugins are involved. Restore the folder name, then rename half the individual plugin folders to .disabled, reload, and continue bisecting. Settings stay in the database; you are only stopping code from loading. Success signal: site loads with a reduced set; one re-enabled folder brings the failure back.

  3. 03

    Rule out a single-plugin update fatal first

    If the outage started immediately after updating one plugin, deactivate or rename only that slug first. If the site recovers with everything else still active, you have an update fatal—not a multi-plugin conflict. Roll that plugin back before spending hours on a full bisect. Success signal: one folder rename alone restores the site.

  4. 04

    Re-enable in small batches with a front-end and admin check

    After the site is stable with a minimal set, reactivate plugins in groups of two or three. After each batch, test home, login, forms, checkout, and the admin screen that previously failed. When a batch breaks, binary-search within that batch. Success signal: a documented list of “safe together” vs “do not combine.”

  5. 05

    Confirm with logs and a clean browser profile

    Enable WP_DEBUG_LOG with display off, reproduce once, and match fatals to plugin paths. Also test in a private window so browser extensions are not fake “plugin conflicts.” Success signal: log and bisect agree on the same slugs.

  6. 06

    Decide: keep one off, replace, or update both on staging

    Once you know the pair, leave the lower-value plugin deactivated on production, replace duplicate functionality with one maintained tool, or update both packages on staging to versions the vendors claim are compatible. Do not leave production toggling forever. Success signal: production runs a known-good set; staging owns the experiment.

When to stop troubleshooting

Get help when you cannot access FTP or staging, mu-plugins keep the site down after a full plugins rename, database damage is suspected, or you are mid-sale and cannot afford more live toggles. Hand off with the suspected plugin pair, versions, bisect notes, and log lines rather than activating random replacements on production.

Information to collect before requesting help

  • 01 Full list of active plugins and versions (export or screenshot)
  • 02 Which two plugins (or plugin + theme) recreate the failure when both are on
  • 03 Whether a single recent update alone causes the outage
  • 04 Exact symptom (critical error, WSOD, feature-only failure) plus screenshot
  • 05 PHP version and WordPress version
  • 06 Error log lines naming plugin file paths
  • 07 Whether staging is available and matches production PHP/WordPress

How a professional repairs the problem

We separate single-update fatals from true multi-plugin conflicts, then bisect on staging or via targeted FTP renames until the incompatible pair is named. After production runs a stable set, we recommend keep/replace/update paths, flush caches, and verify critical journeys. Finally we document which combinations must not ship together and how to retest after future updates.

Frequently asked questions

How is a plugin conflict different from a plugin update that broke the site? +
An update fatal usually names one newly updated slug and clears when that folder alone is disabled. A conflict needs two (or more) packages active together and may have nothing to do with the latest version numbers.
Will deactivating plugins delete my content? +
No. Deactivating stops PHP from running. Posts, pages, and most settings remain in the database. Some shortcodes or blocks may show raw tags until you reactivate a working replacement.
Can two security or two cache plugins conflict? +
Yes. Duplicate “same job” plugins are a common conflict source. Prefer one well-configured tool per job rather than stacking overlapping firewalls or page caches.
Why does “deactivate all” in wp-admin not fix it? +
Must-use plugins and some drop-ins still load. If wp-admin itself is down, use FTP to rename the plugins folder and inspect mu-plugins separately.
Should I update all plugins to resolve a conflict? +
Not on production first. Update the conflicting pair on staging one at a time with backups between each. Bulk updates can introduce new fatals on top of the conflict.
Do themes count as part of a plugin conflict? +
Often yes. Themes enqueue scripts and use the same hooks. Switch briefly to a default theme during bisect to see whether the clash is plugin–plugin or plugin–theme.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.