Larecipe Feedback Laravel Package

Getting Started

This is a small add-on for LaRecipe (binarytorch/larecipe), the Laravel documentation package. It does one thing: it drops a feedback widget into your docs pages so readers can rate/comment on what they just read. Because it targets LaRecipe specifically, you should only reach for it if LaRecipe is already your docs stack — it is not a general-purpose feedback package.

First steps:

1. Confirm your LaRecipe version. The package's last release was July 2019, which puts it in the LaRecipe 1.x era. Check composer show binarytorch/larecipe and expect to pin compatible versions of both; do not assume it works with LaRecipe 2.x or Laravel 8+.
2. Install and publish assets:

   composer require binarytorch/larecipe-feedback
   php artisan vendor:publish --provider="BinaryTorch\LaRecipeFeedback\LaRecipeFeedbackServiceProvider"
   

   Publish everything you can — config, migrations, and any JS/Vue assets. Inspect the published files before running migrations so you know exactly what tables and routes were added.
3. Run the migration and confirm a feedback table is created in your database.
4. Wire the widget into LaRecipe's layout. LaRecipe renders docs through its own Blade views/Vue app; you typically need to add the package's component/blade include to the LaRecipe layout (either by publishing LaRecipe's views and editing them, or via the package's documented include). This is the first place to look when "it's installed but nothing shows up."
5. First use case: visit any rendered docs page, submit the widget, and verify a row lands in the feedback table. That end-to-end check (render → submit → persist) validates the whole integration in one pass.

Where to look first when reading the code: the service provider (routes, publishes, view namespaces), the package's migration (schema you'll query later), and the Vue/Blade component (what fields are posted and to which endpoint).

Implementation Patterns

Pin-and-contain installation. Since the package is archived, treat it as a vendored dependency: pin the exact version in composer.json, commit the published config/migration, and avoid composer update surprises. If you need it long-term, fork it into your own VCS namespace so the provider name and asset paths stay stable.

Feedback capture as an event source. The most valuable pattern is to treat stored feedback as data, not just a widget. Read directly from the feedback table in a small admin controller or Nova/Filament resource:

// Typical shape — verify column names against the published migration
$feedback = DB::table('larecipe_feedback')
    ->latest()
    ->paginate(50);

Aggregate by page/route to find the docs pages that generate the most negative responses; that is the actual ROI of installing this.

Per-page scoping. Ensure each submission is tied to the documentation page (route or slug). If the shipped schema doesn't capture enough context, add a column via your own migration rather than editing the package's — e.g. store request()->path() or the LaRecipe page key in a page column. This makes the data actionable.

Blade/Vue integration. If the widget is a Vue component, it must live inside LaRecipe's mounted app. Prefer including it in the published LaRecipe layout just above the footer or after the article body. If you've customized LaRecipe's theme, mirror the change in your theme overrides so a vendor:publish refresh doesn't wipe it.

Custom form fields. For richer feedback, publish the component, then extend the posted payload (e.g. "was this helpful?" thumbs plus an optional comment). Update the controller/validation on your side by overriding the package route or wrapping the endpoint.

Routing and middleware. Check the package's routes file. If the feedback endpoint is public, wrap or replace it with your own route group (web, throttle:feedback, optional auth) by disabling the package route in config and registering your own pointing at the package controller — or a subclass.

Notification hook. A lightweight pattern: on new feedback, dispatch a queued job or notification to the docs owner when the rating is below a threshold. Don't do this in the package's controller directly; use a model observer or a small listener on the feedback table/model if one exists.

Gotchas and Tips

• Archived and unmaintained. No security or compatibility fixes are coming. Audit the package code (it's small) and be prepared to own it. Do not introduce it into a codebase you can't fork.
• LaRecipe version drift. The 2019 release predates modern LaRecipe and Laravel. Expect breakage on Laravel 8+/PHP 8 (typed properties, return types, deprecated helpers). If installation fails, inspect the provider's boot/register for old container and route syntax.
• "Installed but invisible." Almost always a layout/include problem: the component isn't in LaRecipe's rendered layout, or published JS assets aren't loaded. Publish LaRecipe's views and confirm the include is actually in the template that renders.
• Migration collisions. Running migrate may create a table name you already use, or the migration may not be idempotent. Read it first; rename the table in config if there's a clash.
• CSRF and asset paths. If submissions 419, the widget's AJAX call is hitting a route outside the web middleware group or missing the CSRF token meta tag. Verify VerifyCsrfToken isn't excluding the endpoint unintentionally, and check APP_URL/asset URL config if the JS 404s.
• Public endpoints are spam magnets. Add rate limiting and consider a honeypot or optional auth. The archived package likely has no protection.
• Config quirks. Published config may reference the vendor view namespace (e.g. larecipe-feedback::...). If you override views, keep the namespace and let Laravel's view resolution prefer your published copy; don't rename the namespace.
• Extension points to prefer: config toggles, published views/components, and your own migration for extra columns. Avoid editing files inside vendor/ — those changes vanish on the next install.
• Data hygiene. Feedback rows are user-generated text; escape on render and never trust the submitted rating/comment in admin views without validation. Back up before any schema change.
• Cost/benefit sanity check. At 19 stars, near-zero adoption, and archived status, the maintenance surface is yours. If LaRecipe compatibility is uncertain, a 30-line custom Blade form + controller + migration gives you the same outcome with no dead dependency — consider that before adopting this.