Cookie Notice Laravel Package

Getting Started

Install the package and publish its config and views:

composer require duncanmcclean/cookie-notice
php artisan vendor:publish --tag="cookie-notice-config"
php artisan vendor:publish --tag="cookie-notice-views"

Open config/cookie-notice.php first — that is where the banner text, button labels, policy link, position, and cookie lifetime are defined. Then drop the widget into your main layout, usually just before the closing </body> tag:

@include('cookie-notice::widget')

The first realistic use case is gating analytics/marketing scripts: render the banner on every page, and only initialise tags like Google Analytics after the visitor has accepted. For a quick smoke test, load any page in a fresh private window and confirm the banner appears once, then disappears after choosing an option.

Implementation Patterns

• Gate scripts on consent state. Keep third-party snippets out of your base layout and initialise them from a small script that checks the consent cookie/localStorage value the package sets. This keeps the banner purely presentational and your analytics logic explicit.
• Override the published Blade view (resources/views/vendor/cookie-notice/widget.blade.php) rather than editing vendor files when you need custom markup, extra buttons, or to match your design system.
• Use the package's front-end events (cookie-notice:accepted / cookie-notice:declined or your version's equivalents) to trigger analytics initialisation and to avoid duplicating cookie-parsing logic across scripts.
• Scope the banner per environment or route by wrapping the include in a check (e.g. don't show it on admin routes), or by using middleware if you need consent enforced server-side.
• Publish translations and reference them in config if the site is multilingual, so text changes don't require view overrides.
• Test consent flows with Laravel's cookie helpers (withCookie, withoutCookie) to assert that gated content behaves correctly for accepted vs. undecided visitors.

Gotchas and Tips

• Clear caches after publishing or editing config/views. php artisan config:clear and php artisan view:clear are the first things to run when changes don't appear; cached config is a common cause of "the banner ignores my settings."
• Changing the consent cookie name or expiry invalidates existing consent. Treat those config keys as a contract; bumping them effectively re-asks every visitor.
• Page caching can bake in the banner. If you cache full HTML responses, make sure the widget is excluded or that the consent check happens client-side, otherwise accepted users may keep seeing the notice.
• v10.2.2 fixes the widget flashing on page load when preferences are already set. If you were working around a visible flicker (e.g. with custom CSS to hide the banner initially), update to this release and remove the workaround.
• Asset publishing matters. If styles or JS are missing, re-run the relevant vendor:publish tag and confirm your layout includes the package assets; with Vite setups, double-check the published asset paths.
• Extension points: custom Blade view, published translations, and the config file are the supported customisation surfaces. Prefer them over forking the package so future patch releases (like this one) apply cleanly.