Statamic Cookie Dialog Laravel Package

Technical Evaluation

Architecture fit. emplify-software/statamic-cookie-dialog is a Statamic addon (Composer package, Laravel service provider, Antlers tag + publishable views/config) rather than a standalone Laravel package. That distinction matters for scoping: it fits cleanly into Laravel applications where Statamic owns the front-end rendering layer (marketing sites, content-driven storefronts), and fits poorly in API-only or non-Statamic Laravel services. The v3.0.4 addition of Multi-Site support aligns the addon with Statamic's native multi-site model (per-site locales/domains, site-scoped content trees), which is the correct architectural direction for any consent widget that renders per-domain.

Integration feasibility. Low effort. Standard path is composer require, rely on package auto-discovery, publish config/views, and drop the consent tag into the base layout. Multi-site does not change the installation mechanics; it changes configuration surface — the addon must now resolve which site's settings, translations, and cookie scoping apply at render time. Expect a small amount of per-site config authoring (cookie name/domain, banner copy/localization if offered, consent categories) rather than new code.

Technical risk.

• Versioning hygiene: multi-site is a capability expansion shipped in a patch release (3.0.3 → 3.0.4). That is defensible only if the feature is strictly additive and inert for single-site installs. We cannot confirm that from the notes alone, and it weakens the signal we normally use to decide how much regression testing a bump deserves.
• Compliance sensitivity: cookie consent is a GDPR/ePrivacy-adjacent surface. Silent fallback to a default site's configuration — wrong banner copy, wrong cookie name, wrong category set — is a legal-exposure defect, not a cosmetic one. This is the highest-severity risk introduced by the release.
• Consent scoping ambiguity: unclear whether consent state is stored per-site or shared via a parent cookie domain. Both are legitimate; they have materially different implications for audit and for users crossing subdomains.
• Cache interaction: Statamic's static/response caching keyed per site means a mis-scoped config can be cached and served to the wrong domain.

Key questions.

1. Is 3.0.4 additive-only, or does it alter config schema, published views, or the consent cookie format? Any of those would argue for treating this as a minor/major bump.
2. In a multi-site install, is the fallback for an unconfigured site explicit-and-loud, or silent-to-default?
3. Is consent state scoped per site, per domain, or shared across the site group?
4. What is the supported Statamic/Laravel version matrix, and is multi-site covered by the maintainer's test suite?
5. Who is the upstream maintainer (single-vendor addon) and what is the release cadence and issue-response history?

Integration Approach

Stack fit. Requires a Statamic-backed Laravel app. Confirm Statamic major version compatibility before scheduling work — addons commonly pin to a Statamic major, and a mismatch here is the most likely blocker. Multi-site support presumes the Statamic multi-site config (sites: in config/statamic/sites.php) is already established; if our multi-site rollout is not yet live, this feature is inert for us and 3.0.4 is effectively a no-op upgrade.

Migration path. For single-site installs: low-risk composer bump, verify published views/config are unchanged, smoke-test banner render and consent persistence. For multi-site installs: bump, then explicitly author per-site configuration and verify each domain independently. Do not assume the upgrade "just works" per site — the failure mode is a correct-looking banner with the wrong configuration.

Compatibility. Two axes: Statamic/Laravel version, and our own consent-policy content per locale. The second is organizational, not technical, and is usually the longer pole — localized banner copy and category definitions need legal/compliance sign-off per market, which can outlast the engineering work.

Sequencing.

1. Confirm Statamic version compatibility and read the PR #22 diff (small, reviewable) to answer the fallback/scoping questions.
2. Upgrade in a staging environment with a representative multi-site config (at least two sites with distinct domains).
3. Verify per-site render, per-site consent persistence, and cache behavior per domain.
4. Localize/authorize banner content per market.
5. Production rollout, single-site first, then multi-site domains in waves.

Operational Impact

Maintenance. Low ongoing code footprint, but the addon is single-vendor and low-velocity — a small dependency we should track explicitly rather than assume is maintained. Pin the version in composer.json and treat upgrades as deliberate, reviewed changes rather than routine composer update drift.

Support. Support burden shifts from engineering to content/compliance: once multi-site is configured, per-market banner copy and category definitions become an ongoing editorial and legal-review obligation. Establish ownership up front, otherwise consent content silently ages out of date as markets are added.

Scaling. Rendering cost is negligible. The scaling concern is combinatorial: N sites × M locales × K consent categories of configuration to keep correct, plus cache keys that must include site context. Complexity grows with the site matrix, not with traffic.

Failure modes.

• Silent site fallback — wrong banner served on a domain; compliance exposure, no visible error. Highest severity.
• Consent state bleed — consent granted on one domain honored or ignored on another unexpectedly.
• Cache mis-keying — one site's banner cached and served on another.
• Config drift after upgrade — published views/config diverging from the package's, causing subtle render issues.
• Version pin breakage — a future Statamic major leaving this addon behind, forcing either a fork or a replacement.

Ramp-up. Minimal for a Laravel/Statamic-fluent engineer — hours, not days. The real ramp-up is cross-functional: compliance/legal must review per-market consent copy, and whoever owns the multi-site content model must own the per-site configuration. Budget review cycles, not engineering cycles. Recommend an explicit per-domain acceptance checklist (render, cookie name/domain, consent persistence, cache) as the definition of done for the multi-site rollout.