Stop me if you’ve heard this one before.
You: My computer went crazy.
Support: Okay. Have you tried restarting it?
You: Yes. And it’s still crazy. Maybe even crazier.
Support: Well, let’s try it again. Just in case.
Sound familiar? It should. It’s basically the first 15 seconds of every tech support call that’s ever happened in the world. There’a a WordPress version, too. It’s very similar.
You: My WordPress website went crazy.
Support: Okay. Have you tried deactivating all the plugins and reactivating them one by one?
You: Yes. And it’s still crazy. Maybe even crazier.
Support: Well, let’s try it again. Just in case.
The resemblance is uncanny, right? Because WordPress plugin conflicts are by far the most common issue that WP users face. Everyone uses plugins. And if you haven’t run into the white screen of death or logged in to see your theme look like a Picasso painting, then you should go buy yourself a lottery ticket — you’re the luckiest person I have ever met.
If you’re not that lucky, however, you can do quite a bit before, after, and during the crisis to make sure that WordPress plugin conflicts don’t make things too hard for too long.
Preventative Care is the Best Care
Like eating well and exercising are preventative measures to keep you healthy, you can also practice preventative care on your WordPress site so that when a rare plugin conflict does arise, it is not catastrophic. If done correctly, your preventative measures will lessen the impact of any conflicts that do happen. Exercising every day might help boost your immune system, but you can still catch the flu or break your leg. And your WordPress install might be conflict-free for ages, only to catch a really nasty bug (literally and figuratively) every once in a while.
1. Never Install a Plugin to a Live Site
Rule number 1 of web development: never test on a live site. Even if you’ve used the plugin in the past. Even if you have used it on your personal sites without problem. Never, ever activate a plugin on a live site that you haven’t tested on either a staging site or a local clone. You can do this in multiple ways, and we have a handy-dandy guide you can follow to get started. By working on a test site that’s identical to the live one, you can see what breaks in a safe environment.
2. Take Your Time to Really Test Things Out
When you have your local environment set up, and you’re running your plugin tests, it’s easy (and common) to hit Activate -> Visit Site, and then click around for a while to see if anything’s out of place. Since things look okay, you push the changes live, and things keep running smoothly.
Until the end of the month when you reconcile your Stripe or PayPal reports, and you see that your revenue has dropped 75%. Trace it back, and it’s because you installed Captain Jimmy’s Super Happy Fun Whizbang plugin 3 weeks ago. Turns out, it has a conflict with your payment gateway’s recurring billing cycle, and not one of your subscribers was charged and their subs were cancelled. Every single one of them will have to manually resubscribe.
Uh. Oh.
Just poking around your dev site didn’t work. Sometimes, plugin conflicts are hidden and don’t show up until very specific criteria are met. So it’s definitely in your best interests to run a test of all major functionality before pushing it live. Maybe the plugin conflict only shows up with recurring payments, and not one-time purchases. If you don’t run through all of the primary use-case scenarios for your site, the WordPress plugin conflict will possibly fall right through the cracks.
And FYI, someone close to me had this particular situation happen, so it’s not just a worst-case hypothetical. This really happens, and they missed out on thousands of dollars. So…take your time, folks. Pretty please.
3. Keep Plugin Use to a Minimum
We all use plugins. They’re one of the reasons WordPress is so awesome. But one of the best ways to prevent plugin conflicts is to only use a plugin when you really need it. There are a lot of instances when a simple code snippet can do the same thing as the plugin. Think about it this way: you can’t have WordPress plugin conflict if you don’t have WordPress plugins!
4. Keep Stuff Up-to-Date, but Not Too Up-to Date
WordPress plugin conflicts tend to stem from at least one plugin butting heads with another plugin, your theme, or your WordPress version (and occasionally your server’s PHP version). You can avoid a slew of problems by making sure that nothing on your site is terribly out-of-date. But beware of automatic updates (and of mindless updates — “Oh, cool! A new update for Captain Jimmy’s Whizbang!”…click…click…crash).
Make sure that you know what you’re updating. The WordPress plugin repository has made great strides recently on compatibility information, and it’s imperative that you take a look at what you’re installing.
If a plugin hasn’t been tested with any of the three past major updates, that information is provided at the top of the plugin page. That might not mean there’s a conflict, but you should absolutely test in a safe place before using it on any production site.
And further down the screen, you can see information on the plugin that can help prevent issues, too. The most important ones are highlighted below, including time of last update, WP version compatibility, and PHP requirements. You know that if you’re running WordPress 4.9.5, this one has a potential — if unlikely — conflict with something else on your site.
And the repo does one more thing that you can really use to protect yourself. Whenever there’s a plugin update, the developers release a changelog to show everything that was addressed in the new version. It’s easily accessibly from your dashboard, too: Plugins -> Installed Plugins -> View version 6.3 details. A modal pop up with the changelog right there.
A bunch of people I know are intimidated by chagelogs and release notes. There’s no reason to be. They aren’t scary. Here’s a quick breakdown of what it can all mean so you can keep your WordPress site as safe and sound as you can.
5. Make Sure Your Plugins Will Continue to be Supported
Don’t take a chance on a plugin if you’ve never heard of it before. Maybe if there’s a recommendation from a friend or another trusted source, then you might be safe. Make sure there are enough reviews and recent updates, too. You will run across a lot of abandoned plugins on the repo, and that has led to thousands (if not millions) of WordPress plugin conflicts.
If you don’t know the developer will keep the plugin updated for a reasonable amount of time, it’s probably a good idea to steer clear.
Additionally, it’s a good idea to go do a plugin audit every now and again to make sure that none what you have installed are out-of-date. If they are, it’s time to do some research to find a replacement before conflicts start to happen. And they will.
Identifying Plugin Conflicts
Okay, so you have a conflict come up despite taking every preventative measure you could. It happens, and it’s terrible. But it’s not the end of the world. You just gotta stay calm to get all your upside downs turned rightside up again.
1. Use Some Plugins for Your Plugins
I know it sounds counter-intuitive, but you really can use some plugins to sniff out issues that may have arisen.
- Health Check is the pseudo-official plugin doctor.
- Plugin Organizer lets you disable and enable plugins on a page/URL basis, instead of the whole site. You can also swap loading order.
- Theme Test Drive is an ironic inclusion, because it hasn’t been updated in a while itself. But it comes highly recommended by WooCommerce, so there’s that. I’ve said it before, and I’ll say it again: if it’s good enough for WooCommerce, it’s good enough for me.
2. Swap Themes
As much as I am loathe to suggest that anyone ever step away from Divi or Extra for even a moment, you gotta do what you gotta do. By reverting back to one of the default WordPress themes (probably Twenty Seventeen), you will see immediately if there’s a conflict with a plugin and the theme you’re running. If you can’t access the WordPress dashboard to switch themes, you can change your theme by editing values in your database.
Additionally, if you find that there is an issue with your theme, you can try to rollback to a previous version of the theme.
3. Check Each Plugin’s Support Forums and Documentation
When something breaks on the internet, word travels fast. So you have two choices here, really. You can use Google, Bing, or DuckDuckGo to search for “[plugin name] plugin conflict”, or you can go down the list and hit the official and WP.org forums, docs, GitHub and WP repo pages for each one you’ve got installed.
You should be able to track down help for your problem (or find someone who already has).
4. Have You Tried Deactivating All the Plugins and Reactivating Them One by One?
I am ending on this section with the first advice you’re given for a reason. It is the most fool-proof way of fixing this issue. When you go from all plugins with a problem to no plugins and no problem, it’s pretty simple to see when the guilty party rears its nasty little head.
While this is the most surefire way to get things sorted, you have to basically shut down your site’s entire functionality. Keep in mind that while you will find out what the problem is, you won’t find out the underlying cause of the problem, nor find a solution to it (other than not using those two plugins together). You’ll probably need to look at one of the above options for that before moving forward.
Resolving Plugin Conflicts
Once you know which one of those little code goblins caused your site to break, it’s time to triage the damage and get things back to 100%. Heck, if your site goes totally kaput, even getting it back to 50% capacity is an admirable, short-term goal. Here’s how you can get started on the road to recovery.
1. Restore from a Pre-Crash Backup
The simplest way to fix WordPress plugin conflicts is to wipe the slate clean and start over. That doesn’t have to mean a fresh install running Twenty Seventeen; it can be a restore from a previous backup, one that you know works well enough to keep your site up and running until whatever fix you need can be implemented.
The main thing you need to make sure of, though, is to create regular backups. UpdraftPlus and Backup Buddy are well-known WordPress backup plugins that are amazing for this. You can see our full run-through of the backup/restore process, using UpdraftPlus or the old-fashioned way of phpMyAdmin.
2. Clear the Cache
Sometimes, even when you sort the problems out, implement all the fixes that work on your dev site, and think things are back to normal…they aren’t. The issues could persist because of a caching issue, either on the server side or the browser’s. Luckily, clearing caches is relatively quick and painless, and you should probably do it regardless of whether there are any apparent issues.
3. Debug the PHP and JavaScript Errors to Fix Manually
This one might not be for everyone. Let’s say that you really need what the plugin does for your site. That means backup restore isn’t a long-term solution, and you can’t find either a suitable replacement or an update from the developers, either.
That leaves you one option: dive in and fix the troublesome code yourself. WordPress is built just for this kind of situation. Over at the Codex, you can read a fantastic article called Debugging in WordPress that will get you started, and as you fall down the rabbit hole even further, there’s the JavaScript debugging article over that way, too.
Wrapping Up
Whew. That was intense, right? But that’s a good thing. After all that, you’re ready to tackle pretty much any problem that arises on your WordPress site. From plugin conflicts to theme issues (or some combination of the two), you should be able to identify and resolve them with as little hassle as possible.
But most importantly, you are now versed well enough in plugin conflict resolution to prevent those issues from happening in the first place. That’s what we want, too: for those WordPress plugin conflicts never to happen in the first place. So no matter what stage you are in –pre-, post-, or mid-crisis — you’re definitely ready to keep things running smoothly. And if they don’t…have you tried deactivating all the plugins and reactivating them one by one?
What are some of your habits at preventing or resolving plugin conflicts? Let’s share best practices in the comments!
Article thumbnail by Andrew Rybalko / shutterstock.com
If you encounter a issue with a plugin update you can always use the award winning plugin WP Rollback
What to do when I published ne wages in divi just to see blank page with navigation only on my website? What’s the most common triggering this?
I had a few wordpress issues that I thought were caused by plugin conflict. However, after many hours of testing, I found that increasing PHP limit solved many problems. So this is also something to watch.
That’s very true. I’ve had that myself, and in general, I try to adjust the memory limit when I do a new install, but usually it’s only at the prompting of a theme or plugin that says “Hey, buddy. I can’t work now.” But if the plugin doesn’t say anything, it’s unbelievably easy to miss and not think about. You know, like I did for this article, haha! 😉
Thanks for the reminder, Michel.
Hey, did you read the “1 ratings” for Health Check and Plugin Organizer? I don’t think I’d trust either of these. If you DID read them, then could you respond to the allegations? If you haven’t, will you, please? I’m not really qualified to accurately assess what’s being stated.
But either way, I’ll do the half&half method which I read about online a few months ago, so it’s out there and has been.
“disabling your plugins” always struck me as a WP version of “Disable your cookies.”
Hi Elegant team,
For peoples who want to work with a local wordpress website easely, I recommand Local By Flyweel.
Do you use this software ? What do you think about it ?
Thank, Ben.
I also recommend MAMP for working with a local WP site!
I really like Local, personally. I think there are some other members of the team who use it as well. The upsell isn’t too intrusive, and it kind of just works. I think it’s just simpler than using MAMP for me.
Local by Flywheel is a great option!
To disable all the plugins in just one step, if we can’t access the WP dashboard, we change the name of the folder by FTP. We just rename the folder located in the wp-content: “plugins” into “plugins2”. Doing this, we automatically disable all the plugins.
Many plugins like W3TC and others, need extra steps to complete the deactivation. You have to check wp_config and htaccess, and remove all plugins data or extra folders or files.
Very true. I’ve had a couple issues on personal sites with some caching plugins that I didn’t think about clearing first, and it did some totally wacky things that weren’t terribly fun to fix. Good tip — thanks for pointing that out!
The absolute best way to resolve is to have ET bring in more plugin functionality so we don’t have to use 3rd party.
Again! PLEASE have a Divi Store where plugins, layouts can be “verified” to work with Divi.
Great idea Richard.
Absolutely agree! I’m using the Extra with a couple of plugins recommended by ET. The irony is they messup with the Visual Builder so much, I can’t even use it..!
Have you tried it within the past few updates? We have made some really major improvements to the Visual Builder recently, and those conflicts might have been solved.
And to what Richard was saying, we’ve got a lot of stuff coming down the pipeline. Our releases that are coming up will keep adding a ton of functionality that y’all are wanting. We do really love the community of plugins and layouts that have sprung up around Divi, so that is something we take into consideration, too, as we make roadmaps for the future. 🙂
An alternative to turning all plugins off is a split half search. Disable the top half of the plugins on your plugin page, leaving the bottom enabled. Test to see if the issue is resolved. If not disable the bottom half while having the plugins at the top enabled again. Whichever half of enabled pliugins is the source of the problem do the split half search again on that half. So, a quarter of the installed plugins. Doing this will quickly weed out a potential candidate for the problem.
After reading the article though, this split half test may not be the silver bullet as it could be two plugins conflicting against each other, one in the top half of the plugins list and the other in the bottom. I guess further testing with another pattern of on/off plugins would be required at this stage.
That said, I have used the split half test on several occasions to great effect to resolve an issue quickly.
That’s a really good idea, though. I’ve never heard or thought of it, but I could definitely see how in a lot of cases, it would really help narrow down the issue pretty quickly.
I first heard the term about ten years ago as a recommended troubleshooting technique that Apple Service Provider technicians use.
Think about it, you can guess any number between 1 and 1,000,000 with only 16 questions of (higher or lower than this number?) I’m an old guy. It’s binary… I use to code pushing buttons and flipping switches to create machine code.
good thinking sir.