christopheraseidl/livewire-cookie-consent
Livewire Cookie Consent provides a ready-made Livewire component for adding a cookie consent banner to Laravel applications. Collect visitor approval before setting cookies, then customize the message, button labels, and persistence through config options and publishable views.
Install and first render (5 minutes)
composer require christopheraseidl/livewire-cookie-consent
php artisan livewire-cookie-consent:install # verify exact signature with `php artisan list`
The install command was refactored in v1.1.0, so don't copy command names from older blog posts or the v1.0.0 README — run php artisan list | grep consent and use what's actually registered.
Where to look first
The new config file (v1.1.0). This is the single most important artifact in this release. Publish it immediately:
php artisan vendor:publish --tag=livewire-cookie-consent-config
Confirm the tag name from the package's service provider if that tag doesn't resolve. Read the file top to bottom before writing any code — cookie name, lifetime, categories, and asset registration are all likely driven from here now.
The published Blade views. Publish them if you intend to style the banner:
php artisan vendor:publish --tag=livewire-cookie-consent-views
The Livewire component. Drop it into your base layout, above </body>:
<livewire:cookie-consent />
Component paths changed in v1.1.0. If you were referencing the component by a fully-qualified class or a hardcoded view path, that reference is now stale — use the tag alias and let the package resolve it.
First real use case: gate a third-party analytics snippet so it only loads after opt-in. That's the whole reason you install this package, and it's the fastest way to validate the install end to end.
@if (app(\ChristopherASeidl\LivewireCookieConsent\Services\ConsentService::class)->allows('analytics'))
<script src="https://analytics.example.com/script.js"></script>
@endif
The exact service class/facade name is worth confirming against the source — v1.1.0 explicitly introduced a configuration service and an asset management service, so the API surface here is new and likely to be the intended entry point.
Config-driven categories over hardcoded strings. With the new config file, define your cookie categories once and reference them by key everywhere. This keeps your Blade gates, banner copy, and tests in sync, and it's the difference between a one-line change and a grep-and-replace when legal asks you to split "marketing" into "marketing" and "retargeting."
Two-layer consent enforcement. Consent lives in a browser cookie, so you need both:
The second layer is the one people forget. Anything you do server-side based on a consent cookie must be excluded from shared/full-page caches, or you'll serve one user's personalized page to another.
React to consent changes without a reload. Livewire's event bus is the natural integration point — the banner dispatches an event when the user accepts/rejects, and your components listen:
#[On('consent-updated')]
public function onConsentUpdated(): void
{
$this->analyticsEnabled = $this->consent->allows('analytics');
}
This matters for SPA-ish pages where a user might toggle preferences from a settings panel long after the initial banner interaction.
Centralize script registration. v1.1.0 added an asset management service. Instead of scattering <script> tags across layouts, register scripts against a category in one place (a service provider or the config) and render them through the package. You get one audit point for "which scripts fire under which consent state," which is exactly what you'll be asked for during a privacy review.
Use the uninstall command in tests and CI teardown. The uninstall path was refactored alongside install. If you're writing an integration test that scaffolds a Laravel app, the install/uninstall pair is your setup/teardown — verify both directions work, since uninstall commands are the classic place for stray-published-file bugs.
Test with Livewire's own helpers. The migration to Laravel's testing framework in v1.1.0 means Livewire::test(CookieConsent::class) style assertions are the supported path:
Livewire::test(\ChristopherASeidl\LivewireCookieConsent\Livewire\CookieConsent::class)
->assertSee('Accept')
->call('acceptAll')
->assertDispatched('consent-updated');
Method names above are illustrative — read the component's public methods and assert against those rather than guessing.
Treat v1.1.0 as a breaking upgrade, not a patch. The release notes are explicit: files removed, Livewire component paths changed, install/uninstall refactored, exception handling reworked. If you extend the package — custom views, subclassed components, your own service provider bindings, published-then-edited views — budget real time for this. If you consume it as-is, you're probably fine.
Re-publish the config, but merge rather than overwrite. You're upgrading into the config file's introduction, so you have no local copy yet — publish cleanly. For the next release, remember --force will silently clobber your customization. Diff the package's shipped config against yours on every upgrade; the new config service in v1.1.0 may also mean some settings that used to work via .env now only resolve through the config file.
Component path changes are the sneakiest break. <livewire:cookie-consent /> will keep working because it resolves by alias, but any @include('livewire-cookie-consent::...') or class-string reference in your own code will fail with a "view not found" or "class does not exist" at runtime, not at build time. Grep your views and providers for the old paths after upgrading.
Exception types may have moved. "Improved exception handling" plus "removal of some files" often means exception classes were renamed, consolidated, or relocated. If you have catch blocks targeting package exceptions, verify them. Silent swallows are the failure mode here: your handler stops matching and the generic Throwable catch upstream hides the real error.
Configuration caching will bite you. php artisan config:cache in production plus a config file added mid-upgrade means stale cached config unless you re-run the cache command as part of deploy. If the banner renders with wrong categories in staging but is fine locally, this is your first suspect.
Consent cookies and cache poisoning. Never let a response vary on the consent cookie unless you've configured your cache layer (Vary: Cookie, or excluding those routes entirely). A CDN caching a page with analytics tags injected for one consented user and serving it to everyone is a compliance incident, not a bug.
Debugging the banner's absence. The component renders nothing on the server by default when consent is already recorded — that's correct behavior, not a failure. To verify the install: clear cookies for the domain, reload, then check that the Livewire component is in the DOM. If it's still missing, confirm Livewire's asset injection is present in your layout and that the package's views are published or resolvable.
Check Livewire version compatibility explicitly. The path migration suggests alignment with Livewire 3's conventions. If you're still on Livewire 2, verify before upgrading — and if you're on Livewire 3, take the opportunity to confirm the package isn't registering a v2-style component alias that conflicts with your own.
Extension points to lean on rather than fork. Between the new config file, the configuration service, and the asset management service, v1.1.0 gives you three supported seams. Prefer binding against the service interfaces in your own provider over subclassing the Livewire component — subclassing is precisely the pattern that broke for extenders in this release, and it will break again.
Watch the changelog link, not just the summary. The release notes point at the full diff. The "removal of some files" line is the one worth chasing down before you upgrade a production app — it tells you what stopped existing, which the summary deliberately doesn't enumerate.
How can I help you explore Laravel packages today?