Tracking Code Manager Laravel Package

Technical Evaluation

Package context. simonridley/tracking-code-manager is a Statamic addon (Statamic runs on Laravel, so it ships as a standard Composer package with a service provider, config, routes, and CP views). Its function is narrow and well-understood: let editors register tracking snippets (GA4, GTM, Meta pixel, etc.) in the Control Panel and inject them into rendered site output, typically via an Antlers tag/partial and per-environment or per-site scoping.

Architecture fit. Good. The addon follows the conventional Statamic addon shape — no separate datastore, no external service dependency, config-driven, output-only. That means it sits at the edge of the render pipeline rather than in the request/domain path. For a TPM this is the cheapest possible integration class: no data model ownership, no write paths, no queue or job surface.

What v1.0.2 actually changes. A single PR (#8) updates cp.php routes to use "the right middleware," released as a patch with the headline "Fixes for Statamic 4." Reading between the lines: the Control Panel routes were previously registered with incomplete/incorrect middleware under Statamic 4, which in a CP context means authorization and web-session middleware. This is a correctness and potentially a security-adjacent fix, not a feature. It also confirms the addon was effectively broken or degraded on Statamic 4 until now.

Technical risk. Low-to-moderate, mostly non-technical:

• Semver hygiene is fine but the fix class is a warning. A route-middleware defect surviving into a tagged release suggests thin automated coverage of CP route registration. Treat v1.0.1 as unsuitable for Statamic 4 and v1.0.2 as the first viable Statamic 4 release.
• Governance/bus factor. Single maintainer plus one first-time contributor. No evidence of CI matrix, no stated support policy, no security contact in the notes. For an addon that injects third-party JavaScript into production pages, that matters more than for a utility package.
• Blast radius if it misbehaves is customer-facing, not internal. Broken snippets mean missing analytics (silent data loss) or, worse, injected scripts on CP/error pages.
• No breaking changes indicated. Patch-level, route-only.

Key questions to resolve before adoption:

1. What middleware was added — is it Statamic::cp()-style auth/web, and does it now correctly enforce CP authorization for non-super users?
2. Exact support matrix: Statamic 3 vs 4, PHP versions, Laravel versions. Is Statamic 3 still supported or has the branch moved on?
3. Multisite behavior: are snippets scoped per site/locale, and how is inheritance handled?
4. Rendering surface: does the tag output on CP routes, error pages, and 404s, or only front-end site requests?
5. Consent/GDPR: is there any built-in consent gating or ordering guarantee, or is that entirely on us?
6. Test coverage and whether a fork/vendor policy is needed.
7. Is config publishable and cache-safe (php artisan config:cache, route:cache)?

Integration Approach

Stack fit. Clean. Install is composer require simonridley/tracking-code-manager, publish config, add the Antlers tag or partial to the layout. No database migrations expected, no external credentials, no API calls. It occupies a slot we would otherwise fill with hand-rolled Antlers conditionals and a YAML/blueprint — so it replaces bespoke code rather than adding a new dependency class.

Migration path.

• Net-new adoption: pin to ^1.0.2 explicitly. Do not allow ^1.0.0, since 1.0.0/1.0.1 carry the broken CP routes on Statamic 4.
• From a hand-rolled solution: inventory existing hardcoded snippets first, migrate them into the CP as data, and keep both paths behind a feature flag for one release cycle so you can diff rendered <head> output before switching off the old include.
• From v1.0.1: drop-in patch, but verify CP access immediately after deploy — the middleware change affects route registration, so a stale route cache can mask it.

Compatibility. Confirm the Statamic major version on each property before rollout; this release is explicitly a Statamic 4 fix, so treat Statamic 3 sites as a separate decision with a separate version constraint. Verify PHP version against the addon's composer.json rather than the README.

Sequencing.

1. Local install, publish config and views, confirm CP nav entry and route access as a non-super CP user.
2. Deploy to staging; clear config:cache, route:cache, and Statamic's static/content caches; confirm the tag renders and that CP routes still resolve.
3. Diff rendered HTML against current production output — same scripts, same order, same placement in <head>.
4. Run a CSP and tag-manager audit (see failure modes).
5. Production rollout per site, starting with the lowest-traffic property.
6. Enable per-environment snippet config (e.g., suppress on staging) before the second site, not after.

Operational Impact

Maintenance. Minimal ongoing effort — config and content data only, no schema, no scheduled jobs. The real maintenance cost is dependency hygiene: pin the version, watch the repo for Statamic 5 readiness, and be prepared to vendor or fork if the maintainer goes quiet. Given the single-maintainer profile, a fork is a realistic contingency for a package this small.

Support. Community-only: GitHub issues, no SLA, no security disclosure process documented in the release notes. Set internal expectations accordingly; do not treat vendor responsiveness as an input to the timeline. Assign an internal owner so CP questions from editors don't dead-end.

Scaling. Output injection is O(1) per request and effectively free. The scaling concerns are all caching-related, not compute-related:

• Statamic's static/response caching will bake snippets into cached HTML; changing a snippet in the CP must trigger a cache invalidation, or editors will report "my change didn't apply." Validate this behavior explicitly.
• CDN/edge caches need a purge strategy keyed to snippet updates.
• Multisite multiplies the number of snippet records to keep consistent; a per-site QA checklist is worth more than tooling here.

Failure modes to design for.

• CP route breakage (the exact class fixed in 1.0.2) — mitigate by asserting CP health checks post-deploy and testing as a non-super user.
• Snippet leakage onto CP/error/404 pages — verify the tag is only in front-end layouts, and treat any CP injection as a security incident, not a cosmetic bug.
• CSP violations — new snippet domains (googletagmanager.com, connect.facebook.net) will be blocked by a strict CSP. Coordinate with the security owner before enabling, and prefer adding nonces/hashes over loosening script-src.
• Consent and privacy — injecting analytics without consent gating is a compliance exposure in the EU/UK. This addon is a delivery mechanism, not a consent manager; pair it with one and document the order of operations.
• Silent data loss — a snippet that fails to render produces no error, just a gap in analytics. Add a synthetic check that asserts key script markers are present in production HTML.
• Cache staleness after CP edits — the most likely day-two support ticket.

Ramp-up. Low. Developers need ~30 minutes (Composer install, config publish, Antlers tag placement). Editors need a short walkthrough of the CP form and the environment/site scoping rules — the main risk is an editor pasting a production tag into staging or duplicating a snippet across sites. Budget half a day total including the CSP and consent review, which is the only part that requires cross-team coordination.