Cookie Consent Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config publish tag, and no Laravel auto-discovery. Treat it as source material to port or as a Symfony-side dependency only.

Minimal evaluation steps in a Laravel app:

1. Run composer require fairlane/cookie-consent-bundle --dry-run and read the resolved dependency tree. The bundle targets Symfony's framework-bundle and Twig; pulling those into a Laravel project can conflict with the Symfony components Laravel already pins.
2. Open the repository in this order: the bundle class in src/, Resources/config/services.yml (or services.php), Resources/config/routing.*, Resources/views/, and the README. Those files tell you what services, routes, Twig helpers, and templates you would have to re-implement.
3. Confirm the Symfony version constraint in composer.json. A last release of 2017-11-11 means Symfony 3.x-era APIs; expect incompatibility with Symfony 5/6 and modern PHP.
4. First realistic use case for a Laravel developer: do not install it. Instead, use it as a reference implementation for a ~100-line in-house consent banner: a Blade partial in your layout, a small JS snippet that writes a consent cookie, and middleware that reads that cookie before injecting analytics/marketing scripts.

If you are actually maintaining a Symfony app where it belongs: register the bundle in config/bundles.php, import its routing, configure the consent text/categories, and include its Twig template in your base layout. For Laravel, the only sane port path is copying the view/JS behaviour into Blade and replacing the Symfony DI wiring with a Laravel service provider.

Implementation Patterns

Consent-gate middleware. The day-to-day value is not the banner; it is gating non-essential scripts. In Laravel, create middleware that reads a consent cookie (for example cookie_consent containing {"analytics":true,"marketing":false}) and shares the result with views via View::share or a request attribute. Then conditionally render analytics snippets in your layout:

@if (app('cookie-consent')->allows('analytics'))
    @include('partials.analytics')
@endif

Blade partial plus vanilla JS. Symfony bundles ship Twig templates; convert the markup to a Blade partial included once in layouts/app.blade.php. Keep the JS cookie-writing logic in a small resources/js/cookie-consent.js file. Prefer SameSite=Lax, an explicit path=/, and a long expiry.

Config bridge. If the bundle exposes configuration (banner text, categories, cookie name, expiry), mirror it in config/cookie-consent.php and register a singleton in AppServiceProvider. Do not try to boot Symfony's config tree inside Laravel.

Granular categories. Model consent as categories (necessary, analytics, marketing) rather than a single accept/reject flag. Store a JSON object in the cookie, version it ("v":1), and re-prompt when your policy version changes. This is the pattern most likely to survive an audit.

Script-loading pattern. For third-party tags, block the <script> tag server-side where possible. If you must defer client-side, use type="text/plain" data-consent="analytics" and swap the type after consent — this is the pattern most cookie-consent libraries use and is straightforward to reimplement.

Testing. Write feature tests that hit a page with and without the consent cookie and assert that the analytics/marketing markup is absent or present. This is the cheapest way to prevent regressions when templates change.

Gotchas and Tips

• Abandoned and low-adoption. Last release 2017, 2 stars, 0 dependents. Assume no security patches, no PHP 8 support, and no Symfony 5/6 compatibility. Do not make it a production dependency without a fork.
• Framework mismatch. The bundle assumes Symfony's container, event dispatcher, routing, and Twig. Laravel has none of that wiring. Installing it risks pulling symfony/framework-bundle and conflicting with Laravel's own Symfony component versions; run a dry-run first.
• Cookie encryption. Laravel encrypts cookies set through its cookie API by default. If your banner JS writes the consent cookie directly, PHP reads it via $_COOKIE, not Cookie::get(). Pick one mechanism and document it; mixing encrypted and plain cookies is a common source of "consent not detected" bugs.
• A banner is not compliance. GDPR/ePrivacy requires prior consent for non-essential cookies, granular choice, easy withdrawal, and ideally a consent record. A 2017 bundle that only displays a notice may implement implied consent, which is not sufficient in the EU. Block scripts by default.
• Caching. Full-page caches and CDNs can serve a page rendered for one consent state to another user. Either vary the cache by the consent cookie or resolve consent client-side for cached pages.
• Debugging. Use php artisan route:list and php artisan config:clear after wiring config. If you attempt any Symfony bridge, container compilation errors will surface as opaque binding exceptions; isolate each service registration rather than importing the whole bundle.
• Extension points worth stealing. The bundle's view templates and cookie-name/expiry configuration are the reusable parts. Fork the repository, convert Twig to Blade, replace the DI with a service provider, and pin the fork if you must use its exact behaviour.
• Recommendation. For a Laravel app in 2024+, build the small in-house version or use a maintained Laravel-specific consent package. The cost of adapting this bundle exceeds the cost of writing the banner and middleware yourself, and the result will be testable and maintainable.