Fix: WordPress Plugin Conflict

Your site worked. You installed a plugin. Now it doesn't. Here's how to find the culprit in under 5 minutes.

Last updated: October 2026

⚡ The 30-second fix

Deactivate all plugins, then reactivate them one at a time. The plugin that breaks the site when reactivated is the conflict.

If you can't log in, use your hosting file manager to rename wp-content/plugins to wp-content/plugins-disabled. This disables every plugin site-wide and restores access.

What's actually happening

Two plugins are fighting over the same WordPress hook, or one plugin assumes a PHP/WordPress version you don't have, or a plugin modifies global state that another plugin depends on. WordPress doesn't isolate plugins — they all run in the same PHP process, and the last one to modify a shared value wins.

// Common conflict pattern
Plugin A: add_action('init', 'setup_thing', 10);
Plugin B: add_action('init', 'setup_thing', 10);
// Both register the same function → fatal error or silent override

If you can still access wp-admin

The fastest path. Deactivate every plugin, then reactivate one by one.

Go to Plugins → Installed Plugins
Select all plugins via the header checkbox
Choose Deactivate from the Bulk Actions dropdown
Click Apply — the site should recover
Reactivate plugins one at a time, reloading the site after each
The plugin that breaks the site is the conflict

Pro tip: Start with the plugin you installed or updated most recently — it's the cause 80% of the time.

If you have SSH access (WP-CLI)

Faster and safer. Works even when wp-admin is completely broken.

# Deactivate all plugins
wp plugin deactivate --all

# Verify the site loads
# Then reactivate one at a time
wp plugin activate plugin-slug

# Reload the site after each
# When it breaks, you've found the conflict

# To identify the culprit faster (list by last updated)
wp plugin list --fields=name,status,update

Pro tip: wp plugin list shows which plugins have pending updates. Plugins recently updated are the most common culprits.

If wp-admin is broken (file manager / SFTP)

When you can't log in at all. Works on every host including shared hosting.

Open your hosting file manager (cPanel, Plesk) or connect via SFTP
Navigate to wp-content/
Rename plugins → plugins-disabled
Reload your site — it should work
Rename the folder back to plugins
Log into wp-admin and reactivate plugins one at a time

Warning: Renaming the plugins folder deactivates every plugin. If a plugin is critical (like a payment gateway), the site may still not load — but at least wp-admin will work.

If nothing else works (phpMyAdmin)

Last resort — force-deactivates plugins at the database level.

-- In phpMyAdmin, run this on your WordPress database
UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

The wp_ prefix may differ. Check your wp-config.php for $table_prefix.

Backup first. Direct database edits are unforgiving. Export the wp_options table before running this query.

Identifying the exact conflict (advanced)

Once you know which plugin is causing problems, you can often find the specific conflict. This lets you keep both plugins if they're both valuable.

# Enable debug logging in wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

# Then reload the site and check:
# wp-content/debug.log

The debug log will show the exact function or hook conflict, often with the file path of both plugins involved.

Pro tip: If the log shows Cannot redeclare function_name(), both plugins define the same function. That's a hard conflict — one plugin must be replaced.

🛡️ How to prevent this next time

Test on staging first. Never install or update plugins on production without testing. Every host has staging now — use it.
Fewer plugins is better. Every plugin is a potential conflict. If a plugin does one thing, consider a custom function instead.
Check "Tested up to" before installing. A plugin last tested on WordPress 5.8 may misbehave on 6.7.
Look at last update date. Plugins not updated in 2+ years are riskier. Search the plugin slug on wordpress.org to check.
Keep backups automated. If a plugin breaks the site, a 1-click restore is 10 seconds — bisecting takes 10 minutes.
Disable auto-updates on critical plugins. Updates that run overnight give you a broken site at 8am.

Common variations of this issue

Symptom	Likely cause
White screen of death	PHP fatal error from plugin incompatibility
Site loads but styling broken	Plugin conflicting with theme styles
Specific pages 404 or blank	Plugin intercepting a route
Admin works, frontend broken	Frontend-only plugin conflict
Random intermittent errors	Race condition in hook priority

❓ Frequently asked questions

How do I fix a WordPress plugin conflict?

Deactivate all plugins by renaming the wp-content/plugins folder, then reactivate them one at a time until the site breaks again. The last plugin you activated is the conflict.

How do I access WordPress admin if I can't log in?

Use SFTP or your hosting file manager to rename wp-content/plugins to wp-content/plugins-disabled. This deactivates every plugin site-wide and restores admin access.

Can I fix a plugin conflict without WP-CLI?

Yes. WP-CLI is faster, but the file manager method works on any host. Rename the plugins folder, then reactivate plugins one by one from wp-admin.

What causes WordPress plugin conflicts?

Three things: two plugins registering the same WordPress hook, a plugin that assumes a different PHP or WordPress version, or a plugin that modifies global state that another plugin depends on.

How do I prevent plugin conflicts in the future?

Test plugin updates on staging first, keep fewer plugins active, use plugins from active authors, and check the 'Tested up to' field before updating.