Statamic Cookie Dialog Laravel Package

Product Decisions This Supports

• Build vs. buy for consent management. This is a Statamic addon that provides a cookie consent dialog, so the real decision is whether to buy/install a prebuilt consent layer versus building consent UI + preference storage in-house. For most teams, consent UI is undifferentiated work with legal exposure — a strong candidate to buy.
• Multi-site / multi-locale rollout planning. v3.0.4 adds Multi-Site support, which is the release that makes this package viable for Statamic installations serving several sites or domains from one control panel. If multi-site was previously a blocker on the roadmap, that blocker is now removed — worth re-scoring against alternatives.
• Market and regional expansion. Consent obligations differ by jurisdiction (GDPR/ePrivacy in the EU, CCPA/CPRA in the US, and others). Per-site consent configuration lets you ship region-specific banners, copy, and cookie categories without forking the codebase — a prerequisite for launching into new markets.
• Compliance-adjacent roadmap sequencing. Cookie consent is typically the entry point to a broader privacy workstream (privacy policy surfacing, consent logging, tag/script gating, data subject requests). Choosing this package now determines how much of that later work you inherit versus integrate.
• Scope discipline for engineering. Installing a maintained addon frees engineering capacity for product-differentiating work. The trade-off is a dependency on a third-party vendor's release cadence and on Statamic's major-version lifecycle.
• Consent UX as a conversion lever. Banner design, blocking behavior, and granularity of categories affect bounce rate and opt-in rates. Treat banner configuration as a product surface with A/B-testable choices, not purely a legal checkbox.

When to Consider This Package

Consider it when:

• The stack is Statamic (not plain Laravel) — this is an addon, so it assumes Statamic's control panel, templating, and addon ecosystem. On a non-Statamic Laravel app it is the wrong shape of dependency.
• You run or plan a multi-site Statamic setup. Before v3.0.4 the multi-site gap was a legitimate reason to look elsewhere; that objection is now addressed, so re-evaluate if you previously ruled it out on those grounds.
• You want consent handled within the CMS — editable copy and configuration by content/marketing editors rather than hardcoded strings shipped by engineering.
• Your consent requirements are standard — cookie categories, accept/reject, preferences, per-site configuration.
• You are comfortable with an open-source, vendor-maintained addon and the implied support model (community issues, vendor release cadence) rather than a contractually backed SaaS CMP.

Look elsewhere when:

• You need a certified, audited CMP with consent receipts, vendor lists, geo-detection, IAB TCF support, or legally defensible audit trails. A CMS addon is generally not that, and you should not represent it as such to legal or compliance stakeholders.
• You require SLA-backed support, indemnification, or a vendor who will attest to regulatory changes on a schedule.
• Your architecture is decoupled — headless/frontend-framework rendering, multiple frontends, or non-Statamic properties that also need consistent consent behavior. Consent needs to live where the tags fire.
• You need server-side or tag-manager-level enforcement of consent state (e.g., gating scripts before they load across many properties).
• The maintenance risk is unacceptable: verify the addon's release history, open-issue backlog, and compatibility with your Statamic and PHP versions before adopting. A single-maintainer dependency in the compliance path carries continuity risk.

How to Pitch It (Stakeholders)

To executives: We can handle cookie consent with a maintained, open-source Statamic addon instead of building it. The latest release adds multi-site support, which means one installation can serve consent banners across all our sites and locales — this was the main thing holding us back from standardizing. It reduces legal-risk surface area and removes custom code we'd otherwise own and maintain. It is not a substitute for a certified enterprise consent platform; if legal requires audited consent records or an enterprise CMP, we should budget for that separately, and I'd want that requirement stated explicitly before we commit.

To engineering: Low-cost integration if we're on Statamic. It's an addon, so it inherits the CMS's multi-site model — per-site consent configuration comes for free as of v3.0.4. Before we adopt, I want three things confirmed: current Statamic and PHP version compatibility, the maintenance health of the repo (release cadence and open-issue backlog), and how consent state is exposed to templates so we can gate analytics and marketing tags correctly. Budget a small spike to validate tag-blocking behavior, since that's where consent implementations usually fail.

To legal/compliance: This gives us a configurable consent banner with categories across our sites. It does not, on its own, constitute a compliance program — we still need to define cookie categories, retention, and whether we require consent logging. Flag any requirement for auditable proof of consent now, because that changes the buy decision.