Investigate a suspected plugin conflict on staging or through a supported session-isolated troubleshooting mode. Avoid deactivating every plugin on a busy live site while visitors rely on forms, checkout or account features.
IN THIS ARTICLE
01 Prepare a reproducible test
Write the exact steps and expected result, and record the plugin, theme and WordPress versions. Create a suitable backup and a representative staging copy when the failure involves public or transactional behaviour.
Disable or sandbox external effects on staging, including outgoing customer email, payments and webhooks. A copied site can still contact real systems if its integrations remain live.
02 Use the appropriate isolation method
- Prefer staging when the test changes persistent settings or must reproduce a visitor workflow.
- If using the Health Check and Troubleshooting plugin, review its current documentation and enter its troubleshooting mode through the supported interface.
- Confirm the mode's scope and compare the affected action with a minimal relevant component set.
- Enable suspected components one at a time or in a deliberate grouped comparison, recording when the failure returns.
- Keep required dependencies together so a missing dependency is not mistaken for a conflict.
Does troubleshooting mode isolate every side effect?
A troubleshooting mode can alter which plugins or theme load for your session without changing ordinary visitors' view. It does not make every action you take harmless: saving settings, submitting forms or running business operations can still affect stored data or external services.
An authenticated test may also fail to reproduce a problem that occurs only for anonymous visitors or scheduled jobs. Use staging or another appropriate diagnostic route for those contexts.
03 Verify the minimal conflict
Repeat the failing steps with and without the suspected combination. Record the exact versions and error, then consult the relevant developers for a supported correction. Do not conclude that the last plugin enabled is solely responsible without checking its dependency and interaction.
After testing, exit troubleshooting mode, remove temporary diagnostic changes and verify normal site behaviour. If a plugin must remain disabled, document which customer-facing features are affected and provide a deliberate replacement or communication plan.
04 Share actionable evidence
Provide support with the smallest reproducible component combination, test steps and sanitised logs. Avoid sending a whole live database when a clear staged example is enough. A good conflict investigation identifies the interaction and preserves normal service while the correction is developed.