Statamic Activecampaign Laravel Package

Technical Evaluation

Architecture fit This is a Statamic add-on riding on Laravel's service container, cache, and serialization layer — it introduces no new runtime service, datastore, or queue. It hooks the correct extension point: Statamic's registerSerializableClasses API, which is the sanctioned way to declare allowlisted classes for Laravel 13's hardened cache unserialization. Architecturally this is a low-surface-area dependency that fits any Statamic-based Laravel application and does not constrain how we structure our own code.

Integration feasibility Feasible in a single sprint if we are already modern: PHP 8.3+, Statamic 6.5+, Laravel 12 or 13. The blocker profile is entirely version-floor driven — PHP 8.2 hosts or Statamic 6.0–6.4 are hard-incompatible with no shim path. Composer is the only integration surface; no migrations or config publishing are called out in the release, though form-bearing add-ons typically need a cache/config step. The fix itself (a registered allowlist) is a few lines of framework wiring, not an architectural change.

Technical risk Medium-low overall, but the risk is concentrated rather than diffuse:

• Version floor as a breaking change. Raising PHP to 8.3 and Statamic to 6.5 is a hard break shipped under a minor version number (3.4.0). That is a semver signal mismatch: a ^3.0 constraint allows the upgrade to land automatically during a routine composer update on a host that cannot satisfy the new floor. Expect a resolver failure at best, a mid-deploy surprise at worst.
• Serialization allowlist is security-sensitive surface. Registering classes for cache deserialization widens what unserialize will accept from the cache backend. If the allowlist is scoped narrowly to FormConfig types, risk is negligible; if it is broad or generic, we are depending on cache integrity as a trust boundary.
• Patch-shaped fix with upgrade-shaped blast radius. The deserialization fix implies existing cached payloads are already broken or will be. A warm cache carried across the deploy is a live failure path.
• Laravel 13 support claim. Worth confirming whether this targets a stable Laravel 13 or a pre-release. "Support" against an unreleased major is a forward-compatibility statement, not a stability guarantee.

Key questions

1. Is the serializable-class allowlist explicitly enumerated to FormConfig types only, or does it include a wildcard/parent namespace?
2. Do previously cached FormConfig entries deserialize after the upgrade, or is a cache flush mandatory? If mandatory, is that documented?
3. Are there other add-on classes passing through the cache that the allowlist does not cover (fieldtypes, submission payloads, settings)?
4. Is Statamic 6.5 a hard constraint or merely the first version tested? Can 6.5.x–6.9.x drift safely?
5. Is Laravel 13 GA at the time of this release, and is 3.4.0 tested against Laravel 11 and below or is that support formally dropped?
6. Why is a version-floor change shipped as a minor rather than a major? Is 3.3.x receiving security backports?

Integration Approach

Stack fit Target state: PHP 8.3–8.5, Laravel 12 or 13, Statamic 6.5+, add-on ^3.4. This aligns cleanly with a Statamic-centric Laravel estate. It does not fit any platform still on PHP 8.1/8.2, Laravel 10/11, or Statamic 5 — those consumers must stay on 3.3.x and accept that they are now on an unmaintained track unless the vendor commits otherwise.

Migration path

1. Confirm runtime PHP ≥ 8.3 across all app servers, queue workers, and CI runners — not just the build image. CLI and web often drift.
2. Upgrade Statamic to ≥ 6.5.0 first; it is the gating dependency for Laravel 13 support.
3. Upgrade Laravel to 12 or 13 (13 last, and only if GA).
4. Bump the add-on to ^3.4.
5. Flush and rebuild all caches as a mandatory, coordinated deploy step: cache:clear, config:clear, Statamic stache clear/warm. Treat the cache as part of the release artifact, not as durable state.
6. Smoke-test form rendering, submission, and FormConfig resolution on a cold cache and a warm cache.

Compatibility The CI matrix (PHP 8.3/8.4/8.5 × Laravel 12/13) is genuinely good coverage for the supported envelope and gives us confidence in the floors. Gaps: no stated coverage for older Statamic 6.5.x patch levels, no OS/webserver variance, and no indication of static analysis or deprecation-warning cleanliness on PHP 8.5. PHP 8.5 support is asserted via CI, which is stronger evidence than a changelog claim.

Sequencing Runtime → Statamic → Laravel → add-on → cache flush → verification, in that order, with a rollback that pins 3.3.*, restores the prior PHP/Statamic pair, and clears cache again. Because the failure mode is cache-resident, rollback without a cache flush will not actually restore service — that must be written into the runbook explicitly.

Operational Impact

Maintenance Low steady-state effort — the add-on has no independent infrastructure and its cadence tracks Statamic/Laravel releases. The real maintenance cost is tracking: this release demonstrates the maintainer moves the version floor in lockstep with upstream, so every Laravel major will force a coordinated platform upgrade on our side. Budget for that as recurring, not incidental.

Support Single-vendor, likely small-team dependency. Two support questions materially affect us: whether 3.3.x gets security backports, and whether breaking version floors will keep arriving as minor bumps. If the answer to either is unfavourable, we should treat the add-on as a pinned dependency with a planned upgrade window rather than an auto-updating one, and consider vendoring or forking given the small surface area.

Scaling No scaling concerns: the deserialization path is a per-request cache read with no added I/O, and the allowlist registration is boot-time only. Behaviour is uniform across horizontally scaled instances as long as the cache backend is shared — which is also the risk vector, since a single poisoned or stale shared cache entry affects the whole fleet at once rather than degrading gracefully.

Failure modes

• Hard boot failure if the runtime cannot satisfy PHP 8.3 / Statamic 6.5 after an unattended composer update — caught at deploy, but only if staging mirrors production's PHP version.
• Stale-cache deserialization errors on FormConfig entries immediately post-deploy; presents as broken forms or exceptions on form pages, not as an install error. Highest-likelihood incident for this release.
• Silent config degradation — if a FormConfig fails to deserialize and the failure is swallowed, forms may render with defaults or empty fields rather than erroring. Worse than a hard failure; needs an explicit smoke test asserting field presence.
• Allowlist over-breadth turning the cache into an unexpected trust boundary; low probability, high severity, entirely dependent on answer to key question 1.
• Laravel 13 pre-release drift if we adopt against a non-GA framework and the cache serialization contract shifts before GA.

Ramp-up Minimal for anyone competent in Laravel — the integration is a composer bump plus a cache flush. Effective ownership does require Statamic literacy (stache, FormConfig, add-on registration) and, for this specific release, enough framework-internals familiarity to reason about cache serialization and allowlisting. Assign an owner who can read the registerSerializableClasses implementation rather than treating it as a black box; that is the one place this dependency can hurt us.