Skip to main content

Visual Feedback for Laravel

In-page feedback for Laravel applications. A reporter opens a widget on the page they are already looking at, describes what is wrong, and the report arrives with a screenshot of what they actually saw plus the context you need to reproduce it — URL, viewport, color scheme, browser, the state of the page.

The point is the gap it closes. A bug report that says "the button looks broken" costs a conversation; the same report with the reporter's own screen attached costs a glance.

What you get​

  • A Livewire widget in modal or inline mode, with a built-in floating button, a standalone trigger component, or a plain window event if you place your own.
  • Screenshot capture in two stages — the browser's own screen capture where it exists (pixel-exact), silently falling back to a DOM renderer that works everywhere, including iOS. The report records which stage produced the image, so you can tell an exact picture from a reconstruction.
  • Region redaction through a data attribute, effective in both capture stages: the region is blacked out and input values cleared before anything is captured.
  • Two view trees — a framework-free one that needs no build step, and a WireKit one you publish over it, which inherits your application's design tokens.
  • Delivery channels — mail, database and signed webhook, each isolated and individually queued, extensible with your own.
  • Abuse protection with no external service: a honeypot, a server-anchored time trap and rate limits, running underneath any additional gate you add rather than instead of it. The first two depend on nothing outside the request; the rate limits go through your cache, and what happens when that is down is a setting — see Abuse protection.
  • Seven bundled locales — de, en, es, fr, it, nl, pt — every string translated, in an informal register. The widget your users see is in their language without you writing a line of it, and a category you add is the only thing that needs a label of your own.
  • Built to WCAG 2.1 AA and proven rather than asserted — a full axe sweep over every widget state in both trees, a keyboard-only run through the whole flow, and contrast measured on the values the browser actually rendered.

Start here​

  • Installation — requirements, publish tags, and where the widget goes.
  • Configuration — every config key and its environment variable.
  • The capture cascade — the two stages, and how a report tells you which one produced its image.
  • Placing the trigger — the built-in button, your own, or the window event.
  • View trees — framework-free, or WireKit with your design tokens.

Then​

  • Delivery channels — mail, database, signed webhook, your own.
  • Abuse protection — the floor that always runs, and adding a gate.
  • Privacy and retention — the notice, and how long anything is kept.
  • Accessibility — what is proven, and the three things your page owes.
  • Integration contract — CORS, CSP, and what the DOM stage does not reproduce. Read this one before you trust a screenshot.
  • Testing — driving the widget from your own suite, and what the bundled suites already prove.

Where the detail lives​

The README is the showcase — one paragraph, the install line, and a feature list. Everything below this page is the detail it used to carry.