Laravel Kustomer Laravel Package

Getting Started

Treat this as a small, single-purpose package: it gives you a feedback widget (a floating trigger + form) that posts to a route the package registers, persists submissions, and leaves hooks for you to extend the fields and the handling. It is not a full support-desk or CRM — plan to own the admin/reporting layer yourself.

Minimal path:

1. composer require mydnic/laravel-kustomer
2. Publish the package assets (config, migrations, and any front-end assets). The README is the source of truth for the exact provider/command names — expect the usual php artisan vendor:publish --provider="Mydnic\Kustomer\KustomerServiceProvider" shape, with tags for config, migrations, and assets.
3. php artisan migrate to create the feedback storage table.
4. Include the widget in your layout — typically a Blade component/directive or @include of a published view, placed just before </body> in resources/views/layouts/app.blade.php.
5. Load the page and submit one piece of feedback end-to-end before customizing anything.

First real use case: drop the widget into your authenticated app layout, submit a test row, confirm it lands in the database table, then wire a notification or admin screen. That whole loop should take under fifteen minutes — if it doesn't, stop and check asset publishing and route registration before going further.

Because the package is small and the star count is modest, read the actual source in vendor/mydnic/laravel-kustomer rather than relying on the README alone. It's a few files; you'll know the full surface area in ten minutes, and that knowledge pays off for every customization below.

Implementation Patterns

Layout-scoped inclusion, route-scoped visibility. Put the widget include in a shared layout, then gate it with your own Blade conditional (e.g. only for authenticated users, only outside admin routes, only when config('kustomer.enabled')). Avoid editing the package view directly — publish it and override, or wrap the include.

Custom fields via the published view + extension points. If you need more than a message box (category, severity, page URL, screenshot), publish the widget view and add fields, then capture the extra payload in whatever callback/event the package exposes. Where the package doesn't offer a formal hook, subclass or bind your own implementation in a service provider — that's the "extensible" part, and it's usually cleaner than forking.

Associate feedback with context automatically. The highest-value pattern is attaching the submitting user, tenant, and current URL server-side rather than trusting hidden form inputs. If the package's model is overridable, extend it and add user_id/tenant_id; otherwise add a small listener on the submission event that enriches the record. This turns raw feedback into something you can triage.

Fan out on submission. Subscribe to the package's event (or override the handling) to: notify a Slack channel, dispatch a queued job, create a ticket in your issue tracker, or write to an audit log. Keep this in listeners/jobs — never in the package's controller path — so a Slack outage doesn't break the widget for users.

Admin surface. Build a simple resource (Filament/Nova/plain controller) over the feedback table: list, filter by date/tenant, mark resolved. Don't wait for the package to ship one.

Front-end integration tips. Keep the widget's CSS scoped so it doesn't collide with your design system; if you're on Livewire or Inertia, verify the widget's POST works under your stack (Inertia pages need the plain-HTTP route to be reachable outside the Inertia middleware, or you write your own submission handler).

Gotchas and Tips

• Verify Laravel version compatibility explicitly. With 418 stars and a low health score, the package may lag current Laravel majors. Check composer.json constraints and the release history before adopting; if it's stale, pin your Laravel version or be prepared to patch a illuminate/support constraint in a fork.
• The release date metadata looks anomalous (a future-dated release). Don't read "recent release" as "actively maintained" — check the commit log and open issues.
• Config caching bites. After changing published config, run php artisan config:clear; after changing published views/assets, clear the view cache and re-run your asset build. Most "my changes don't show up" reports are this.
• Asset publishing is the usual first failure. A missing JS/CSS publish means the trigger never renders or the POST 404s. Confirm the published files exist under public/vendor/... and that your layout actually loads them.
• CSRF and auth middleware. The submission route is web-facing; if you move it behind auth, unauthenticated users lose the widget. If you expose it publicly, add rate limiting and honeypot/validation — a public feedback endpoint attracts spam quickly.
• Multi-tenancy. Default migrations rarely include a tenant column. Add it in your own migration and enforce scoping in the model/global scope, or you'll leak feedback across tenants in the admin view.
• GDPR/privacy. Feedback text is user-generated PII. Decide retention up front and add a purge command or scheduled job; also make sure the widget doesn't silently capture IP/URL if your privacy policy doesn't cover it.
• Don't fork for small changes. Prefer publishing views/config and binding overrides in a service provider. Fork only if the package is genuinely unmaintained and you need framework compatibility fixes — and if you do, note it in your dependency docs so the next developer knows.
• Debugging tip: submit a form with the network tab open and check the response body first. The package's failure modes (validation, CSRF, missing table) all surface there faster than in logs.