Loupely Changelog
Every release, documented. What shipped, what changed, and why it matters.
9 releases
Loupely: dead-site detection, upgrade prompts, and result state redesign
What this is
Version 0.10.4 shipped three features and a set of fixes. Dead-site detection was added: when a site returns a 405, 502, or any non-intentional failure response, Loupely now recognises the site as down, skips the diagnosis, shows a triage card with 4 next steps, and does not consume a credit. Two upgrade prompts were added for credits plan users: one in the no-credits state and one below the credit count in the confirming state, both linking to the pricing page.
The result state was redesigned to match the Lens visual language, with a route chip, a dark diagnosis block, and a triage shell card. A 5-message cycling sequence was added during diagnosis to give feedback while the capture is being processed. An amber notice was added to the confirming state and triage page when the plugin is not connected and the diagnosis is working from browser signals only.
What it answers
- does loupely use a credit when my site is completely down
- wordpress site down how do i know what to do next
- loupely extension stuck on diagnosing with no progress
- how do i upgrade from loupely credits to annual plan
- what does it mean when loupely says browser signals only
Why we built it
A fully dead site needs a different response than a broken-but-alive one. Consuming a credit on a 502 and returning no useful diagnosis would have been the first thing a real user complained about.
Enhancements 6
- Dead-site triage card added: when site_appears_down fires, the confirming state shows "Your site appears to be down" with 4 recovery steps and no credit consumed
- Upgrade button added to the no_credits state: reads "Upgrade for unlimited" and opens useloupely.com/pricing in a new tab
- Upgrade link added to the confirming state below the credit count, visible to credits plan users only, linking to useloupely.com/pricing
- 5-message diagnosing sequence added: cycles through "Something happened here," "Retracing the last steps," "Getting the full story," "Piecing it back together," and "Finding who broke what" during diagnosis, clearing on response
- Result state redesigned to match Lens visual language: route chip, dark diagnosis block, and triage shell card
- Amber browser-only notice added to the confirming state and triage page when the plugin is not connected
Bug Fixes 4
- SiteAppearsDown detection expanded to fire on any non-intentional failure response, not only timeouts
- Confirming state credit line now reads "No credit used" when site_appears_down is true
- Authentication_failure deprioritised in analysis.js: it only surfaces as the primary finding when no higher-priority finding exists
- Authentication_failure triage route changed from hosting_provider to diy_admin with Wordfence-specific steps and Wordfence-aware branching in diagnose.ts
Loupely fixes pre-existing error misdiagnosis
What this is
Version 0.10.3 fixed a diagnosis accuracy bug. If a site already had errors before a plugin update, Loupely was reading those pre-existing errors as post-update regression and producing an incorrect diagnosis. The CR-005 guard was added to suppress pre-existing errors from that comparison. The diagnostics page was also rebuilt after loupely-diagnostics.js was found corrupted, with every button rewired cleanly from scratch.
What it answers
- why is loupely diagnosing errors that were already there before the update
- wordpress diagnostic tool misreading pre-existing php errors
- loupely core giving wrong diagnosis after plugin update
- how does loupely tell the difference between old and new errors
- wordpress plugin update regression detection how it works
Why we built it
A diagnosis that blames a plugin update for errors that were already there before the update is worse than no diagnosis. The guard makes the regression detection honest.
Enhancements 1
- CR-005 regression test added to the diagnostics page to confirm the pre-existing error guard holds across future builds
Bug Fixes 2
- CR-005 C-004 guard added: pre-existing PHP errors are no longer included in post-update regression comparison, preventing false-positive regression diagnoses
- Loupely-diagnostics.js rebuilt from scratch after corruption was found: every button is now wired exactly once with no duplicate handlers
Loupely ships: full capture pipeline, diagnosis, triage page, and feedback form
What this is
Loupely now does the complete job. You install the Chrome extension and the WordPress plugin, navigate to the broken page, and click the icon. Loupely reads both the browser and the server at the same time, tells you in normal human terms what broke, and opens a full triage page with your exact next step.
The triage page shows the diagnosis, the route (contact your host, roll back the plugin, clear your cache, contact the plugin developer, or fix a setting yourself), and a pre-written message you can paste directly into a support ticket. For plugin errors, it links to the correct support page for that specific plugin automatically. No searching, no copy-pasting error codes, no describing symptoms to a developer who wasn't there.
If the diagnosis is wrong, you can flag it from the bottom of the triage page. Select the reason, add a note if you want, and submit. Your credit is refunded.
This release was validated on a live WooCommerce site running 21 active plugins on real hosting. Loupely found a recurring PHP error in the Dokan Lite plugin that the site owner didn't know was there, named the file and line number, and linked directly to Dokan's support forum.
What it answers
- how do i find out what broke on my wordpress site
- how do i diagnose a wordpress error without a developer
- what do i do when my woocommerce site stops working
- how do i contact a plugin developer about a php error
- what causes recurring php errors in wordpress
Why we built it
A diagnosis without a next step leaves you in the same place you started. The triage page closes that gap: the diagnosis tells you what broke, the triage tells you exactly what to do about it, and the pre-written message means you don't have to figure out how to describe a PHP error to someone who can fix it.
Enhancements 10
- Capture pipeline decoupled from diagnosis: the extension captures browser and server evidence first, then waits for you to choose whether to diagnose or download the capture file free
- Diagnosis runs from the popup: clicking Diagnose this calls the Loupely server directly from the extension, returns a plain-language diagnosis in 1 to 3 seconds, and persists the result across popup close so a paid diagnosis is never lost
- Server-side triage: the triage engine runs on the server alongside the diagnosis and returns the complete result in one call. The route is stored in the session record for data moat analysis
- Triage page: a full-page result view opens in a new tab showing the diagnosis, the route card with numbered steps, a pre-written support message, and secondary options (AI tool handoff, developer handoff)
- Plugin support URLs: the triage page links directly to the correct support page for the identified plugin. Premium plugins go to their paid support portals. Free plugins go to their wordpress.org support forum
- Feedback form: a collapsible form at the bottom of the triage page lets you flag a wrong diagnosis, select a structured reason, and submit for a credit refund. The submission fires a notification to the Loupely team
- Diagnosis-included download: after diagnosing, the capture file download includes the diagnosis and triage route alongside the raw browser and server evidence
- Restore on reopen: if you close the popup after diagnosing, reopening it within 30 minutes restores the result view instead of starting over
- Capture speed: browser capture modules now run in parallel, cutting capture time significantly
- Post-update refresh notice: when the extension updates, the popup shows a hard-refresh instruction before allowing a new capture, preventing orphaned content scripts from producing bad results
The full engine pipeline is proven end-to-end on a real site
On a local WordPress site with the plugin installed and a deliberate error triggered, the full pipeline ran from start to finish: browser capture, server fetch, cross-signal correlation, local analysis, AI diagnosis, triage routing, output file assembly, and credit decrement. Correlation rule CR-014 fired. The analysis produced a real primary finding. The AI returned a real diagnosis sentence. A credit was consumed. Triage produced a full route with next steps.
This is the moment the product stopped being a collection of components and became something that works.
What it answers
- does Loupely actually work
- has Loupely been tested on a real WordPress site
- how do I know the WordPress diagnosis is accurate
- what does a Loupely diagnosis actually look like
- is Loupely ready to use
Why we built it
Every component was proven individually. This stage proved they work together. Nothing ships until the full chain runs cleanly on a real site with a real error.
Enhancements 5
- Full engine pipeline proven end-to-end on a real WordPress site: browser capture, server fetch, correlation, analysis, AI diagnosis, triage routing, output file assembly, and credit decrement all ran in sequence
- Diagnosis helpers added to content.js for token refresh-exchange and direct diagnose Edge Function calls from the extension content script context
- Capture relay added so content.js writes capture results to extension storage and the popup reads from it, decoupling capture from diagnosis
- Popup confirming state added showing the primary finding and three options: cancel, free download, or diagnose this
- Plan-aware credit display added to confirming state: annual plan holders see included in your plan, credit users see uses 1 credit and remaining balance
Bug Fixes 3
- Plugin envelope unwrap corrected so serverData.events and serverData.active_plugins reach the correlation and analysis engines correctly
- Module-scoped auth functions made accessible to content script context after confirmed undefined errors when called outside the extension popup
- Chrome.tabs API calls removed from content.js after confirmed unavailability in content script execution context
Credits and payment: proven end-to-end in test mode
The full payment infrastructure shipped and was proven end-to-end in test mode. Credit packs ($19 for 10 diagnoses, $29 for 20), annual plans (Loupely Annual $99/year, Bundle $149/year, Agency $499/year, Lens Annual $49/year), and the Stripe webhook that handles purchases, renewals, cancellations, and plan changes are all working. Credits are shared across Loupely and Loupely Lens and never expire. On every subscription purchase, a license key is generated, stored, and emailed from hello@useloupely.com. Stripe is in test/sandbox mode. Payment goes live at launch.
What it answers
- how much does it cost to diagnose a WordPress error
- is there a pay-per-use WordPress debugging tool
- does Loupely have an annual plan
- do WordPress diagnosis credits expire
- what's included in the Loupely agency plan
Why we built it
The payment layer had to be proven before the product could launch. Every path — credit purchase, subscription, renewal, cancellation, license key delivery — was tested against real Stripe sandbox events before moving on.
Enhancements 6
- Credit pack purchases proven: sandbox test card payment returned webhook 200 and balance incremented correctly
- Annual subscription purchases proven: plan activated, license key generated in LPY-XXXX-XXXX-XXXX format, and key emailed from hello@useloupely.com via Resend
- Webhook handles all four Stripe events: checkout.session.completed, invoice.paid, customer.subscription.deleted, and customer.subscription.updated
- Idempotency protection added via processed_webhook_events table so duplicate Stripe event delivery never results in duplicate credits or plan changes
- Credits shared across Loupely and Loupely Lens from a single pool and never expire
- Plan check in diagnose.ts correctly grants unlimited diagnoses to annual plan holders and charges credits to pay-per-use users
Bug Fixes 2
- Add_credits RPC corrected to 2-argument signature after confirmed mismatch with deployed Supabase function caused silent purchase failures
- RESEND_API_KEY secret replaced after confirmed invalid value was causing license key email sends to fail silently with a 401 response