When supporting WordPress users, there’s two key things to keep in mind.

The first one is simple: Believe that everyone has good intentions until proven otherwise, language barriers are hard.

The second one is not as simple, in the words of the wise Dr. House: Everybody lies.

This isn’t due to malicious intent on their end, it may not even be intentional. It’s merely that the troubleshooting approach, the one that just works, is to disable all your plugins and theme. It’s understandable that users will try to avoid this step in any way possible.

Their website may be their livelihood, they can’t just start messing with it, they may be unfamiliar with tools such as staging sites, local installs and so fort that many will say is the best way to do this, or they’re just not able to replicate problems outside of a production environment.

This was the problem I wanted to tackle during Contributor Day at WordCamp US (WCUS) in 2017.

Shortly before the event, I had been given control of an old, and now more or less abandoned, plugin called Health Check. The plugin had originally been used to test for compatibility issues before WordPress 3.2 did a minimum versions bump for PHP and MySQL.

The plugin would be some sort of an official plugin by the support team which gets actively promoted in the support forums.

So the plugin began. First as a way to introduce a debug information page, as proposed for WordPress core in ticket #39165 (and later in ticket #46573), it could give us information about a site so we could more easily identify problems.

This was good, we now had a starting point, the original plugin had also been experimenting with showing some information about versions to the user, this seemed helpful, so we built on that.

The plugin got more checks, relevant to features in WordPress, best practice recommendations, all with a simple three tier system: Good, recommended, and critical. Users could now look and identify potential problems with their site on their own, and this feature continues to evolve.

---

That was useful, we could judge the interest in debug information, users could check for common configuration issues, but it didn’t address the harder to reach issues of identifying conflicts in plugins, which kept poking at the back of my mind.

So while talking with folks at WCUS, I always kept half an eye on the prize, and eventually came up with an approach that I felt would fit well into our “official support tool”, and decided that I would spend contributor day working on it.

It took the full day of working, but by the end of the event, version 0.6.0 of the plugin was released, introducing the feature to the world.

Now any site maintainer could simulate a plain WordPress setup, with no plugins active, and enable them one by one to find out which one caused the conflict they were seeing.

Since then, Troubleshooting Mode has evolved a bit, it now also covers themes, and it even tries to identify potential fatal issues when plugins or themes depend on each other internally.