Loupely Changelog
Every release, documented. What shipped, what changed, and why it matters.
9 releases
The triage engine: 30+ failure types, one specific next step
The triage engine shipped. After the diagnosis, Loupely routes you to one of 6 paths: rollback a plugin update, contact your hosting provider, contact the plugin developer, clear a cache, take a DIY admin action, or receive a null result with guidance. The route is chosen deterministically. For factual failures, the correct route is always knowable, so that's always what you get.
Every route includes pre-written messages you can copy and send. If the route is contact the plugin developer, Loupely writes the bug report. Two secondary options are always available regardless of route: hand the evidence to a developer, or pass the capture file to an AI tool.
What it answers
- what do I do after WordPress shows an error
- how do I know if I should rollback a WordPress plugin update
- how do I write a bug report for a WordPress plugin developer
- what do I say to my hosting provider when WordPress breaks
- is there a tool that tells me the next step after a WordPress error
Why we built it
Knowing what broke is only useful if you know what to do about it. The triage engine is what turns a diagnosis into an action.
Enhancements 6
- Triage engine shipped with 30+ failure types mapped to 6 deterministic routes: rollback, hosting provider, plugin developer, DIY admin, cache clear, and null result
- Pre-written messages generated for every triage route so users can copy and send a complete bug report or support request without writing it themselves
- Plugin name lookup table with 30 entries resolves raw plugin slugs into readable names for use in triage copy
- SMTP plugin detection identifies 5 common SMTP plugins and produces route-specific guidance for mail delivery failures
- Rollback route includes a file manager path for sites where WP-Admin plugin management is unavailable due to the fatal error
- Secondary options appended to every route: use an AI tool with the capture file, or hand the capture file to a developer
Cross-signal correlation: how Loupely connects browser errors to server causes
The correlation engine shipped. It runs 15 rules against the combined browser and server evidence to identify relationships between the two sides that are invisible when you look at either alone. A JavaScript error in the browser that coincides with a PHP fatal on the server isn't a coincidence. A form that submits without a JavaScript error but triggers a failed wp_mail call on the server isn't a frontend problem. A PHP error that started within 24 hours of a plugin update points somewhere specific. These are correlations, and they become the primary finding.
What it answers
- why does my WordPress site have a JavaScript error and a PHP error at the same time
- how do I find out if a plugin update broke my WordPress site
- why is my contact form not sending emails even though it submits fine
- how do I know if a WordPress error is caused by the browser or the server
- is there a tool that connects browser and server WordPress errors together
Why we built it
A diagnosis built on one side of the evidence is a guess. The correlation layer is what makes Loupely's output worth trusting.
Enhancements 6
- Cross-signal correlation engine shipped with 15 rules connecting browser errors to server causes
- Specificity scoring ranks correlated findings so the highest-confidence match becomes the primary finding
- CR-001 through CR-005 cover PHP error and network failure timing, sustained wp_mail failures, PHP fatal and browser script error pairing, plugin source matching, and post-update regressions
- CR-006 through CR-015 extend coverage to WooCommerce payment gateway failures, SMTP connectivity failures, disk space exhaustion, memory limit fatals, repeated login failures, max_input_vars form truncation, SSL certificate chain failures, database query overload, execution time limit fatals, and cron overdue detection
- Form type classification added to CR-002 so WooCommerce checkout failures are described accurately rather than as generic contact form failures
- Setup mode guard added to CR-005 so mass plugin activations during initial site setup don't produce false rollback recommendations
The Chrome extension ships: browser capture, credential scan, private mode, and magic link sign-in
The Loupely Chrome extension shipped its first release. 9 categories of browser evidence captured in 1 click: JavaScript errors, network failures, DOM state, browser storage, performance data, CSS state, pre-capture buffer, platform detection, and page builder detection. No DevTools. No mode switching.
The extension also shipped with a 60-second rolling pre-capture buffer, so errors that fire on page load and disappear before you click the icon are still captured. A credential scan runs before every download and redacts 10 categories of sensitive data before the file reaches your machine. Private mode strips the page URL from the capture file for anyone working on client sites or staging environments. Magic link authentication means no password to create, forget, or reset.
What it answers
- how do I capture JavaScript errors on my WordPress site without opening DevTools
- how do I capture a WordPress error that only happens on page load
- is it safe to share a WordPress debug file with a developer
- how do I capture a WordPress error without revealing the site URL
- how do I sign in to the Loupely Chrome extension
Why we built it
The browser and the server tell different parts of the same story. This release was the browser half: everything needed to capture, protect, and deliver evidence from the client side before a diagnosis can run.
Enhancements 10
- 9 browser capture modules built and passing: page context, JavaScript errors, network failures, DOM capture, browser storage, performance data, CSS state, pre-capture buffer, and platform detection
- 60-second pre-capture buffer runs silently in the background so errors that fired before you clicked the icon are included in the capture
- Credential scanner checks 10 named patterns before every download and redacts matches: Stripe secret keys, AWS access keys, JWTs, PEM blocks, MySQL connection strings, Mailchimp API keys, Google service account JSON, WordPress nonces, Stripe publishable keys, and generic secrets in fields labelled token, key, or password
- Private mode toggle strips the page URL from the capture file before assembly so client site URLs don't appear in the download
- Magic link authentication shipped: enter email, receive link, click, signed in with no password at any step
- Page builder dynamic class annotation added so Elementor, Divi, Bricks, Oxygen, and Beaver Builder class prefixes are flagged and don't get misread as plugin conflicts
- Fetch and XHR override injected into the page world so outgoing network requests are captured before they leave the browser
- SPA and AJAX navigation detection added via MutationObserver so captures on WooCommerce and page builder admin screens don't fire against stale DOM
- Conflict detection added for Sentry, Datadog, and New Relic so Loupely doesn't interfere with monitoring tools already running on the page
- CSP detection and graceful fallback built in: if a page security policy blocks page-world injection, the extension captures what it can and notes the limitation in the output file
The WordPress plugin captures server events in real time
The Loupely WordPress plugin shipped. It runs inside your WordPress installation and writes a timestamped record of server-side events to a local database table: PHP errors, fatal shutdowns, failed wp_mail calls, WooCommerce payment failures, hook conflicts, REST API errors, plugin updates and activations. Nothing is reconstructed after the fact. Everything is captured as it happens.
When the Chrome extension runs a capture, the plugin returns its records via a rate-limited, authenticated REST endpoint. That server evidence is one half of what Loupely reads. Without it, the diagnosis is guesswork.
What it answers
- how do I see PHP errors on my WordPress site without turning on debug mode
- why did my WooCommerce checkout fail with no error message
- how do I find out which plugin caused a WordPress error
- is there a tool that captures WordPress server errors automatically
- how do I get WordPress server logs without FTP or cPanel
Why we built it
The browser can't see a PHP fatal. It can't see a failed mail call or a WooCommerce payment that silently didn't go through. Without a server-side record, a diagnosis is guesswork. The plugin is what makes the guess go away.
Enhancements 9
- PHP error handler registered with chaining so Loupely doesn't conflict with other monitoring tools already on the site
- Fatal shutdown handler captures errors that kill the PHP process before normal error handling can fire
- Plugin source attribution identifies which plugin file an error came from, so the capture file names the cause not just the symptom
- Wp_mail failure capture logs every failed email send with recipient domain and error code — no email addresses stored
- WooCommerce order and payment failure capture fires conditionally, only when WooCommerce is active on the site
- Plugin update and activation events recorded so post-update regressions can be identified by the correlation engine
- REST endpoint registered at /loupely/v1/capture with Bearer token authentication and a 10-second rate limit between requests
- Events returned in priority order — fatals first, then errors, then warnings — capped at 500 rows to prevent oversized responses on high-traffic sites
- Admin settings panel added to WordPress dashboard for connection key display and management