Privacy Cookie Bundle Laravel Package

Getting Started

Confirm the environment first. This bundle targets Symfony 2.6 – 3.x and was archived in 2019. In a Symfony 4/5/6 app there is no AppKernel.php and no automatic bundle registration, so treat it as a porting exercise rather than a drop-in dependency.

1. Install

   composer require ezsystems/privacy-cookie-bundle
   

2. Register the bundle in app/AppKernel.php:

   $bundles = [
       // ...
       new EzSystems\PrivacyCookieBundle\EzSystemsPrivacyCookieBundle(),
   ];
   

3. Configure it in app/config/config.yml (verify exact keys against DependencyInjection/Configuration.php in the vendor directory — the bundle is old enough that docs may differ slightly from the shipped tree):

   ezsystems_privacy_cookie:
       cookie_name: privacy_cookie
       cookie_lifetime: 365
       banner:
           message: "This site uses cookies to improve your experience."
           more_info:
               text: "Read more"
               link: "/privacy-policy"
           accept_text: "Accept"
   

4. Publish the bundle assets (the public files live under web/bundles/ezsystemsprivacycookie/):

   php app/console assets:install --symlink
   php app/console cache:clear
   

5. Wire it into your base layout — add the stylesheet/script and render the banner once, as the last element in <body>:

   <link rel="stylesheet" href="{{ asset('bundles/ezsystemsprivacycookie/css/privacycookie.css') }}">
   {# ... #}
   {{ render(controller('EzSystemsPrivacyCookieBundle:PrivacyCookie:banner')) }}
   <script src="{{ asset('bundles/ezsystemsprivacycookie/js/privacycookie.js') }}"></script>
   

Where to look first: the bundle's Resources/views/ for the banner markup, Resources/public/css|js for presentation/behaviour, and DependencyInjection/Configuration.php for the authoritative config schema. Your first real use case is normally "show a one-time cookie notice across the whole site and link to the privacy policy" — put it in base.html.twig, configure a message and a policy link, and confirm the cookie is written when you click Accept.

Implementation Patterns

Single render point in the base layout. The banner is a global UI concern; render it exactly once from base.html.twig (or your main layout). Rendering it inside partials or error templates leads to duplicate banners and multiple cookie-setting code paths.

Gate third-party scripts on the cookie. The banner itself does not block anything. The day-to-day pattern is to read the bundle's cookie in Twig/PHP and only emit analytics/marketing tags after acceptance:

{% if app.request.cookies.get('privacy_cookie') %}
    <script src="/path/to/analytics.js"></script>
{% endif %}

Keep the cookie name in one place (a parameter or config value) and reuse it in both the bundle config and the gating condition.

Override the template rather than the vendor code. For Symfony 2/3, copy the banner template into app/Resources/EzSystemsPrivacyCookieBundle/views/ (matching the original relative path) and edit there. This survives composer update and lets you add translation calls, change button markup, or point at a route:

<a href="{{ path('privacy_policy') }}">{{ 'cookie.more_info'|trans }}</a>

Theme via CSS overrides, not edits to bundle assets. Load your own stylesheet after privacycookie.css and override classes. Never modify files under web/bundles/... — assets:install will overwrite them.

Environment-specific configuration. Use config_dev.yml for a short or obvious dev message and config.yml for production copy. If you run multiple sites on one kernel, pass the message/link in via container parameters so each front controller can vary them.

Asset pipeline integration. If your app already uses Assetic, the bundle's optional Assetic config works, but it is brittle. On Symfony 3.4+ with Webpack Encore, skip the bundle's asset registration entirely and import the CSS/JS through Encore; just keep the banner partial and JS behaviour.

Avoid double banners if you already have consent tooling. If you're migrating from another cookie notice, check for its cookie first and suppress this one until the old cookie expires (or set the same cookie name during rollout).

Gotchas and Tips

• Archived and legacy. Last release was 2019-05-13, and it only advertises Symfony 2.6–3.x. On PHP 8 or Symfony 4+ you will likely hit signature/container issues. Budget time for a fork or a small reimplementation rather than assuming the Composer install will just work.
• License is NOASSERTION. Check the actual LICENSE file in the repository and get sign-off before shipping it in a commercial product.
• Assets path must exist. If the banner appears unstyled, confirm web/bundles/ezsystemsprivacycookie/ was created by assets:install and that your asset() base path matches your deployment (subdirectory installs commonly break here).
• Config key and units are easy to get wrong. The root key is ezsystems_privacy_cookie. Confirm the cookie_lifetime unit (days vs seconds) in Configuration.php — the README and the implementation can disagree — and verify by inspecting the cookie's Expires value in devtools.
• The banner is a notice, not a consent platform. It offers a single accept action, with no categories, no reject/withdraw UI, and no consent logging. Under strict GDPR/ePrivacy interpretations that is often insufficient; if you need granular consent, use the bundle only for the visual notice and build your own category state and script-gating layer on top.
• Client-side cookie setting is bypassable. Users with JS disabled or cookie-blocking extensions will see the banner on every request. Design your script gating so it fails closed (scripts off) when the cookie is absent.
• Debugging checklist: clear the cookie in devtools → confirm document.cookie after clicking Accept → check the network tab for 404s on the CSS/JS → cache:clear after config or template-override changes (in prod, ensure cache warmup runs in deploy).
• Template override location matters. Symfony 2/3 resolves app/Resources/<BundleName>/views/; if your override isn't picked up, check the bundle name casing and clear the cache. This resolution mechanism does not exist in Symfony 4+.
• Extension points are limited. Realistically you can override the template, the controller, and the CSS/JS. There is no pluggable consent model, so any richer behaviour (remembering per-category choices, a "manage preferences" link) has to be built alongside the bundle.
• Don't render it on error pages or in AJAX fragments. Guard with {% if not app.request.isXmlHttpRequest %} or keep it strictly in the main layout to avoid duplicated banners and unexpected cookie writes.