Consent Bundle Laravel Package

Getting Started

• Install with composer require setono/consent-bundle. On Symfony Flex the bundle is auto-registered and a recipe usually drops a config file at config/packages/setono_consent.yaml; if not, add Setono\ConsentBundle\SetonoConsentBundle::class => ['all' => true] to config/bundles.php.
• Where to look first: the README is thin (4 stars, 0 dependents), so treat DependencyInjection/Configuration.php and the bundle's Resources/config/* as the real documentation. Run bin/console debug:config setono_consent and bin/console debug:container --tag=… to discover the actual config keys and service IDs before writing code.
• v1.2.0 adds a config option for the default consent checker. Use debug:config setono_consent to find the exact key (likely under default_consent_checker or similar) and set it to the checker service you want used by default, instead of wiring it manually.
• The bundle wires the framework-agnostic consent contracts into Symfony's DI/event system. That means the manager/service you inject is the contract interface — code against that interface, not the concrete class.
• First use case: gate a non-essential snippet (analytics, marketing pixels, embeds) behind a consent check. Wire a POST endpoint that records consent, inject the consent manager into the controller that renders the page, and conditionally render the snippet. Ship that one vertical slice before touching the banner UI or persistence options.

Implementation Patterns

• Check-before-act, everywhere. Don't scatter if (consent) { … } through templates. Inject the consent manager into the controllers/subscribers that own the side effect (setting a cookie, calling an analytics SDK) and guard at that boundary.
• Map your taxonomy to consent types once. Define categories (necessary, analytics, marketing, …) in config and treat them as the single source of truth. Both the banner template and the server-side guards should read from the same map.
• Use the new default consent checker config (v1.2.0). If you have a preferred checker implementation, register it as a service and point the bundle config at it. This keeps your checker selection declarative and avoids custom compiler passes or service decoration just to swap the default.
• Grant/revoke endpoint: a small controller that accepts the category set, records it via the manager, and returns redirect/JSON. Keep it idempotent so the banner can re-post on every toggle.
• Decorator pattern for third-party SDKs: wrap each SDK call in a thin service that consults the consent manager, then inject that wrapper. When consent logic or an SDK changes, you edit one class.
• Event subscriber for request-scoped consent: use a kernel.request subscriber to resolve consent state once per request and stash it on the request/manager, rather than re-reading cookies in every service.
• Twig glue: expose a twig.extension function (e.g. has_consent('analytics')) for template conditionals; keep the heavy logic server-side so views stay declarative.
• Laravel angle: the bundle itself is Symfony-only. If you're porting to Laravel, take the contracts package (framework-agnostic interfaces) and bind them in a ServiceProvider, then add a Blade directive/middleware mirroring the Twig extension. Don't try to boot the Symfony bundle in Laravel.

Gotchas and Tips

• Maturity risk is the headline. 4 stars, 0 dependents, single-maintainer Setono project, last release Jan 2025. Pin an exact version, subscribe to releases, and read each CHANGELOG — assume interfaces may shift between minor versions. v1.2.0 is additive (config for default consent checker), but verify the key and expected service type in Configuration.php before relying on it.
• Sparse docs → rely on the container. When you can't find a service, debug:container, debug:event-dispatcher, and reading services.php/services.yaml in the bundle are faster than guessing. Grep the bundle source for tags to find extension points. For v1.2.0, use debug:config setono_consent to confirm the default consent checker option name and default value.
• Config quirks: bundle configs often default to a specific cookie name/attribute or storage backend. Verify same_site, secure, and http_only defaults against your domain setup; a wrong SameSite silently drops server-side consent on cross-site navigations. Also verify that the default consent checker configured via v1.2.0 actually implements the expected contract/interface.
• Persistence vs. page cache: if you cache rendered pages, the consent banner state must be client-side (or a cached-fragment ESI), or visitors will see stale banner/opt-in state. Server-side enforcement should never trust a cached HTML decision.
• Don't treat it as a compliance silver bullet. The bundle records and exposes consent; it does not implement IAB TCF, jurisdiction logic, or audit retention. Own that policy layer yourself.
• Testing: bind the consent manager to a fake in functional tests so consent state doesn't leak between requests, and add one test per category that asserts a blocked third-party call is skipped without consent. Add a test that your configured default consent checker (v1.2.0) is the one actually used.
• Extension points to prefer: decorate the consent manager contract, add a custom storage/persistence adapter, and use listeners — these survive upstream changes better than subclassing bundle internals or overriding templates. Prefer the new config option for the default checker over hard-coding service overrides.
• Debugging tip: if consent "doesn't stick", log the resolved consent at the start of the request in a dev subscriber; most issues are a missing cookie attribute, a session reset, or the manager being resolved before the subscriber runs. Also confirm which default consent checker is active via debug:container after changing the v1.2.0 config.