View Categories

The Server Capture Layer

3 min read

What lives on the server that the browser can’t see #

Your browser only sees what the server chose to send it. If a PHP error fires silently, if a WooCommerce hook doesn’t run, if a database write fails without producing a visible error message, if a scheduled task misfires in the background: none of that shows up in the browser. The page might look completely normal. The checkout might appear to process. The form might confirm submission. And none of it actually worked.

This is the gap that makes WordPress debugging so frustrating for non-technical site owners. The thing that broke is invisible to the tool you’re using to look at it. The server capture layer is how Loupely closes that gap.

What the server capture collects #

The Loupely WordPress Plugin runs on your server and captures the following when the Chrome extension requests a diagnosis:

  • PHP Errors and warnings: Fatal Errors, non-fatal warnings, notices, and deprecated notices that fired during the current request. These are the errors WordPress debug mode captures, but Loupely surfaces them without requiring you to enable debug mode or read the debug log manually.
  • Hook Execution data: which WordPress action and filter hooks ran, in what order, and whether any failed. Plugin conflicts often show up here before they produce a visible error.
  • WooCommerce Save Pipeline events: whether an order write completed, whether inventory was decremented, whether the Payment Gateway received a valid response, and where in the pipeline a failure occurred if one did.
  • REST API responses: the actual response your server sent to REST API requests, including status codes and error bodies that never make it to the browser in readable form.
  • Active plugin list and versions: which plugins are active at the time of capture, so a diagnosis can reference specific plugin conflicts by name and version.
  • WordPress version and server configuration details: PHP version, memory limit, and other environment data relevant to diagnosing compatibility issues.
  • wp_mail log: whether email dispatch attempts were made and whether they succeeded, for diagnosing Contact Form and WooCommerce Transactional Email failures.
  • Cron and scheduled task status: whether WordPress cron events are firing correctly, relevant for diagnosing failures in scheduled processes.

How the plugin communicates with the extension #

The plugin registers a secure REST API endpoint on your WordPress site. When you click Run Diagnosis in the Chrome extension, the extension authenticates with that endpoint using the connection key you set up during installation and requests the current server-side diagnostic data. The data is transmitted to Loupely’s servers alongside the browser capture for correlation and analysis. The endpoint only responds to authenticated requests from the extension, and all transmission happens over HTTPS.

What happens if the plugin isn’t installed #

Without the plugin, the server layer doesn’t exist. The extension operates in browser-only mode and captures what the browser can see. For problems that originate in the browser (JavaScript errors, script conflicts, rendering failures), a diagnosis is still possible. For problems that originate on the server (the majority of serious WordPress failures), you’ll get an incomplete picture at best. If you’re diagnosing something serious, especially anything involving WooCommerce, forms, authentication, or database writes, the plugin is not optional. See Installing the Loupely WordPress Plugin.