Decide what kind of failure you have before touching anything
A conflict between plugins, or between a plugin and the theme, usually leaves the page loading but one feature wrong: a button that does nothing, a form that will not submit, a menu that will not open, a slider that never moves. That is different from a fatal error, where WordPress shows a critical-error notice or a blank page, and different again from a payment failure at checkout. The first question is therefore which of those you have, because each has a different safe first move.
- Write the failing action as steps another person can repeat, with the address of the page and what you expected.
- Note the time it last worked and every update or install since then.
- Open the browser console on the failing page and keep the red lines that name a file in a plugin or theme folder. Share the file name and message, not cookies or tokens.
- If you see a critical-error notice or a blank page, stop here: that failure has its own method and its own job.
Work on a copy, one change at a time
WordPress documents deactivating plugins one at a time as a way to find the one at fault, and its plugin guide says to take a current backup before updating. WooCommerce publishes the same method in more detail for its own sites: make a backup or a staging copy first, update everything, switch to a default theme, turn off everything except the components involved, then re-enable them one by one and repeat the failing action after each. The value of the method is the record, not the cleverness: after every change you write down what was active and whether the action worked, so the culprit is a row in a table rather than a hunch.
- Change one thing per run; two changes at once make a pass or fail meaningless.
- Repeat the failing action exactly the same way every run, and test it more than once, because an intermittent fault can look like a fix.
- If switching the theme fixes it, the theme is involved, but that does not mean the theme alone is at fault; a plugin may rely on markup the theme changed.
Remember what the plugin screen cannot switch off
Two kinds of code keep running when you deactivate ordinary plugins. Must-use plugins load automatically, do not appear in the normal list and are removed only by deleting their file. Hosts sometimes install caching or security drop-ins that behave the same way. WooCommerce warns that these can still cause a conflict and that a host-installed one may need your host to disable it. Caches matter too: its guide says to turn off browser caching while testing, because a cached page can hide the real cause or make a fix look as if it failed.
- Ask your host what is installed at server level before concluding that no plugin is responsible.
- Test in a private window as well as a normal one.
- Clear page caches after each change on a copy, and note which cache layers exist.
A word about troubleshooting-mode plugins
The Health Check plugin offers a troubleshooting mode that disables plugins and switches to a default theme for your user only, until you leave the mode or log out, so visitors are not affected. That is useful on a live site you cannot copy, but it is a convenience and not evidence. Its directory listing, read on 11 October 2026, showed the last release in July 2024 and a notice that it had not been tested with the latest three major WordPress releases. Treat it as a way to form a hypothesis, then confirm the result on a staging copy where you can record each run.
- Do not install extra tools on a production site to diagnose a problem you can reproduce on staging.
- A feature that is fine in troubleshooting mode but broken normally points to an active plugin or the theme, which narrows the table of runs.
What fixes it, what does not fit and how the paid job is accepted
When the culprit is found, the fix is usually small: a setting, the order scripts load, a template override placed in a child theme, or a plugin version that works. Sometimes two plugins that both must stay cannot coexist, and the honest answer is a trade-off. The paid job that follows this order starts from a published test price of GBP 245 and one failing feature, stays on a staging copy and is accepted only when the failing action passes three runs in a row, the console shows no new error and up to five neighbouring pages are unchanged. It does not cover fatal errors, shop checkout failures, slow pages or rebuilding a plugin.
- Send the steps, the plugin list as text and the console lines, never logins.
- The price is an untested proposal and payment follows the agreed checks and your sign-off.
Sources and limits
- WordPress documentation: Manage Plugins, troubleshooting Checked 2026-10-11.
- Back up before updating plugins; an error message may name the plugin file; deactivating plugins one at a time is a documented way to find a conflicting plugin.
- Must-use plugins do not appear in the default plugin list and can be removed only by deleting the file from the must-use folder.
- WooCommerce documentation: how to test for conflicts Checked 2026-10-11.
- The documented method is backup or staging first, a default theme, all plugins off except those involved, then re-enabling one at a time and testing after each.
- Host-installed drop-ins and must-use plugins can still cause conflicts when ordinary plugins are off; browser caching should be disabled while testing.
- Health Check & Troubleshooting plugin listing Checked 2026-10-11.
- Its troubleshooting mode disables plugins and uses a default theme only for the logged-in user until it is switched off or the user logs out.
- On 11 October 2026 the listing showed version 1.7.1 from July 2024 and a notice that it had not been tested with the latest three major WordPress releases.