WordPress plugin conflict: how to find the two plugins that clash

What is a WordPress plugin conflict?

A WordPress plugin conflict is two plugins that each work on their own and break the site when both are on. The fault lives in the pair, not in either plugin, which is why the usual “find the bad plugin” steps can miss it.

It often shows up after an update, when one plugin adds a function or a setting that another already uses.

Tracing a clash like this, on a copy of the site so the live one stays up, is part of our WordPress maintenance work.

How did we test it?

We built a test site on WordPress Playground on 17 Oct 2026: WordPress 7.1.3 on PHP 8.3.33, with debug logging on and errors hidden from visitors.

It had ten small plugins we wrote for the test. Two of them, Lab Gift Notes and Lab Order Notes, each declare a function with the same name, as two real plugins can when neither checks first. Two more set the excerpt length, one to 10 words and one to 40. The other six do nothing and stand in for the rest of a normal plugin list.

What does a plugin conflict look like on the site?

With eight plugins on, the clashing pair among them, the front page answered with an HTTP 500 and the line “There has been a critical error on this website.”

Each of the two alone loaded with a 200. Only the pair broke it.

That screen is the same one any fatal error gives, so our guide to what “There has been a critical error on this website” means covers the other causes behind it.

Why does turning off half your plugins not find it?

The halving method finds one bad plugin in a few rounds. It does not find a pair.

We split the eight plugins into two halves of four. The first half loaded. The second half loaded too. We split the second half again, and both quarters loaded. Every test passed, yet all eight together still crashed, because Lab Gift Notes sat in one half and Lab Order Notes in the other.

So if every half you test works and the full list does not, stop halving. You are looking at a conflict.

Where does the error log name both plugins?

Read the log before you switch anything off. With WP_DEBUG and WP_DEBUG_LOG set to true in wp-config.php, WordPress writes PHP errors to wp-content/debug.log, as the WordPress debugging handbook sets out. Many hosts also keep a PHP error log in the control panel.

Our log held this line:

PHP Fatal error: Cannot redeclare lab_format_note() (previously declared in /wordpress/wp-content/plugins/lab-gift-notes/lab-gift-notes.php:3) in /wordpress/wp-content/plugins/lab-order-notes/lab-order-notes.php on line 3

The folder after plugins/ names each one. The second plugin is the one PHP stopped on, but the first is half of the fault. Removing either brings the site back.

Switch debug logging off when you are done, because debug.log sits in a folder that visitors can request.

What if two plugins clash with no error at all?

Some conflicts never crash anything. Two plugins change the same setting through the same filter, and the one loaded last wins.

Our excerpt test shows it. The Hello world post has a 15 word excerpt. With only the 10 word plugin on, it was cut to 10 words. With both on, it was cut when the 10 word plugin loaded last and shown in full when the 40 word plugin loaded last. No log line, no warning.

WordPress sorts the active plugin list when you activate one from the dashboard, as its activate_plugin() reference shows, so the order is usually alphabetical by folder name. A setting that “stopped working” after a new plugin went on can be this.

How do you find a WordPress plugin conflict without a log?

Work on a staging copy, not the live site:

1. Switch every plugin off and check the fault is gone. If it stays, the cause is the theme, PHP or WordPress itself.
2. Turn the plugin you suspect most back on, often the one updated last.
3. Turn the others back on one at a time, checking after each.
4. The one that brings the fault back is the second half of the pair. Test the two alone together to confirm.

The Health Check & Troubleshooting plugin does the same switching for your own login only, so visitors keep the normal site. We did not run it in this lab.

When you have the pair, update both, then report the clash to each author with the log line. Replace whichever one you depend on less if no fix comes.

We take on this kind of job as a single fix. On a staging copy we read the logs, find the pair and hand back the change that keeps both working, or the swap we made.

What did we not test?

• The dashboard’s own check when you activate a plugin that crashes.
• The recovery mode email, since our test site sends no mail.
• The Health Check & Troubleshooting plugin.
• JavaScript conflicts, where two plugins break a button or the editor and PHP logs nothing.
• Real plugins from wordpress.org. Ours were written for the test.

Is a plugin conflict breaking your site right now?

Tell us what broke and which plugins changed last, and we will say which test from this list to run first.

Rather start with a second opinion? Ask for the free site check with your site address, and a written reply comes within 2 business days. If the site broke straight after an update, our guide to a WordPress site broken after an update reads each screen you might see.