Gdpr Bundle Laravel Package

Getting Started

First, a reality check. fluffy-factory/gdpr-bundle is a Symfony bundle, not a Laravel package. It targets Symfony's kernel, DI container, and Twig — none of which you have in a Laravel app. With 2 stars, 0 dependents, and a last release of April 2021, treat it as a reference implementation to borrow from, not a composer require you'll run in production. If you're actually on Symfony 4/5, the steps below apply directly; if you're on Laravel, jump to the "Implementation Patterns" section and port the concepts.

Symfony install path

1. composer require fluffy-factory/gdpr-bundle (pin the 2021 release; verify PHP/Symfony version constraints in composer.json before committing).
2. Register the bundle in config/bundles.php.
3. Import the bundle's routing/config (typically @FluffyFactoryGdprBundle/Resources/config/routes.xml or similar) and set your categories under the bundle's config key — confirm the exact key in DependencyInjection/Configuration.php.
4. Publish/copy the bundle's JS + CSS assets into your public pipeline (the bundle predates modern Symfony AssetMapper, so expect manual assets:install or a copy step).
5. Render the cookie bar partial in your base layout, and mark third-party scripts with the bundle's consent attribute.

Where to look first

• The README (thin — skim it, don't trust it as complete).
• DependencyInjection/Configuration.php — the real source of truth for category names and options.
• Resources/views/ — the cookie bar markup you'll override.
• The shipped JS — how it detects consent, stores it, and unblocks scripts.

First use case: gate Google Analytics / GTM / Meta Pixel behind an "analytics" and "marketing" category so nothing fires until the visitor opts in. That single flow is 90% of why anyone installs this.

Implementation Patterns

The category model is the whole design. The bundle organizes cookies into named groups (typically required/functional, analytics, marketing) and stores the visitor's choice in a consent cookie. Every pattern below is a variation on "does this category have consent?"

Script blocking (client-side). The canonical pattern in bundles of this vintage: render tags as inert, then hydrate on consent.

<script type="text/plain" data-consent="analytics">
  /* GA snippet */
</script>

On consent, the bundle's JS rewrites type to text/javascript (or injects a fresh <script>). This is the pattern to replicate if you're porting to Laravel — and the one thing you must verify by reading the bundle's JS, because it's where the security and correctness live.

Server-side gating (the Laravel shape). Because you'll likely reimplement, design it as:

• config/gdpr.php — category definitions, cookie name, consent version, banner text.
• App\Support\CookieConsent — reads/parses the consent cookie, exposes allows('analytics').
• EnsureCookieConsent middleware — puts the consent object on the request.
• A Blade directive or component: @consent('analytics') ... @endconsent to conditionally render tracking tags server-side. This pairs with the client-side blocker for anything injected after page load.
• <x-cookie-banner> Blade component rendering the bar and posting to a POST /consent endpoint that writes the cookie and an audit record.

Consent as a record, not just a cookie. The bundle's cookie is a UI mechanism; GDPR wants evidence. Add a consent_log table (session id, categories granted, policy version, timestamp, IP if your DPO insists) and write to it on every accept/reject. Bump a policy_version constant and re-prompt when it changes.

GTM / Consent Mode bridging. Don't rely on the bundle to know about gtag('consent', ...). Map each category to ad_storage, analytics_storage, ad_user_data, ad_personalization, fire consent default (denied) before GTM loads, and consent update on choice. Consent Mode v2 became mandatory for EEA traffic in 2024 — this bundle predates it entirely, so this wiring is on you.

Withdrawal must be as easy as consent. Expose a persistent "Cookie settings" link that reopens the bar. The bundle's re-open hook (often a global JS function) is the extension point — confirm its name in the shipped JS and wrap it in a Blade component so it survives theme changes.

Gotchas and Tips

• Framework mismatch is the headline gotcha. Symfony DI, Twig extensions, and assets:install don't exist in Laravel. Attempting to shoehorn the bundle in via a Symfony bridge is more work than writing ~200 lines of Blade + middleware. Port, don't install.
• Abandoned since 2021. No Consent Mode v2, no support for the EDPB's 2023 pay-or-consent guidance, no CNIL-style "reject as easy as accept" defaults enforced. Audit the banner UX against current regulator guidance before shipping.
• 2 stars / 0 dependents means zero security review. The JS that unblocks scripts is an injection surface. Read it line by line; don't assume it sanitizes category names or handles a tampered cookie gracefully.
• Blocking must happen before third-party loads. If the bundle's JS sits at the footer, GTM may have already fired. Ensure the consent-default script is inline in <head> ahead of any tag manager.
• Full-page caching breaks naive banner rendering. If you render the banner server-side based on a cookie, your CDN will serve one visitor's state to another. Either vary the cache on the consent cookie, or render the banner unconditionally client-side and let JS hide it.
• Cookie attributes matter. SameSite=Lax, Secure, and a sane Max-Age (6–12 months, then re-ask). The 2021 defaults may be looser than you'd ship today.
• A banner is not compliance. You still need a cookie policy page, a lawful basis per category, DPAs with your processors, and a documented retention period. The bundle solves the UI, nothing else.
• Extension points to check in source: overridable Twig templates under Resources/views/, service decoration for the consent-checker, and any *_extension.js/event hooks the bundle fires on consent:change — that event is where you'll hook analytics re-init.
• Testing: assert the inert script renders with type="text/plain", that the consent cookie round-trips, that the middleware blocks server-side tags when the cookie is absent, and that re-opening the banner after accept still works. Feature-test the POST /consent endpoint for invalid category names.
• Accessibility and i18n: the shipped markup is likely English-only and may lack focus trapping and aria labels. Budget time to rebuild the banner as a proper accessible dialog and translate strings via your app's locale files rather than the bundle's.