Blog
WordPress plugin conflict testing — a developer's guide
How to systematically test WordPress plugin conflicts across PHP versions, themes, and popular plugins — without guessing from support tickets.
Plugin conflicts are compatibility bugs with bad branding. Treat them like a testable matrix, not a mystery.
Define the conflict surface
Conflicts appear when two plugins:
- Register incompatible hooks on the same action
- Load assets in an order your code did not expect
- Assume they are the only plugin customizing checkout, REST routes, or admin menus
List the plugins and themes your users actually run — not the minimal set on your dev machine.
Build a combination grid
A useful grid crosses PHP versions, the current and previous supported WordPress releases, themes, and co-installed plugins. Each selected combination is an environment run; the scan is the job and report that groups those runs. Skip the grid and you will fix symptoms one ticket at a time.
Capture multiple signal types
PHP fatals from debug.log are table stakes. Also capture:
- JavaScript console errors on admin and frontend
- Screenshots of broken layouts
- WP-CLI activation status
Prioritize by impact
Not every failure deserves the same urgency. Combine the report's impact estimate with your own support commitments and customer context before ordering fixes.
Run the matrix automatically
Manual reproduction does not scale across releases. Folt can expand a scan into the current 216-run full matrix or a smaller selection and return a structured report. The Free plan includes 100 runs per month, so it cannot launch the full matrix.
Compare approaches in Folt vs manual VM testing.