Eu Cookie Law Bundle Laravel Package

Getting Started

First, a reality check that shapes everything else: leblanc-simon/eu-cookie-law-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no config/eu-cookie-law.php, and no Blade directive. A Laravel developer cannot composer require it and expect it to boot. Your realistic options are:

1. Port the relevant bits (the Twig template, the CSS/JS, and the config keys) into a Blade partial or a small custom package.
2. Run it inside a Symfony/Twig context only if you already have one (rare in a Laravel shop).
3. Vendor the template and reimplement the render logic yourself, treating the bundle as a reference implementation.

If you go the port route, the first place to look is the bundle's Resources/views/ directory (the notice markup) and its DependencyInjection/Configuration.php (the option names). Those two files tell you 90% of what the bundle actually does: it renders a cookie explanation div with a message, a policy link, and an accept action.

Minimal port skeleton for Laravel:

// config/eu-cookie-law.php
return [
    'message' => 'We use cookies to improve your experience.',
    'policy_url' => '/privacy',
    'accept_label' => 'Accept',
    'cookie_name' => 'eu_cookie_consent',
    'cookie_lifetime' => 60 * 24 * 365,
];

{{-- resources/views/partials/cookie-notice.blade.php --}}
@unless(request()->cookie(config('eu-cookie-law.cookie_name')))
  <div id="eu-cookie-law" role="dialog" aria-live="polite">
    <p>{{ config('eu-cookie-law.message') }}
       <a href="{{ config('eu-cookie-law.policy_url') }}">Learn more</a></p>
    <button onclick="document.cookie='{{ config('eu-cookie-law.cookie_name') }}=1;path=/;max-age={{ config('eu-cookie-law.cookie_lifetime') }}';this.closest('#eu-cookie-law').remove()">
      {{ config('eu-cookie-law.accept_label') }}
    </button>
  </div>
@endunless

Include it once in layouts/app.blade.php. That is your first use case and it covers the bundle's core value: a compliant-looking notice with a link to policy and a persisted acceptance.

Implementation Patterns

Treat it as a UI concern, not a package concern. The bundle only renders a div. The real GDPR work is your cookie inventory, consent storage, and script gating. Use the package (or your port) only for presentation.

Consent storage pattern. Persist acceptance in a first-party cookie with a versioned value (e.g. v1) so you can re-prompt when the policy changes. Read it in a middleware or view composer and share it:

// app/Http/Middleware/ShareCookieConsent.php
public function handle($request, Closure $next)
{
    view()->share('cookieConsent', $request->cookie('eu_cookie_consent'));
    return $next($request);
}

Gate non-essential scripts. The notice is meaningless if analytics loads before acceptance. Pair the partial with a consent-aware script loader:

@if($cookieConsent)
  <script src="{{ mix('js/analytics.js') }}" defer></script>
@endif

Policy route + localization. Point policy_url at a named route (route('privacy')) rather than a hardcoded path, and drive message/accept_label through __() so the notice respects app()->getLocale(). The original bundle ships translations — mirror that with lang/{locale}/cookie.php.

Full-page cache compatibility. If you cache rendered HTML (response cache, Cloudflare), render the notice unconditionally and hide it client-side based on document.cookie. Server-side @unless(cookie) breaks shared caches because the first anonymous response gets cached without the banner.

Testing pattern. One feature test is usually enough:

public function test_notice_is_shown_without_consent_cookie(): void
{
    $this->get('/')->assertSee('We use cookies');
}

public function test_notice_is_hidden_with_consent_cookie(): void
{
    $this->withCookie('eu_cookie_consent', 'v1')
         ->get('/')
         ->assertDontSee('We use cookies');
}

Gotchas and Tips

• Framework mismatch is the biggest one. No Laravel service provider, no auto-discovery, no facades. Budget time for the port; do not assume composer require "just works."
• It is a div, not a consent manager. The bundle does not block cookies, categorize trackers, or log consent. You still need to gate analytics/marketing scripts yourself and decide whether explicit opt-in is required in your jurisdiction.
• Tiny ecosystem signal. 10 stars and 0 dependents means limited peer review. Read the template and JS line by line before copying, and pin a commit hash if you vendor it. Do not treat it as audited compliance code.
• Asset publishing. Symfony bundles expose CSS/JS via Resources/public. In Laravel you must copy those into resources/ and run them through Vite/Mix — there is no vendor:publish tag unless you build one.
• Template override instead of fork. If you stay on Symfony for any reason, override the bundle's Twig template in templates/bundles/EuCookieLawBundle/ rather than editing vendor files. In Laravel, the equivalent discipline is a single Blade partial you own.
• Accessibility and dismissal. The original notice is informational; ensure you keep role="dialog"/aria-live and a keyboard-focusable accept button. Add a "reject" path if your legal review requires it — the bundle historically favors implied consent.
• Do not cache the consent decision server-side per user unless you key the cache by cookie value. The safe default is client-side hiding with an unconditional render.
• Extension points to preserve in a port: message text, policy URL, accept label, cookie name/lifetime, and a way to swap the template. Those are the knobs a real deployment always ends up needing.