Bug tracking for WordPress — session replay, console + HAR (2026)

A WordPress page is rarely one team's code. It runs a theme plus a dozen independently-authored plugins, and as of June 2026 WordPress powers 41.9% of all websites and 59.4% of the known CMS market (W3Techs), so the front end you are debugging is a stack of third-party scripts that have never been tested together. When one of them throws a console error, the visible symptom (a broken slider, a checkout button that does nothing, a form that won't submit) tells you almost nothing about which of those scripts failed. The default and usually correct hypothesis is "it's a plugin" — Patchstack logged 7,966 new ecosystem vulnerabilities in 2024, up 34% year over year, overwhelmingly in third-party plugins rather than core — but knowing that does not tell you which plugin, and that is the expensive part.

The official isolation tool, Health Check & Troubleshooting, has a sharp edge that makes production debugging slow: its Troubleshooting Mode deactivates plugins and loads a default theme for your logged-in admin session ONLY, while live visitors keep seeing the normal site. So you flip plugins off and on for yourself, refresh, and try to remember the exact interaction a real user took to trigger the bug. Layer on the jQuery problem — jquery-migrate has been disabled by default since WordPress 5.5, and the 5.6 jQuery upgrade promoted many deprecated calls from silent warnings to hard console errors — and any plugin still calling removed APIs now breaks loudly in the browser. This guide is for WordPress teams debugging front-end plugin and theme conflicts: what these failures look like in the console, and how to capture the one session that reproduces them so you stop guessing which interaction to repeat.

Framework-specific failure modes engineers actually ship through. Each is hard to spot in a screenshot and obvious in a session replay.

Real WordPress bug patterns — the symptom you will see in a report and the fix that actually works.

Plugin feature silently dies with 'X is not a function' after a core or plugin update

Symptom: A slider, lightbox, or AJAX add-to-cart stops working. The console shows 'TypeError: $(...).someMethod is not a function' or 'jQuery.fn.X is not a function'. Nothing visibly errors on the page itself.

Fix: A script is calling a jQuery method that no longer exists (removed in jQuery 3.x) or that belonged to a plugin loaded in the wrong order. Read the console error: it names the failing script URL, which points at the responsible plugin. To confirm which plugin, enable the official jQuery Migrate Helper, which re-enables the shim and logs each deprecated call so you can pin the breakage to a specific file rather than to WordPress core.

Two plugins each load their own jQuery and one breaks intermittently

Symptom: A feature works on some pages and fails on others, or works until a caching plugin is enabled. Console shows a 'is not a function' error that appears and disappears depending on which page or cache state loaded.

Fix: Two plugins are enqueuing rival copies of jQuery (or jQuery UI) outside the dependency system, so load order decides which one wins. Open the network waterfall and look for the same library requested twice from two different paths. The fix is to deregister the duplicate and declare 'jquery' as a registered dependency so WordPress loads it once; capturing the HAR proves the double-load before you start editing functions.php.

A console error reproduces for visitors but not in Troubleshooting Mode

Symptom: You enable Health Check Troubleshooting Mode, reactivate plugins one at a time, and cannot make the error reappear — yet real users keep reporting the broken interaction.

Fix: Troubleshooting Mode runs in your admin session with a default theme; the bug may depend on the production theme, a logged-out state, or a specific user action you are not reproducing. Capture the actual failing session (the DOM at the failure instant, the console stack trace, and the network requests) from the user's browser, then use that exact sequence as your script for the one-plugin-at-a-time isolation. You stop guessing which interaction to repeat.

The honest comparison — where BugMojo wins, and where another tool might serve you better.