After being up-to-date this is probably the second thing the support agent will ask you to do.
What is the use of a conflict test?
It will help you get closer to the source of the issue. You can find out whether the issue is actually with the plugin in question, is the issue caused by another conflicting plugin, the theme you are using, or maybe some custom code in the theme.
How does one do a conflict test?
It is fairly easy. It just means deactivating and activating plugins.
Where it gets complicated / time consuming is if you have a lot of plugins.
There are two ways to approach conflict testing: top-to-bottom or from the bottom up. I’m going to outline the bottom up approach, that is likely to give better, more reliable results.
- Switch to a default theme like twentyseventeen or twentynineteen.
- Deactivate all plugins, except for the one in question.
- Clear your cache.
- Check if the issue still exists.
- If the issue is still there, yeay, good chance it’s a bug with the plugin. Report your findings to support. (More on this coming up in Client Tip #4.)
If you cannot recreate the issue like that, then we start an iterative process.
- Activate …
- … your parent theme (and skip to step 2).
- … your child theme (and skip to step 2).
- … one plugin.
- Clear cache.
- Test.
- If the issue is still there, report it.
- If the issue is not there, go to step 1 and repeat.
Side note: if you have plugins that are interdependent – like WPML -, then you can activate them together.
Side note 2: if you have a LOT of plugins, then you can activate them in batches of 5. Once the issue kicks in deactivate the last 5 and go one-by-one.
It is fairly simple, right? And yes, it can be boring and time consuming, but it’s a sure way to find out if there is any conflict with another plugin.
So what happens when the issue appears after activating plugin X? There is probably a conflict between that plugin and the one in question. Finding this and reporting it will help support and the developers track down the issue and fix it.
One thing to note, if you are doing the conflict test on your live site, that will be visible to your visitors. If you don’t want that, and in any case, setting up a staging site is very much recommended. If you cannot set one up, then the next paragraph might provide an alternative.
Apart from conflict testing it is recommended to test any and all updates to your plugins and theme on a test / staging site, in order not to screw up your live site.
A bit of help with conflict testing
There is this very cool plugin called Health Check which can help you with the conflict testing process, especially if you cannot set up a test / staging site, or just want to quickly test something.
Health Check has a troubleshooting mode, if you switch that on you can do the above conflict test on your live site, and none of that will be visible to your visitors. They will still see the normal website, while you are running the test. It is a really great plugin I would recommend you to test it out.
But I would recommend setting up a staging site even more. 🙂
Word of advice
Don’t lie about whether you have done the conflict test. There are two main reasons for this.
Support will likely find out and how will that look? 🙂
But more importantly …
… if you say you did the conflict test, but in reality you did not, and you start the support exchange, you might end up running in circles and waste precious time because the source of the issue will be uncovered only later.
So if you didn’t do it, don’t sweat it, just be honest about it. And be prepared that support will ask you to do it. 😉
This year (2019) in September I participated at WordCamp Zürich in Switzerland. I applied with a talk about how a support exchange, and thus reaching a resolution can be made faster. And I thought it would make a great blog series.
This is the second set of tips for Clients in the Faster Support – For Both Sides series.
Leave a Reply