Statamic Form Settings Laravel Package

Technical Evaluation

• Architecture fit: This is a Statamic add-on (Laravel package under the hood) rather than a standalone Laravel library. That matters: it ships a service provider, hooks into Statamic's add-on lifecycle, and relocates site form settings out of core into the add-on behind per-feature switches. Fit is good for teams already standardized on Statamic, but it is a complement/shadow of core behavior, not a greenfield component — the value is entirely dependent on how tightly it couples to Statamic's settings model.
• Integration feasibility: Installation is standard Composer + auto-discovery. The real integration work is not installation but settings relocation: existing sites have form settings in the site/config layer, and v0.1.0 moves them behind switches. Whether that is a transparent read-through or a hard cutover is the single biggest unknown and is not answered by the release notes.
• Technical risk: Moderate. Three compounding factors: (1) v0.1.0 — pre-1.0, no semver stability commitment, API and config keys can move; (2) core-adjacent override — anything that re-homes native Statamic form settings is exposed to breakage on Statamic minor upgrades; (3) single-organizational maintainer (UAMS-Web), so upstream responsiveness is not contractual. Counterweight: the release shows genuine engineering hygiene — aggregate required CI check, mutation-instrument job, synced-files job — which is a positive signal for a 0.1.0.
• Signal-to-noise caveat: Of the eight shipped PRs, only #16 is functional. Everything else is CI, tooling, dependency bumps, and shared skills/rules sync. The assessment rests on one feature PR, so treat the functional surface as largely unproven.
• Key questions:
  • Do the per-feature switches live in publishable config, the control panel, or env? Who can flip them, and is there an audit trail?
  • Does the add-on override, mirror, or migrate core form settings? Is there a read-through fallback if the add-on is disabled?
  • What are the declared constraints for PHP, Laravel, and Statamic versions — and is there a support matrix beyond composer.json?
  • On uninstall, are settings preserved in a recoverable location, or is removal destructive?
  • Is this built for one internal site or intended as a reusable distribution? That determines how much we should invest in upstreaming vs. forking.
  • Where is the user documentation for the switches? Release notes are currently the only changelog artifact.

Integration Approach

• Stack fit: Laravel + Statamic. Confirm the pinned Statamic major/minor before anything else — add-ons in this category are typically version-brittle at the settings layer. Validate against the exact Statamic version(s) in our estate, not just "latest."
• Migration path: Treat this as a settings migration, not a package install. Required sequence: inventory which sites currently define form settings → capture current config in VCS as the rollback artifact → enable the add-on with all switches off → verify forms render identically → enable switches feature-by-feature per site. If the add-on does not fall back to core settings when a switch is off, this is a one-way door per site and must be scheduled as such.
• Compatibility: Three axes to clear before rollout: PHP version, Laravel version, Statamic version. Composer minor/patch bumps in the release (#11) suggest active dependency tracking but do not establish a support matrix. Also confirm whether the add-on interacts with any existing form/blueprint customizations in our sites — colliding config keys are the most likely silent failure.
• Sequencing:
  1. Spike on a single non-critical site; confirm settings resolution and CP behavior.
  2. Document the switch matrix (feature → switch → default → owner).
  3. Roll to remaining sites in waves, lowest-traffic first.
  4. Only after full coverage, decide whether to retire core form settings from our templates — do not remove them in the same change window as the add-on rollout.
• Rollback: Keep the add-on removable and core settings intact through at least one full release cycle. If uninstall is destructive, pin the version and treat upgrades as change-managed events.

Operational Impact

• Maintenance: Low-to-moderate effort, but non-zero ownership. We inherit version-pinning, Statamic upgrade testing, and switch-configuration drift across sites. The maintainer's investment in shared skills/rules and aggregate CI is encouraging but describes their workflow, not our support contract.
• Support: Community/org-level only — GitHub issues, no SLA, no vendor escalation. For a settings-layer add-on that affects content editors, plan an internal fork-or-patch capability, or accept that a broken upstream release blocks form configuration changes.
• Scaling: Two scaling vectors. Horizontally, per-site config multiplies the settings surface — the per-feature switches are the mitigation, so keep the switch matrix documented and under config management rather than CP-only. Vertically, runtime cost is negligible (add-on boot per request); the scaling risk is configuration entropy, not performance.
• Failure modes to monitor:
  • Switch misconfiguration silently suppressing form settings (worst case: forms appear functional but submissions/settings are wrong).
  • Add-on disabled or removed → settings become unreachable and the site degrades non-obviously.
  • Statamic upgrade changes the underlying settings schema while the add-on still targets the old shape.
  • Divergence between cached/core settings and add-on-managed settings after a partial rollout.
  • Pre-1.0 breaking change in a 0.2.0 arriving without a migration note.
• Ramp-up: Developers familiar with Statamic add-ons: minimal, under a day. Content editors and site admins: medium — if the CP location or semantics of form settings change, they need a short guide and a support path for "my form settings disappeared." Documentation is currently a gap; budget for writing the switch matrix and an editor-facing note as part of adoption rather than after.
• Recommendation: Proceed to a contained pilot, not a fleet rollout. Re-assess at the next functional release (or at 0.2.0/1.0.0), specifically checking for a documented settings-migration/fallback story and a stated Statamic support matrix.