- What is pushery/visual-feedback-for-laravel and what does it do?
- It is a Composer package that adds an in-page feedback widget to a Laravel application so users can send feedback without leaving the page they are on. When a report is submitted, the widget captures a screenshot of the page in the browser (client-side) and sends it along with the written message. That gives you visual context for bug reports and UI issues instead of a vague text description. It is built for Laravel and Livewire views.
- How do I install pushery/visual-feedback-for-laravel?
- Pull it in with composer require pushery/visual-feedback-for-laravel and then follow the setup steps in the GitHub README. Those steps typically involve publishing the package config or front-end assets with artisan vendor:publish and rendering the widget in your main Blade layout. Because publish tags and provider registration can change between releases, always confirm the exact instructions for the version you installed rather than copying commands from older blog posts.
- Does this package work with Livewire components?
- Yes. The package is described as targeting Laravel and Livewire, so the widget can be rendered inside your Blade layout and will appear on pages that Livewire renders or morphs. Since the screenshot is taken in the browser at submit time, it captures whatever the DOM currently shows, including Livewire-driven state. If you use full-page Livewire components or wire:navigate, test that the widget re-initialises correctly after navigation.
- How does the screenshot capture actually work?
- The capture happens entirely in JavaScript in the user's browser, not on your server, so there is no headless browser or screenshot service in the loop. The widget serialises the visible page into an image and submits it with the feedback payload. This keeps latency low and avoids server-side rendering costs, but it also means the capture only reflects what the client rendered, so browser-specific quirks and scrolled-out content may not appear.
- Does it send my data to a third-party service?
- The description only mentions client-side capture inside your Laravel app, with no external screenshot API or hosted dashboard implied. In practice you should verify this yourself by checking the package config and the network requests the widget makes in devtools. If your compliance requirements forbid outbound calls, inspect the published JavaScript before shipping it to production.
- Which Laravel and PHP versions are supported?
- The supported version range is defined by the require constraints in the package's composer.json, so check that file or the Packagist page before installing. Composer will tell you immediately if your installed Laravel or PHP version conflicts with the package. If you are on an older Laravel release, confirm compatibility rather than assuming it works, and pin the package version you tested.
- Where are feedback submissions and screenshots stored?
- Storage is controlled by the package configuration, so publish the config file and review the configured disk, route, and model before going live. Screenshots are usually persisted as files on a Laravel filesystem disk with the text feedback and metadata stored alongside. Make sure the configured disk has the right permissions and retention policy, since screenshot files can accumulate quickly.
- Can I customise the widget or limit who sees it?
- Most widgets of this kind expose positioning, styling, and copy through the published config or Blade views, so check what is publishable in your version. You can also guard the widget with a Blade @auth or environment check so it only renders for internal testers, beta users, or non-production environments. That is the simplest way to keep it out of the way of anonymous visitors on a public site.
- Are there privacy or production concerns with client-side screenshots?
- Yes, and they matter. A screenshot captures exactly what the user sees, which may include personal data, tokens, addresses, or internal admin content, so you need a retention policy and a clear consent notice. Consider limiting the widget to authenticated users or staff, masking sensitive fields before capture if the package supports it, and storing screenshots on a private disk rather than a public one. Also check the payload size, because base64 images can make submissions large.
- How should I test it, and what are the alternatives?
- Submit a feedback item in a staging environment and inspect the request in devtools, then confirm the file landed on the expected disk and the database row contains what you need. For automated coverage, assert that the submission endpoint validates input and persists the record, and stub the image payload rather than sending a real screenshot in tests. If you need a hosted triage dashboard, session replay, or issue-tracker sync, commercial tools like Marker.io or Usersnap cover that ground; this package suits teams that want the widget and storage to stay inside their own Laravel app.