Resolve Plugin Conflicts without Deactivating All ClassicPress Plugins

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.

  1. Do not disable any plugins or change the theme.
  2. Make a shortlist of any plugins that you think might be related to the conflict.
  3. 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 almost 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 "CodePotent".

Notable Replies

  1. 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 :rofl: ).

    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.

  2. 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.

  3. Thanks, @joyously, @fwolf, and @timkaye for the suggestions. As @1stepforward mentioned, the Query Monitor plugin is probably going to be overwhelming for a new user. I’m not sure how “complicated” the Site Health plugin would seem to a lesser experienced users, but, as it’s a WordPress offering, I didn’t recommend it.

    Also, there’s no guarantee that there will be an internet connection (such as on localhost or in cases where WP_HTTP_BLOCK_EXTERNAL has been misused), so, these plugins might only be helpful if they were preinstalled.

    Moreover, the article is intended to “teach a person to fish” with a critical thought process for dealing with the issue, rather than just giving them a one-time lunch with a plugin they may or may not be able to grok. :slight_smile: I think back to my early days learning JS via jQuery and how, while it allowed me to solve some problems, it actually stunted my growth.

  4. Or…, you can simply install the “Plugin Detective” and solve it in under a minute… just an idea…

  5. And I repeat…

    …as noted, this isn’t about the quickest solution, it’s about building a critical thought process for resolving conflicts. Cheers.

Continue the discussion at forums.classicpress.net

12 more replies

Participants