- Can I install eveltic/cookie-bundle in a Laravel application?
- No. Despite being listed among PHP packages, this is a Symfony bundle built on a DI extension with a configuration tree, Twig templates and extensions, Symfony routing and controllers for its AJAX endpoints, and the Symfony Translator. None of that boots inside a Laravel app without a compatibility layer, so treat it as a reference implementation to port rather than a Composer dependency. Realistically expect one to three weeks to reimplement the routes, convert Twig to Blade, move configuration into config/, and rewire translations to Laravel's translator.
- How do I install and set up the cookie consent bundle in a Symfony app?
- Run composer require eveltic/cookie-bundle, then execute php bin/console ev:cookie:install to generate the files you need to adapt to your configuration. Update the schema with doctrine:schema:update --force or by generating and running a Doctrine migration. Finally, add the Twig calls ev_cookie_include_assets() and ev_cookie_render() to your base template to output the banner assets and markup.
- Which Symfony versions does this bundle support?
- The bundle is written around Symfony 6 and 7 conventions such as bundle DI extensions, event subscribers, Twig extensions, and the Symfony Translator, and it is described as a low-effort drop-in for those versions. The README does not publish an explicit version constraint table, so check the composer.json require block of the tagged release you plan to use. Older Symfony 4 or 5 projects should be validated with a test install before committing.
- What cookie categories and expiration settings can I configure?
- Four categories ship by default: technical, preferences, analytics, and ads, and you can add or remove categories to match your own setup. Cookie expiration periods are configurable, and the banner supports light, dark, and auto theme modes. A preferences modal exposes per-category toggles, and a persistent floating button plus a consent-details view let users retract consent at any time. All of this is driven through AJAX calls, so no page refresh is needed.
- How do I check whether a user has accepted a cookie category in Twig or PHP?
- The bundle exposes Twig helpers and backend functions that let you test whether consent has been accepted before rendering non-essential markup or executing server-side logic. Wrap analytics or advertising snippets in those checks so output is conditioned on the stored preference. Because the checks are exposed on both the template and backend layers, you can gate script tags in Twig and gate server-side tag injection in your controllers or services.
- Does the bundle store consent server-side with a timestamp and policy version for audit?
- The bundle integrates with Doctrine ORM and includes command line tools for archiving cookie consent data, which indicates persistence beyond a first-party cookie and gives you something to archive. What the README does not document is whether the stored record includes an auditable proof-of-consent tuple such as timestamp, banner or policy version, accepted categories, and a user identifier. Confirm the schema and retention policy by reviewing the generated entity before you rely on it as evidence of consent.
- Does it support Google Consent Mode v2 or IAB TCF?
- There is no stated support for Google Consent Mode v2 or the IAB Transparency and Consent Framework. If your site runs GTM, GA4, or AdSense in the EU, Consent Mode is effectively table stakes, so you would need to write custom glue that maps the bundle's category state into gtag consent signals. The same applies to TCF-based vendor lists, which are not part of the feature set.
- How does cookie versioning force users to re-consent?
- The bundle includes cookie versioning as a feature, which means bumping the version invalidates previously stored preferences and prompts the user to consent again. Use this whenever you change your cookie policy, add a vendor, or introduce a new category, so captured consent stays aligned with the current banner. Test the flow in staging to confirm the retract and re-consent UI appears as expected for returning users.
- Is the package actively maintained and safe to use in production?
- Maturity signals are thin: roughly two stars, no dependents, no visible CI badges or coverage reports, and no detailed changelog. The most recent release is dated 2025-09-26, which shows recent activity but is not a maintenance track record. The MIT license lets you fork, but it does not reduce the cost of owning that fork, so assume your team becomes the maintainer of record and budget for code review and patching.
- Does the bundle guarantee GDPR/AEPD compliance, and does it block scripts before consent?
- The 2024 AEPD compliance claim is a marketing statement, not a certification, so validate the behaviors that matter yourself. Check whether non-essential scripts are actually blocked before consent or merely recorded as a preference while tags still fire, and confirm there is a reject-all path with prominence equal to accept-all with no pre-ticked categories. Also verify CSRF protection, input validation, and rate limiting on the AJAX write endpoints, plus nonce or hash support if you run a strict CSP, and review keyboard focus handling and screen reader behavior in the modal against WCAG 2.2 AA.