Statamic Multisite Forms Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic add-on distributed as a Composer package, so it inherits Laravel's service-provider and config-publishing conventions rather than introducing a parallel extension mechanism. That is the right shape for a Laravel/Statamic estate: no new runtime, no new build toolchain, and deployment stays inside the existing composer install + php artisan flow. The package's stated domain — forms across a Statamic multisite — is a real gap in core Statamic, which ships multisite content but does not natively solve per-site form submissions, so the capability is genuinely additive rather than duplicative.

Integration feasibility. Straightforward on paper. v0.6.1 explicitly documents installation from Packagist (PR #186), which means the package is resolvable via Composer without a VCS repository entry — a meaningful reduction in setup friction versus a Git-sourced dependency. The remaining work is standard: register the add-on, publish config, and define site-scoped form behaviour. Nothing in this release changes runtime behaviour, so there is no compatibility surface to re-validate.

Technical risk. The dominant risk is maturity, not technology. The package is at v0.6.1 and its own release notes record that the Statamic Marketplace listing is deliberately deferred until v1.0.0 (PR #188). That is an honest signal from the maintainers: the public API, config schema, and form data model should be assumed unstable until 1.0. Any integration now is an early-adopter position, and upgrade churn between 0.6.x and 1.0 should be budgeted for. Secondary risks are unverified: we have no code-level review, no test coverage signal, no evidence of Statamic major-version constraint breadth in composer.json, and no failure-mode documentation. This release is documentation-only — five PRs, all README/wiki/copyright/marketplace metadata — so it neither introduces nor retires any technical capability.

Key questions. Which Statamic major versions are supported, and is that constraint pinned or open-ended? Is form submission data stored in the app database, and if so what does the schema and retention story look like across sites? Does the add-on hook Statamic's form tags, its submission pipeline, or both — i.e. can existing templates adopt it incrementally? What is the maintainers' 1.0 timeline, and is UAMS (now named copyright holder per PR #189) committing to ongoing stewardship or is this a publish-what-we-built artifact? Finally, does the multisite scoping govern only rendering, or also submission routing, notifications, and export?

Integration Approach

Stack fit. Assumes Laravel + Statamic with multisite already configured. The add-on does not appear to impose additional infrastructure — no queue worker, no external service, no separate datastore is implied by the release notes. For teams already running Statamic multisite, this is a same-stack addition; for teams on plain Laravel without Statamic, it is not applicable.

Migration path. Install from Packagist per the newly documented instructions, pin explicitly, and treat it as an additive capability rather than a replacement for existing form handling. Because no existing assessment or prior version data is available, there is no deprecation or breaking-change trail to reconcile — v0.6.1 is the baseline we would adopt against. Teams already on a VCS-repository install can move to the Packagist source, which is the substantive change this release enables.

Compatibility. Two axes to verify before committing: Statamic major version, and PHP version. Neither is stated in the release notes, and both should be read from composer.json rather than inferred. The deferred Marketplace listing is a mild compatibility signal — Marketplace review typically enforces version constraints and support policy, so a pre-1.0 package likely has loose or undocumented constraints today.

Sequencing. (1) Read composer.json for framework constraints and confirm against the target app. (2) Spike in a non-production multisite environment: install from Packagist, wire one form across two sites, and verify submission attribution, notifications, and any persistence. (3) Confirm data retention and export behaviour before any production form collects real submissions. (4) Run in production for one release cycle on a low-stakes form. (5) Re-evaluate at v1.0.0 and Marketplace listing, at which point a stability commitment exists. Do not sequence this ahead of a 1.0 if the form is business-critical.

Operational Impact

Maintenance. Low code footprint, but elevated attention requirement pre-1.0. Expect breaking changes between 0.6.x and 1.0; pin to an exact version and treat upgrades as planned work with a changelog review, not automatic. Composer's composer outdated and Dependabot will surface releases, but a human must read them — a documentation-only patch like v0.6.1 is safely absorbed, whereas a future minor may not be.

Support. The copyright holder is now explicitly named as the University of Arkansas for Medical Sciences (PR #189), which is a positive governance signal: institutional backing rather than an anonymous maintainer, and a real entity behind the licence. It is not, however, a commercial support commitment. Assume community-style support via GitHub issues, with no SLA. The add-on is newly documented against v0.6.1 (PR #190), so the wiki is current — but it will drift as the package approaches 1.0, and wiki pages are not versioned per release. Budget internal ownership of the integration regardless of upstream responsiveness.

Scaling. Unassessable from the release notes. The scaling characteristics that matter are submission volume, per-site data isolation, and whether notification/processing is synchronous or queued. None are documented. Before production use, load-test the submission path and confirm whether a burst of form posts can block request workers; if processing is synchronous, plan for a queue or a rate-limit in front of the endpoint.

Failure modes. The realistic failure modes are integration-level rather than runtime-crash-level: a Statamic upgrade breaking the add-on's tag or submission hooks with no upstream patch yet; silent mis-scoping where a submission is attributed to the wrong site in a multisite setup; and data-model changes between 0.6.x and 1.0 that require migration of already-collected form data. The third is the one to guard against — export and retain submissions in a format you control so a schema change upstream does not strand historical records. Absent any evidence of the add-on degrading core Statamic behaviour, blast radius is bounded to forms, which keeps the risk containable to a non-critical surface during evaluation.

Ramp-up. Short for a Laravel developer already fluent in Statamic: Packagist install, config publish, template wiring. The learning cost is concentrated in multisite semantics — how forms resolve per site and where submissions land — not in the package's API, which is deliberately conventional. A competent pair can reach a working prototype in a day; the multi-week cost is the production hardening and data-retention design, not the integration.