‘Disable every plugin’ can restore a page, but it destroys the conditions needed to identify which interaction failed. A useful conflict test keeps one baseline, changes one variable, and records the result.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you reproduce the failure, separate browser and server symptoms, and isolate the smallest plugin interaction without changing production blindly.
Read the failure at the right layer
- Two plugins hook the same request with incompatible assumptions.
- One plugin expects a different PHP, WordPress, database, or dependency version.
- Cached assets or generated files make a resolved conflict appear to persist.
The branches are ordered to protect the strongest evidence around this possibility: two plugins hook the same request with incompatible assumptions. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
An update changes code while production data and caches remain in place; a clean plugin ZIP does not reproduce the site unless PHP, WordPress, database schema, theme, must-use plugins, and generated assets are also comparable; in this guide, the practical goal is to reproduce the failure, separate browser and server symptoms, and isolate the smallest plugin interaction without changing production blindly.
Build a clean diagnostic record
- Write one reproducible path with expected and actual behavior, user role, browser, and timestamp.
- Capture the console, network response, PHP log, and active version list.
- Clone to staging and establish a baseline with the same data and cache state.
- Use binary isolation: disable half the suspected set, retest, and narrow the failing combination.
The sequence moves from observation toward intervention. Preserve the result of the final check—use binary isolation: disable half the suspected set, retest, and narrow the failing combination—because it provides a useful comparison after the repair.
Test one hypothesis without losing the baseline
Treat “Two plugins hook the same request with incompatible assumptions” as a working hypothesis, not a conclusion. Establish a baseline first: write one reproducible path with expected and actual behavior, user role, browser, and timestamp. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: update or roll back the responsible component only after reading its compatibility notes. A result that contradicts “Two plugins hook the same request with incompatible assumptions” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Repair the cause—not the message
- Update or roll back the responsible component only after reading its compatibility notes.
- Remove duplicate functionality so two plugins do not control the same cache, redirect, schema, or form.
- Report a minimal reproduction with logs and exact versions to the maintainer.
Before applying “Update or roll back the responsible component only after reading its compatibility notes,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can test the original path under each affected role and cache state; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Build a reversible plugin test matrix
On staging, record the active set, deactivate one suspected component, reproduce the exact path, and restore it before testing the next candidate.
wp plugin list --status=active --format=table
wp plugin deactivate suspected-plugin
# Reproduce one documented request here.
wp plugin activate suspected-pluginInterpretation and safety: Replace suspected-plugin with the verified slug. Keep caching and user role constant; changing several plugins at once destroys attribution.
Verification checklist
- Test the original path under each affected role and cache state.
- Re-enable unrelated plugins and confirm the failure does not return.
- Keep the staging reproduction until the production observation window ends.
One successful refresh is not closure. Keep the incident open until you can also re-enable unrelated plugins and confirm the failure does not return, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
For maintainer support, provide exact old/new versions, PHP and WordPress versions, the smallest reproduction, first relevant log or console error, and the result under a default theme or reduced plugin set; keep private data out of exported diagnostics; include the result of this first observation: write one reproducible path with expected and actual behavior, user role, browser, and timestamp.
State what was tested, including the result of “Write one reproducible path with expected and actual behavior, user role, browser, and timestamp,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Tempting moves to avoid
- Do not diagnose from plugin count; one plugin can fail and many can coexist.
- Do not test by editing vendor code in production.
Change record
Primary references
- WordPress debugging — official reference consulted for this guide.
- WordPress common errors — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Update or roll back the responsible component only after reading its compatibility notes”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.