Alt Cookies Laravel Package

Technical Evaluation

Architecture fit. alt-design/alt-cookies is not a general-purpose Laravel package — it is a Statamic addon ("Easy Cookies and Google Analytics for Statamic"). Its value proposition is a consent banner plus Google Analytics wiring delivered through Statamic's addon lifecycle (service provider registration, config/views publishing, Antlers tags or Blade components, Control Panel settings screen). That means the real integration boundary is Statamic's runtime, not Laravel's. Fit is therefore binary: strong if our product is a Statamic site (or a Statamic-driven marketing/content surface), and effectively zero if we are evaluating it for a conventional Laravel application, an Inertia/Livewire SPA, or a headless API. Before any evaluation effort is spent, confirm whether Statamic is in the target stack — this single fact determines whether the package is a candidate or a non-starter.

Integration feasibility. Where Statamic is present, integration remains shallow and low-effort: composer require, publish config/views, inject the consent component into the layout, and configure the GA measurement ID through the CP. There is no data model of consequence, no migration surface, and no API contract to negotiate, so "time to first banner" is measured in hours. The v1.3.2-alpha release widens scope in a way that matters to the buy-vs-build calculus: a Control Panel cookie scan that renders the site's pages to observe cookies set by both JavaScript and the server, policy copy generated from that scan and formatted for Bard with a preferences-reopen link hook, no-reload application of accept/reject, a default consent state (no longer loaded twice), and a new updateConsent() JS API. That closes part of the gap the previous assessment flagged — cookie discovery and policy-drafting were previously on our side of the line — but it does not make this a consent management platform: there is still no vendor/tag registry, no stated consent-record retention for auditability, and no multi-jurisdiction category model beyond what the banner exposes. Requirements beyond "banner + GA gate + cookie inventory" still land on us.

Technical risk. The dominant risk remains signal quality, and the new release sharpens rather than resolves it. Four stars and zero dependents still means no production evidence. The v1.3.2 release is an alpha on a pre-release line: sites on stable 1.2 are unaffected unless they explicitly ask for an alpha, which is correct Composer hygiene but also means the new capabilities (scan, policy copy, no-reload, updateConsent()) are only available on code with no stable track record — and those same capabilities would sit inside a compliance-bearing component. Positively, active development on the 1.3 line is evidence against the abandonment concern raised earlier; the changelog is disciplined and versioned, and the notes explicitly state nothing in the public JS API has been removed or renamed since v1.2.7, so there is no breaking change and no forced migration. Statamic addons remain tightly coupled to Statamic's major cadence (CP, publishing conventions, Antlers), so low adoption still implies elevated silent breakage risk on upgrade. New risks introduced by this release: (a) the cookie scan executes the site's own pages server-side — a crawler that renders pages has load, environment-targeting, and potentially credential/PII exposure implications that did not previously exist; (b) auto-generated policy copy is a legal artifact produced by a tool, and unreviewed generated text is a compliance liability that looks like compliance; (c) the default consent state addition is suggestive of Consent Mode-style default/update semantics but is not evidence of Consent Mode v2 — whether analytics_storage/ad_storage are denied pre-consent, and whether updateConsent() maps to a Consent Mode update call, is still unverified and is the single most important thing to test; (d) no-reload application means consent state changes at runtime, so gating correctness on change and withdrawal (not just first load) now needs explicit testing. The anomalous "last release 2026-09-30" timestamp should still be reconciled against actual tag history.

Key questions.

• Is the target application actually a Statamic site, and which Statamic major version?
• Does the addon implement Google Consent Mode v2 — specifically a consent default with analytics_storage/ad_storage denied before interaction — or only conditionally inject the GA snippet? Does updateConsent() issue a Consent Mode update?
• What exactly does the new "default consent state" set, and is it aligned with the Consent Mode default call or a parallel mechanism that could fire twice or conflict?
• When does 1.3 reach stable, and what is the supported/patched window for the 1.2 line while 1.3 is alpha-only?
• What does the cookie scan target — production URLs, a configurable base URL, staging? Does it authenticate, does it persist response bodies or observed PII, what is its request concurrency and load profile, and can it be disabled in production?
• Is generated policy copy presented as a reviewed template or as legally adequate text, and who signs off on it?
• How is consent persisted and re-validated (cookie lifetime, versioning of the consent text, withdrawal/change flow, server-side or client-side only) — and does no-reload application correctly handle tags already fired pre-consent?
• Does it support granular categories (necessary/preferences/statistics/marketing) or a single accept/reject gate?
• Are consent records retained for auditability, and in what form?
• Who maintains the addon, what is the release cadence against Statamic majors, and is there any commercial support path?
• Is the license (MIT) compatible with our redistribution/hosting model — and does MIT imply we own all compliance obligations for the banner's behavior?

Integration Approach

Stack fit. Qualifies only for Statamic-based surfaces: a marketing site, docs portal, or content-led product front end running Statamic on Laravel. It does not fit a general Laravel app, and it should not be pressed into one by copying views out of the addon — that converts a supported dependency into a fork we maintain, which is the worst of both worlds. The v1.3.2 features (cookie scan, policy copy, updateConsent()) increase the temptation to build on the addon rather than around it. Resist that unless Statamic is confirmed: the richer the surface we depend on, the more expensive the exit. If the target is a non-Statamic Laravel property, evaluate a consent-management library or SaaS instead.

Migration path. Two realistic entry paths. (1) Greenfield — install, publish config/views, wire the banner into the base layout, set the GA ID via CP, ship. (2) Replacement of a hand-rolled banner or hardcoded GA snippet — the work is less installation than sequencing the cutover: the old unconditional GA tag must be removed in the same deploy that the gated tag lands, or we briefly run both and the compliance posture degrades. Treat the existing snippet inventory (GTM containers, pixels, heatmaps) as the migration backlog; the new cookie scan is a useful accelerator for building that inventory, but it only observes cookies — it will not enumerate non-cookie tags or server-side pixels, so it complements rather than replaces manual audit. Upgrade path from 1.2.x to 1.3 is explicitly non-breaking (no removals or renames since v1.2.7 or v1.3.1-alpha), so the only decision is when to leave the stable line, not whether the code will conflict.

Compatibility. Three axes to pin down before commit. First, Statamic major version and the Laravel/PHP versions declared in composer.json. Second, release channel discipline: 1.3.x is alpha-only, so any adoption must pin explicitly (exact alpha constraint) and must not be allowed to float into a build via a permissive stability flag — an alpha regression inside a consent component is exactly the failure we cannot afford. Third, front-end delivery and CSP: verify whether the banner ships as an Antlers partial, Blade view, or published view, and whether it injects inline scripts; the new no-reload behavior likely means additional runtime JS, and the policy "link hook" implies a client-side reopen handler — both are common CSP breakage points. Confirm no conflict with an existing GTM container: gating GA directly while GTM also fires GA produces contradictory consent signals.

Sequencing. (1) Confirm Statamic in stack and version parity — a half-day spike, decide go/no-go here. (2) Decide channel: default to stable 1.2.x unless a specific 1.3.2 capability (scan, policy copy, no-reload, updateConsent()) is a hard requirement; if it is, accept and document that we are running pre-release code in a compliance-bearing path. (3) Legal/compliance review of the banner's category model and consent text against our jurisdiction footprint — and now also review scope for generated policy copy, which must be treated as a draft, never as approved text. (4) Technical spike in staging: install, verify pre-consent network behavior in devtools (no GA hits, _ga absent), verify post-consent tagging, verify withdrawal and change without reload, and verify the default consent state is applied exactly once. (5) If enabling the cookie scan, run it against staging first and characterize its load and data handling before it ever touches production. (6) Remove legacy unconditional tags in the same change set. (7) Roll to production behind a short observation window with analytics QA, then retire parallel consent tooling. Do not begin at step 4.

Operational Impact

Maintenance. Ongoing maintenance is modest in absolute terms but not zero, and it is externally gated: the addon must track Statamic majors, and its cadence is not under our control. Budget a periodic compatibility check on every Statamic upgrade rather than a continuous load. Active 1.3 development is reassuring on responsiveness but introduces a new maintenance obligation: if we adopt the alpha line we are effectively tracking a moving pre-release, and we should expect churn between alphas. Because adoption is near-zero, assume we will be the ones who discover breakage, and be prepared to vendor-patch or fork if the maintainer goes quiet — a contingency that should be explicitly accepted by a named sign-off, not discovered mid-upgrade. The generated policy copy adds a recurring review duty: every regeneration must be diffed and approved, or the published policy silently drifts from observed reality.

Support. No evidence of commercial support, SLAs, or a meaningful community, and the alpha channel has no support expectation at all. Internal ownership must be named: someone owns the consent banner as a compliance-bearing component, reviews consent-text and generated-policy changes, and responds to regulatory shifts (Consent Mode requirements, national DPA guidance). New in this release, someone must also own the cookie scan operationally — when it runs, what it targets, and who reads the report. This governance cost exists regardless of how small the package is, and it is the line item most often missed when a four-star addon is adopted on the strength of "it's only a banner."

Scaling. The banner itself is technically trivial — client-side UI plus a tag; it does not touch request-path throughput, queues, or storage. The cookie scan changes that picture locally: it drives page renders against the site, so it has a real, if bounded, load signature and should be treated as an operational job with an owner, not a button. The other scaling concern is organizational: the banner must be correct across every locale, domain, and subdomain, and consent state does not reconcile across them; multi-site Statamic installs must verify per-site behavior explicitly rather than assume inheritance. Generated policy copy likewise needs a per-site review, since a scan of one site will not describe another.

Failure modes. Ranked by consequence: (1) silent over-collection — the banner renders, consent appears handled, but GA fires pre-consent due to config, placement, or a broken default state; highest severity because it is invisible and legally material, and it must be caught by automated pre-consent network assertions in CI/staging, not manual QA. (2) No-reload re-application bug — accept/reject applies on change, so a defect in the runtime path can leave previously gated tags firing after withdrawal, or fail to apply the choice at all; this is newly reachable in 1.3 and needs explicit test coverage. (3) Addon breakage on Statamic upgrade — banner stops rendering or CP settings vanish, leaving no consent UI or an ungoverned tag. (4) Alpha regression in a compliance component — the cost of adopting 1.3.2 before stable. (5) Cookie-scan side effects — unintended production load, crawling of authenticated or preview surfaces, or retention of page content; constrain and disable where not needed. (6) Generated-policy drift — auto-written policy text published without review, or stale after a feature change, creating documented non-compliance of the worst kind: a written policy that contradicts observed behavior. (7) Fork divergence if we patch locally. (8) CSP/JS conflicts with existing tag management. Mitigation for (1), (2), and (3) is the same: a small synthetic check run on every deploy asserting no analytics requests occur before consent, that withdrawal stops them, and that the banner rendered at all.

Ramp-up. Very fast for a Statamic-fluent engineer — hours to a working banner in staging. The real ramp-up is cross-functional: legal/compliance review of consent categories and copy (now including review of generated policy text) and analytics review of what GA configuration must accompany it (Consent Mode, data retention, IP handling). Estimate one engineering day for the spike and integration, plus a compliance review cycle that is calendar-bound rather than effort-bound, plus a short characterization exercise if the cookie scan is enabled. The overall recommendation remains conditional: proceed if and only if Statamic is in the stack and the spike confirms Consent Mode v2 behavior; otherwise reject on architecture-fit grounds rather than quality. If approved, default to stable 1.2.x, and adopt 1.3.2-alpha only for a named capability and only with an exact pin, an explicit acceptance that pre-release code sits in a compliance path, and a plan to move to 1.3 stable when it ships. Treat the addon as a small dependency we are prepared to own — not a supported platform component.