What the browser knows that your server doesn’t #
When something breaks on a WordPress site, the failure usually has 2 sides. The server side is what PHP did (or failed to do): the error that fired, the hook that didn’t run, the database write that didn’t complete. The browser side is what happened after the server responded: how JavaScript handled the response, what the DOM looked like when the error occurred, which network requests succeeded and which ones failed silently.
Most WordPress debugging tools only look at 1 side. They either read the PHP error log (server-only) or they ask you to describe what you saw on screen (browser-only, filtered through your interpretation). Loupely reads both. The browser capture layer is one half of that process.
What the browser capture collects #
When you click Run Diagnosis, the Loupely Chrome extension captures the following from your browser in real time:
- JavaScript errors: any errors that fired in the browser console during your session on that page, including uncaught exceptions, script load failures, and errors thrown by plugins or themes running in the browser.
- Network requests and responses: every HTTP request the page made and what came back, including failed AJAX calls, REST API requests returning unexpected status codes, and third-party script failures.
- DOM state: the current structure of the page at the moment of capture, including form states, rendered elements, and anything JavaScript has modified since the page loaded.
- Console output: any messages, warnings, or errors logged to the browser console by your plugins, theme, or page builder.
- Plugin conflicts visible in the browser: script collisions and namespace conflicts that show up as JavaScript errors before any PHP is involved.
Why browser-only isn’t enough #
A WooCommerce checkout failure looks identical in the browser whether the cause is a JavaScript error, a PHP fatal on the server, a failed database write, or a Payment Gateway timeout. The browser sees the same broken UI in all 4 cases. You can’t tell which one it is from the browser alone, and neither can Loupely without also reading the server.
That’s why the browser capture is always paired with the server capture when the WordPress Plugin is installed. The correlation between the 2 layers is where the actual diagnosis comes from. See Cross-Signal Correlation: What It Is and Why It Matters for how Loupely connects the signals.
Browser-only mode #
If you haven’t installed the WordPress Plugin yet, or if you’re using Loupely on a WordPress site where you can’t install the plugin (like a staging environment with restricted access), the extension will run in browser-only mode. You’ll still get the browser capture, and a diagnosis may still be possible if the cause is browser-side. But server-side failures (PHP Errors, Hook Execution problems, database issues) won’t be captured, and the diagnosis will be limited to what the browser can see. For most WordPress problems worth diagnosing, you want both layers. See Installing the Loupely WordPress Plugin to add the server layer.
The 60-second capture buffer #
The extension runs a rolling 60-second buffer of browser events in the background while you’re on a page. This means that when you click Run Diagnosis, you’re not just capturing what’s happening at that exact moment. You’re capturing everything that happened in the preceding 60 seconds, including the error that fired when you submitted the form, the network request that failed 30 seconds ago, and the JavaScript exception that preceded the visible failure. That buffer is what lets Loupely capture the failure even if you click the button a few seconds after it happened.