Cookie Consent Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony bundle, not a Laravel package. There is no Lemric\CookieConsentBundle\CookieConsentServiceProvider, no config/cookie-consent.php, and no vendor:publish tags. Composer will install it into a Laravel app just fine, but nothing will auto-register. So your day-one decision is architectural, not technical:

1. If you control the stack and it's genuinely Symfony (or a Symfony app sitting next to a Laravel API), install normally and register the bundle in config/bundles.php. This is the only path where "using the package" means what its author intended.
2. If you're on Laravel (the common case), treat this as a reference implementation + front-end asset source, not a dependency. Clone it, read src/, lift the consent-banner JS/CSS and the consent-state model, and reimplement the server-side bits as a Laravel package of your own (service provider, config file, Blade component, middleware). The bundle's total logic is small enough that porting is cheaper than bridging Symfony's DI container into Laravel's.

Where to look first, in this order:

• composer.json — required Symfony version, whether it pulls symfony/framework-bundle, twig, doctrine/*. This tells you how heavy a bridge would be.
• src/DependencyInjection/Configuration.php — the config tree. This is the de-facto documentation for this package; with 0 stars there is no README worth trusting more than the code.
• src/Resources/config/ — service definitions: what the consent service is called, what it injects, whether there's a controller or a Twig extension.
• src/Resources/views/ — the banner markup. Note the template namespace (@LemricCookieConsent/...) because that's also the override path.
• src/Resources/public/ (or assets/) — the JS that writes/reads the consent cookie. This is the piece you'll actually reuse in Laravel.

First use case to validate end-to-end: render the banner on a fresh session → click "Accept analytics" → confirm a consent cookie is written with a category payload → confirm a server-side request to a page that outputs an analytics snippet now includes it. If you can't get that loop working in an afternoon, the package isn't saving you time.

Implementation Patterns

Category-based gating, not a single boolean. The useful shape for AVG/GDPR is necessary | analytics | marketing | preferences, with necessary always on and the others opt-in. Whatever the bundle exposes, normalize to a category array in the consent cookie payload (e.g. {"v":1,"cats":["necessary","analytics"],"ts":...}). Gate on category, never on "did they click accept."

Server-side gate before the script tag, not after. The pattern that actually holds up:

@if (app(\App\Support\Consent::class)->allows('analytics'))
    <script src="{{ mix('js/analytics.js') }}"></script>
@endif

Rendering the tag with a type="text/plain" and letting JS rewrite it works too, but it leaks the request and is easy to get wrong. Prefer the server-side check plus a thin client-side check for SPA routes.

Laravel middleware for the state, not a global helper. If you port this, make ResolveCookieConsent middleware parse the consent cookie once, validate the version, and bind a Consent object into the container. Controllers, Blade, and Livewire then all read the same source of truth, and you get a natural test seam ($this->withCookie(...)).

Consent versioning and re-prompting. Put a schema/policy version in the cookie. When you bump it (new vendor, new purpose), treat old cookies as absent and re-prompt. This is the single most-forgotten GDPR requirement and the bundle likely doesn't do it for you unless you wire it.

Audit trail in the database. A banner alone doesn't demonstrate consent. Log (user_id|null, consent_id, version, categories, ip_hash, user_agent, granted_at, withdrawn_at) on every change. For Laravel: a consents table + an event listener; for Symfony: a Doctrine entity + an event subscriber on the bundle's consent event (check src/Event/ for the dispatched event name — that's your extension point).

Withdrawal must be as easy as granting. A persistent "Cookie settings" link in the footer that reopens the banner and lets the user downgrade. The bundle's JS usually exposes a reopen hook; if not, call the same function the banner's settings button calls.

Cross-domain / subdomain consistency. Set the consent cookie on .example.com with SameSite=Lax (or None; Secure if you're embedding across sites), and match Path=/. Mismatched scope is the #1 cause of "the banner keeps reappearing."

Gotchas and Tips

• Zero stars, zero dependents, last release Aug 2024. That's not a disqualifier, but it means: no Stack Overflow answers, no CVE feed you'll hear about, no one to ask. Vendor the source or fork it into your org so an upstream disappearance doesn't break a build. Pin the exact version.
• The bundle does not make you GDPR-compliant. It gives you a prompt and a preference store. Prior consent (no non-essential cookies before the click), a cookie policy page, records of consent, and withdrawal are your responsibility. Don't let the banner create a false sense of closure in a review.
• No pre-ticked boxes, and "Reject all" must be as prominent as "Accept all." Regulators in the NL/EU have been explicit about this. If the shipped template only has "Accept" + "Settings," edit the template — you can override Symfony bundle templates by placing a file at templates/bundles/LemricCookieConsentBundle/<template>.twig in the app.
• Full-page caching breaks the banner. If a response is cached at the edge, the banner state (or the presence of analytics tags) is baked in for everyone. Either make the consent resolution client-side for cached pages, use ESI, or vary the cache key on the consent cookie. This bites people in production, not in dev.
• Asset publishing is Symfony-shaped. bin/console assets:install --symlink or an importmap entry — there's no vendor:publish. If you're porting to Laravel, copy the assets into resources/ and run them through Vite rather than serving from vendor/.
• Config quirks live in the config tree, not the README. Cookie name, lifetime, domain, template path, and which categories exist are typically all configurable via config/packages/lemric_cookie_consent.yaml. Read Configuration.php before you assume a key exists; the array node names are the API.
• Check the translation directory. AVG is the Dutch GDPR; a bundle by that name likely ships nl and en at minimum. Confirm before you hardcode English strings in an override template, or you'll silently lose the other locales.
• Test the rejection path, not just acceptance. Feature test with a consent cookie that omits analytics, assert the analytics <script> is absent from the HTML. That single test catches most regressions from a refactor.
• Watch for Symfony version coupling. If the bundle's composer.json requires symfony/framework-bundle: ^6.x and you're on 7, you'll get resolution conflicts. In Laravel this doesn't matter (you're porting), but it does if you go the bridge route.
• Debugging tip: when the banner "doesn't show," check whether the cookie is already present (it will hide), then check the cookie's Path/Domain in devtools, then check whether the bundle's template renders at all by hitting its route/controller directly. 90% of the time it's a stale cookie from a previous config.