Laravel Simple Feedback Form Laravel Package

Getting Started

composer require clevyr/laravel-simple-feedback-form:^2.0
php artisan vendor:publish --provider="Clevyr\Feedback\FeedbackServiceProvider"
php artisan migrate

Publish tags vary between releases — if the tagged publish returns nothing, run php artisan vendor:publish interactively and pick the package's group rather than guessing tag names.

Look here first, in this order:

1. config/feedback.php — this is where 90% of day-to-day work happens: recipient address, whether submissions are persisted to the database, mail vs. storage mode, middleware applied to the POST route, and any rate-limit/throttle settings.
2. The published migration in database/migrations/*feedback* — confirms the table name and column set before you write queries or a Filament/Nova resource against it.
3. The package's routes/ file — php artisan route:list | grep -i feedback gives you the actual URI and route names; the form posts to it directly, so any middleware change is a route change.
4. The published Blade views — copy them into resources/views/vendor/... and edit rather than styling around the package markup.

First use case: drop the form into resources/views/layouts/app.blade.php just before </body>, set MAIL_MAILER=log, submit one message from the browser, then confirm both the log entry and the feedback table row. That single pass validates the config, the migration, the route middleware (CSRF/session), and mail wiring at once — four things that fail independently and all present as "the form doesn't work."

Implementation Patterns

Layout injection over per-page includes. The package is designed as a site-wide affordance. Put the include in your base layout so every authenticated page gets it; gate visibility with @auth/@can in the layout rather than duplicating the include per view.

Override, don't fight. Publish the views and the config into your app, then restyle the markup against your design system (Tailwind classes, a modal component, etc.). Editing vendor/ is lost on the next composer update; published views and config are yours.

Guard the endpoint. A public POST route that writes to the database and sends mail is a spam target. Wrap it in throttle:5,1 (via the config's middleware key if present, otherwise by overriding the route registration), add auth middleware if the form is for logged-in users only, and consider a honeypot field if the package doesn't ship one.

Attribute submissions to a user. Add a follow-up migration with user_id/team_id and populate it from a model event or a small custom controller extending the package's. This is what turns the package from a mail forwarder into a queryable support queue.

Fan out to multiple destinations. If the package emits an event on submission, listen for it and notify Slack, create a Linear/GitHub issue, or dispatch a job. If it doesn't, the mailable/notification class is usually swappable through config or a container binding — check the service provider's bindings before forking the controller.

Queue the mail. If sending happens inline, the submitter waits on SMTP. Make the mailable/notification ShouldQueue and ensure a worker is running; in local dev keep it sync so failures surface immediately.

Testing. Post to the route in a feature test and assert both sides: assertDatabaseHas('feedback', [...]) plus Mail::assertSent(...). Use Mail::fake() so the suite doesn't need a mailer. Test the throttle and validation-failure paths explicitly — they're the two that regress silently.

Admin surface. With rows in the database, a read-only Filament resource or a simple paginated route over the Feedback model is a half-hour job and usually replaces the email entirely.

Gotchas and Tips

v2.0.0 is a Laravel 12 compatibility bump — treat it as breaking. A major version bump for a support-matrix change means Laravel 11 and below are almost certainly off the table. The changelog only lists a CI commit, which means the actual constraint change lives in composer.json. Before upgrading: read the require block on the v2 tag, run composer why-not clevyr/laravel-simple-feedback-form 2.0, and pin ^1.0 on any app still on Laravel 11. Diff composer.json between v1.0.0 and v2.0.0 — that diff is the breaking-change list.

Published config silently goes stale. Composer never touches files in config/. After upgrading, diff your published copy against vendor/clevyr/laravel-simple-feedback-form/config/feedback.php — new keys default to whatever the package's internal fallback is, which is frequently null or false and disables a feature you thought was on.

Same for migrations. If you edited the published migration (added user_id, changed an index), re-publishing won't update it and migrate:fresh in tests will diverge from production. Add new migrations for your changes; never edit a published one after it's shipped.

Config cache. php artisan config:clear after any config edit, and remember config:cache in deploy means a env() call added to the published config outside a config() context will silently return null.

419 and 429 look identical to users. A CSRF/session failure (419) and a throttle rejection (429) both render as "form didn't work." Check storage/logs/laravel.log and the network tab's status code before touching the package — and make sure the form is inside the session-middleware group if you customized the route.

Livewire vs. plain Blade. Whether the form is a Livewire component or a standard POST changes everything about error display, validation handling, and how you add JS. Confirm before writing any Alpine/JS — mixing the two produces double submissions.

Mail deliverability is not the package's problem. MAIL_MAILER=log for local, a real transactional provider (with SPF/DKIM) for production. Feedback mail landing in spam is a domain-config issue, not a bug in this package, and it's the most common false report.

Safe extension points: published config, published views, published migrations (additive only), and any service-provider bindings the package exposes. Everything else in vendor/ is overwritten on update — if you need a genuine behaviour change, fork or open a PR upstream rather than patching in place.