- Is friendsofvictoire/cookielaw-widget a Laravel package?
- No. It is a Symfony bundle built for Victoire DCMS, a Symfony-based content management system. It registers through the Symfony kernel, renders with Twig, and depends on Victoire's widget abstractions. There is no service provider, no config publish tag, and no facade, so nothing maps onto Laravel's package conventions.
- Can I install friendsofvictoire/cookielaw-widget in a Laravel app with Composer?
- Practically no. Laravel has no bundle-registration mechanism and no Twig by default, so the bundle has nothing to hook into. Its dependency tree targets Symfony 2.x/3.x and PHP 5.6/7.x era constraints, which will almost certainly conflict with modern Laravel running PHP 8.1+ and Symfony 6/7 components. Forcing it in would mean standing up Symfony's event dispatcher and Twig bridge inside Laravel, which is disproportionate engineering for a banner.
- Which Laravel and PHP versions does this cookie widget support?
- None, because it is not a Laravel package at all. The last release was September 2016, so its constraints target PHP 5.6/7.x and Symfony 2.x/3.x. It has never been tested against any Laravel version, and no compatibility bump has been published in roughly nine years.
- How do I add a cookie consent banner to Laravel using this package?
- Do not install it as a dependency. Read the source and extract the banner markup, CSS, and cookie get/set logic as a design reference, then reimplement it as a Blade component with state held in a first-party cookie or localStorage keyed to a policy version string. At that point you have written the widget yourself, which is the realistic path. The original package contributes no runtime value outside Symfony.
- Does this package make my site GDPR and ePrivacy compliant?
- No, and this is the biggest risk with it. A 2016-era banner predates GDPR enforcement practice, CNIL guidance, the EDPB cookie banner taskforce recommendations, and current ePrivacy consent requirements. It lacks granular purpose categories, reject-all parity with accept-all, consent renewal, pre-consent script gating, and any audit trail. Deploying it could create the appearance of compliance while failing the substantive test.
- Does the widget block analytics and marketing scripts before consent?
- Not reliably. The functional payload is a small markup, CSS, and JavaScript fragment plus a cookie-presence check. Pre-consent gating, where no analytics, marketing, or third-party scripts execute until the matching category is granted, is the part that carries the legal weight and the part this package does not provide. You would have to implement that yourself regardless.
- Does it log or store consent decisions for audits?
- No. There is no server-side consent record, so you get no timestamp, scope, policy version, or identifier to evidence a decision. If you need consent evidence for audit or contractual obligations, you must POST decisions to your own Laravel endpoint and persist them. This package provides none of that.
- Is friendsofvictoire/cookielaw-widget still maintained?
- No. The last release was September 2016, with no commits, security review, or compatibility updates since. It has two stars and zero dependents, meaning no production validation, no community fork, and no issue triage. Treat it as an abandoned reference implementation rather than a maintained dependency.
- What are the alternatives for cookie consent in Laravel?
- For a simple dismissible notice, a small Blade partial plus a JavaScript module is often enough, and packages like spatie/laravel-cookie-consent or whitecube/laravel-cookie-consent cover the basic banner case. If you need defensible consent management with granular categories and audit evidence, use a dedicated CMP such as OneTrust, Cookiebot, Osano, or Usercentrics. First clarify whether the requirement is a dismissible banner or genuine consent management, because this package cannot satisfy the latter regardless of porting effort.
- How should I test a cookie consent banner in a Laravel application?
- Verify that no non-essential scripts fire before consent and that reject-all has parity with accept-all. Confirm the decision persists across requests, is keyed to a policy version, and re-prompts when the policy changes. If you log consent server-side, assert that the endpoint records identifier, timestamp, categories, and version, and that it rejects malformed payloads. Do this against your own Blade implementation, since the original bundle has no test suite you can reuse.