Laravel Cookies Consent Laravel Package

Getting Started

• Install with composer require scify/laravel-cookie-guard, then publish the package assets and configuration. The public assets are published with php artisan vendor:publish --tag="cookies-consent-public"; use the package's other publish tags for config, views and translations as needed.
• Open the package config first. This is where you define consent categories, which categories are required, and which cookie names belong to each category. These name entries are what the package erases when a visitor rejects or later withdraws consent.
• Add the package's banner or floating-button component to your main layout. If you use use_separate_page mode, add the separate consent page as well.
• Make sure the page renders a CSRF token. The route now runs in the web middleware group, so the JavaScript must be able to send a token. The component looks for data-csrf-token on the banner root, then the csrf-token meta tag. In a standard Blade layout, include <meta name="csrf-token" content="{{ csrf_token() }}">.
• Publish translations only for the locales you actually override. In 5.1 they go to lang/vendor/cookies_consent/{locale}/messages.php.
• First use case: accept all, reject optional, or save a per-category selection. On success the consent cookie is written and the banner closes; on rejection the declared cookies for the rejected categories are erased. Test this on a real page with real cookies before relying on it.

Implementation Patterns

• Define categories declaratively. Each category should list its cookies under name. The server validates the posted consent payload as one boolean per configured category plus locale; anything else is dropped. Treat the config as the single source of truth for both the UI and the erasure logic.
• Use required for non-optional categories. Required categories are always stored as accepted, regardless of what the browser sends. "Reject optional" keeps every category listed in required, not only strictly_necessary.
• Control persistence with cookie_lifetime. This now governs the consent cookie the browser stores. 0 keeps consent for the browser session only. The old hardcoded 30-day behaviour is gone.
• Use use_separate_page for a dedicated settings page. The 5.1 release fixes "Accept all" and "Reject optional" in this mode by rendering the category list on the banner root. If you have custom markup for this mode, include the new data attributes.
• Open the banner from your own UI with a link to #consent-settings or a hash change after page load. Both open the banner; they no longer toggle it. This is the right hook for a footer "Cookie settings" link.
• If your own code posts to /guard-settings/save, send the CSRF token (X-XSRF-TOKEN, _token, or the X-XSRF-TOKEN cookie pattern used by the package). Expect a 422 if any category value is not a boolean.
• Override views deliberately. Publish the components if you need markup changes, but keep the root data attributes (data-cookie-lifetime, data-cookie-categories, data-required-categories, data-csrf-token) intact. Re-publishing over custom views will discard your changes; diff before using --force.
• Override translations key by key. Publish to lang/vendor/cookies_consent/ and keep only the strings you change. Laravel merges the rest, so later fixes arrive automatically.
• Test both layers. The package ships Pest tests for config-driven Blade output and view overrides, and Node node:test coverage for the JavaScript bundle. Mirror that split in your app: assert the rendered category list and attributes in PHP, and exercise accept/reject/save flows in a browser or JS test.
• Inertia, Livewire and Turbo apps benefit from the XSRF-TOKEN cookie being sent as X-XSRF-TOKEN, so consent saves keep working on pages that never reload.

Gotchas and Tips

• Re-publish the public assets after upgrading. Run php artisan vendor:publish --tag="cookies-consent-public" --force. Old JavaScript does not read the new root attributes.
• Old published Blade components are the biggest upgrade trap. Without the new root attributes the JavaScript erases nothing on rejection and falls back to 365 days. Re-publish the components or add data-cookie-lifetime, data-cookie-categories, data-required-categories and data-csrf-token manually.
• CSRF failures are now real. If your custom integration posts to the save route without a token, expect a 419. This was silently accepted before 5.1.
• The banner stays open on a failed save. That is intentional. If it "won't close", check the network response for 419/422 rather than the banner logic.
• A non-boolean category value returns 422. Send real booleans, not strings or 0/1 if your client is strict. Unknown keys are dropped rather than rejected.
• Required categories are never erased. If a cookie is not being removed, check whether its category is in required.
• Erasure only covers cookies declared by name. The package deletes on the host and parent domains down to the registrable domain, but it cannot remove cookies you forgot to declare.
• The old enabled config key is gone. Nothing read it; initial checkbox state comes from required only. Remove it from your config to avoid confusion.
• Swedish moved from se to sv. If your app uses locale se, switch it or your translations will not resolve.
• The old translation directory still works until v6. lang/vendor/scify/laravel-cookie-guard/ is read with a log warning. Move changed strings to lang/vendor/cookies_consent/{locale}/messages.php and delete the old directory now rather than at v6.
• Do not rely on the removed server-side cookie. {cookie_prefix}cookies_consent_selection never reached the browser and is gone, as is the pre-v3 cookieConsent eraser.
• Hash links no longer toggle. If you built a custom link that relied on the old toggle behaviour, it will now open the banner every time. That is the documented behaviour.
• Floating button keyboard handling is fixed. Pressing Enter opens it once; remove any workaround that compensated for the previous double toggle.
• Consent cookie attributes changed. It is written with SameSite=Lax, and Secure on HTTPS pages. If you inspect cookies over plain HTTP in development, expect the Secure flag to be absent there.
• Debugging tip: inspect the banner root's data attributes first, then the network request to the save route, then the consent cookie. Most 5.1 upgrade issues are visible at one of those three points.