Resolve Plugin Conflicts without Deactivating All ClassicPress Plugins

Posted on October 16, 2019September 21, 2020 by John Alarcon | Category: Tutorials

Resolving Plugin Conflicts the Proper Way

A common recommendation in the WordPress world when you’re having issues with a plugin is to disable all plugins. Don’t do it!

While we can employ best practices in our own code, we have no control over what other developers are doing. As a result, plugin conflicts will sometimes happen. What’s more, another developer’s plugin might be causing the issue, while it is my plugin that actually exhibits the symptoms.

When these types of issues arise, the most common thing a developer will recommend is to deactivate all your plugins, set your theme to TwentyWhatever, then try their plugin again. While this has been the standard advice for a decade, this is often a waste of time. There’s a better way.

About Deactivating Plugins

Consider what happens when you deactivate a plugin. Do you actually know? Yeah, me neither. Other than the plugin no longer working, it may not be clear what has changed. Were options deleted? Were settings lost? Is the site still working? The answer is: it’s up to each and every plugin developer, so, who knows.

Unless you dig into the code of each plugin, you never really know what may happen when you deactivate them. You just might get stuck having to reconfigure a bunch of plugins. This is why it is preferable to not deactivate all plugins as a first course of action – you just don’t know what may be lost. So, instead of deactivating all plugins at once, I take a more thoughtful approach to make the best use of my time.

Conflict Resolution Plan

The steps listed here will seem logical once you’ve gone through them. Indeed, they will probably even seem obvious once they’re pointed out.

Do not disable any plugins or change the theme.
Make a shortlist of any plugins that you think might be related to the conflict.
Deactivate the first plugin on your shortlist and check to see if the conflict persists.

Does the conflict persist?

If so, reactivate that plugin and then repeat (step 3) with each plugin on your shortlist.

Is the conflict resolved?

If so, you now know which plugin is conflicting. There is usually no need to deactivate any remaining plugins.

If processing through your shortlist of suspected plugins does not reveal the conflict, start at the top of the main plugin list and repeat the process – deactivate, check for conflict, reactivate – until you find the conflicting plugin.

Wrapping Up

Deactivating all plugins in one quick action can be tempting when plugin conflicts arise, but, it’s often unnecessary. Without knowing exactly what every plugin does upon activation, it is very much a “shot in the dark” that mass-deactivation won’t actually create more work. Your gut instinct (which then becomes your shortlist) is often a very quick way to conflict resolution, and, if not, you have a more systematic approach to determine just where that conflict lies.

What do you think?

Are you in support of a thoughtful approach, or would you just deactivate them all and hope for the best? Have you ever had anything unexpected happen when you deactivated a plugin? I have my own opinion about what a plugin should do upon activation, but, what do you think? I’d love to hear your thoughts – let me know in the comments!

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.

About John Alarcon

John Alarcon is a prolific creator of things. In late 2018, his attention turned to ClassicPress and, with more than a decade of WP experience already under his belt, he immediately began releasing plugins, articles, and tutorials created specifically for ClassicPress, solidifying his commitment to the project and establishing a role as a respected leader in the space. You can find John all over the web under the name "Code Potent".

View all posts by John Alarcon | Website

Notable Replies

Mark says:
October 16, 2019
Initially I would have done the deactivation and theme change, but as this more often than not messed up the website, lost settings, widgets moving or disappearing etc.
So my approach is very similar to yours.
If I am adding a new plugin and there is a conflict, I would make a list of most likely culprits based on, which, if any plugins have given problems before, which plugin/s have overlapping functions. Next check on plugin site/forums if anybody else has had a similar problem. Maybe even decide on a different plugin. If that does not give me a fix then your Conflict Resolution Plan would be my approach also.
1stepforward says:
October 16, 2019
That’s good advice John and pretty much what I do already. It’s irritating when I’m told to “disable all plugins and switch to a standard WordPress theme”. I’ve never known that to be effective and it’s just lazy - the equivalent of “just switch it off and back on again” (although that does at least work sometimes. Well, quite a lot actually ).
Just to add to your approach, I also make sure that debugging and logging are enabled (though not displayed). I sometimes also find it useful to prevent concatenation of scripts in admin as I find that helps to get a better idea of what’s being loaded.
More advanced users might want to try this. The commands in wp-config.php are as follows:
```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'CONCATENATE_SCRIPTS', false );
```
but obviously only do this if you know what you’re doing.
anon71687268 says:
October 16, 2019
Mark:
Initially I would have done the deactivation and theme change, but as this more often than not messed up the website, lost settings, widgets moving or disappearing etc.
I figure most of us who have migrated from the WP space will have gone through the disable-everything phase. In our defense, it was the prevailing advice for a decade. It’s likely that quite a few of us have come up with similar methods to save time/work/sanity. Hopefully the article will give newbies a head start.
anon71687268 says:
October 16, 2019
1stepforward:
Just to add to your approach, I also make sure that debugging and logging are enabled (though not displayed). I sometimes also find it useful to prevent concatenation of scripts in admin as I find that helps to get a better idea of what’s being loaded.
Yeah, if scripts couldn’t be reconstituted and unminified, it would be annoying. I often prefer to see PHP errors in-place right where they occur. On a live site, it just takes a few extra lines.
```
if (!empty($_GET['secretkey']) && $_GET['secretkey'] === 'somevalue') {
    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', false );
    define( 'WP_DEBUG_DISPLAY', true );
    define( 'CONCATENATE_SCRIPTS', false );
}
```
Then, to debug:
https://mysite.com/?p=123&secretkey=somevalue
…or if I’m testing with short URLs…
https://mysite.com/some-page-title/?secretkey=somevalue
I just make up a new secret key and value pair each time there’s need to debug in production (which should be fairly rare). After completion, the constants get set back to disable debugging.
joyously says:
October 16, 2019
You should try the Health Check plugin, which puts a small part of itself as a mu-plugin for Troubleshoot mode. This lets it disable plugins and themes for your user only, without affecting site visitors.
we recommend it a lot in the support forums. (written by the support team lead, Marius) The testing and reporting portion of it went into WP core as Site Health, but the Troubleshoot part is only in the plugin.

Continue the discussion at forums.classicpress.net

12 more replies