Resolve Plugin Conflicts without Deactivating All ClassicPress Plugins

Originally published at: https://www.classicpress.net/blog/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…

8 Likes

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.

2 Likes

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.

3 Likes

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. :blush: 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. :slight_smile:

1 Like

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 Likes

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.

2 Likes

Maybe using the cookie supplied by the Query Monitor instead might be better (and more secure)? :slight_smile:

cu, w0lf.

2 Likes

You beat me to it, @fwolf! I’d use Query Monitor for this too.

2 Likes

I use Query Monitor too but only for development. It’s a great tool but not one for newbies. :confused:

2 Likes

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 Likes

I certainly could come up with a plugin, or even better, with an external script which bypasses the regular WP setup, that could be just dropped into eg. the WP / CP root, and called externally. Does have the advantage of a) still being logged in as admin user and b) enabling all of the debugging stuff, but WITHOUT editing wp-config.php etc. pp.

Actually I’m already using something similar, but just for the purpose of injecting a user, for those special cases when logins are forgotten, broken or the site owner simply doesnt know how to do that …

HINT: Its not really a special case, but kind of a regular use case :wink:

cu, w0lf.

1 Like

This is a logical and what I’ve always believed customary approach to pinpointing a bad actor but getting the word out to all is certainly a good decision/great help. I would like to add to the conversation that I find the debug/trace runtime and Admin Color Bar with WP-CLI integration applications that I enable when powering up DesktopServer are quite helpful. If you want to learn more, here’s a link: https://serverpress.com/featuring-debug-trace/ I added a blueprint for ClassicPress to my DesktopServer so I can opt for an install of CP. Hope this of help to someone out there.

1 Like

trace looks like overkill imo when you can simply tail the error logs and do
error_log( print_r( $somevar, true ) );

1 Like

You’re welcome, of course, :slight_smile: to use the work flow that is best suited to you. In my case, I moved away from local WAMP to DesktopServer some five years ago; when I launch my local server using the DS UI, I find it handy to quickly enable the plugins apropos for the moments ahead. When I enable Debug/Trace, I don’t have to remember to change an entry to the wp-config file before deploy. And while, sure, you can use error_log in various places and look at its debug log, I’m happy as a warm kitty snuggled in a tiny box having the window pop on my desktop to view execution of php or javascript for trouble-fixing and having the clear button to tidy up the space and rerun. I don’t have to take the extra step of deleting the code line which suits me as I’ve grown lazy as I’ve aged. (Not too lazy but just kinda) Buy hey, whatever turns you on should be what you turn on!

1 Like

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

3 Likes

Thanks Nick (and good to see you back). There are certainly many different ways to approach the problem.

2 Likes

And I repeat…

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

6 Likes

While declaring compatibility with WP4.4+, it seems to require (as an example)
wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php
that is from WP 5.0.0 and so it’s not compatible with CP.
Simone.

1 Like