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