Statamic Quote Laravel Package

Technical Evaluation

Architecture fit. Release 5.3.0 adds Statamic 6 compatibility (#19). The headline fact is not the feature but the disclosure: this is a Statamic addon, not a standalone Laravel package. Every earlier conclusion about "architecture fit" needs to be re-read through that lens. The package does not sit beside a Laravel application — it runs inside a Statamic install, registers fieldtypes in the control panel, and takes its form definitions from Statamic's form configuration. That is a tighter and more opinionated contract than the 2.2.0 assessment assumed. For a Statamic 6 site it is a natural fit and arguably the only sane way to get file uploads into Statamic forms. For a plain Laravel application, or a Statamic 5 site not ready to move, the package is now out of scope entirely. The earlier caveat still stands and is sharper: if uploads are deliberately centralized in a media library, DAM, or scanning pipeline, adopting this fieldtype creates a second, competing upload path inside the CMS.

Integration feasibility. The release itself is additive and small — a compatibility declaration, most likely a widened constraint in composer.json plus any Statamic 6 API adjustments. But the version jump from 2.2.0 to 5.3.0 is the more consequential signal. Three majors have passed since the assessment was written, and the release note for 5.3.0 is a single line that tells us nothing about 3.x, 4.x, or 5.0–5.2. We cannot assume the additivity we verified at 2.2.0 survived those majors, and we cannot assume the upload behaviour, storage contract, or cleanup semantics we flagged as open questions are unchanged. Realistic effort is therefore not "bump a constraint" but "re-baseline the addon": read the changelog across the intervening majors, re-run the spike, and confirm which of our seven open questions have been answered upstream. Budget a day or two, not an afternoon.

Technical risk. The dominant risks are unchanged from the 2.2.0 assessment — storage lifecycle and orphaned files, MIME/extension trust and public-disk exposure, compliance obligations for uploaded documents, validation that may live in control-panel-editable form definitions, and a thin single-contributor support base. Statamic compatibility adds three more:

• Platform lock. Adopting the addon means adopting Statamic 6, or being pinned to whichever addon major matches your Statamic major. The dependency runs in both directions and constrains future platform upgrades.
• Multi-major drift. Jumping 2.2.0 → 5.3.0 without an intervening review means our documented behaviour baseline is stale. Some risks may be resolved; new ones may have been introduced. Treat the old assessment as unverified.
• Doubled novelty. Statamic 6 is itself a recent major, and 5.3.0 is the release that first supports it. Running a new platform major with a freshly-compatible addon concentrates risk in exactly the code path that handles user-supplied files.
• Control-panel-editable definitions. In a Statamic context the form definition is CP content, not code. If validation limits live there rather than in server-side rules, a content editor can weaken them. This raises the priority of open question 1 from "confirm" to "gate".

Key questions. The 2.2.0 questions still stand and should be re-asked against 5.3.0, since several may now be answered:

1. Does the feature validate uploads server-side, and are limits enforced independently of the Statamic form definition?
2. Which disks/visibility settings are supported, and is S3 or other non-local storage a first-class option?
3. What is the filename strategy, and is there any path-traversal or overwrite protection?
4. Is there file cleanup on record deletion, field removal, or submission abandonment?
5. Are uploads stored via Eloquent relations, a polymorphic media table, Statamic's asset container, or raw paths?
6. Does it support multiple files per field, and what are the concurrency expectations?
7. Does it follow semver? What shipped in 3.0, 4.0, and 5.0, and are any of those breaking for our usage?
8. What is the exact Statamic and PHP support matrix for 5.3.0, and is Statamic 5 still supported by a maintained addon major?
9. What is the package's release cadence and bus-factor, and how quickly did it track the Statamic 6 release?

Integration Approach

Stack fit. The stack is now Statamic 6 on Laravel, not "a conventional Laravel stack." That single line narrows the addressable surface considerably and should be confirmed against our actual installed versions before any work is scheduled. If we are on Statamic 5, this release is not adoptable without a platform upgrade, and the platform upgrade — not the addon — becomes the project. If we are on Statamic 6, the addon fits cleanly and requires no new infrastructure. In either case, confirm the addon's PHP and Laravel constraints, since Statamic majors pin framework versions and file handling tends to pull in framework-version-specific APIs.

Migration path. Treat 5.3.0 as a re-entry point, not an upgrade.

1. Read the changelog for 3.0 through 5.2 and note every breaking change against our documented 2.2.0 baseline.
2. Upgrade in a non-production branch and confirm no regressions in existing form rendering and submission.
3. Re-run the upload spike on a single internal, low-risk form to re-establish actual behaviour.
4. Only then consider migration of existing upload flows — and only if the addon's storage model matches ours. Otherwise keep existing uploads where they are and use this feature solely for new, low-sensitivity forms.

Compatibility. Two compatibility questions, and they are different in kind. The first is platform: which addon major pairs with which Statamic major, and what happens at the next Statamic release. The second is our own data: if files are stored via an addon-specific table, asset container, or path convention, migrating off later means a data migration. The 2.2.0 note said to confirm the storage contract before production data accumulates — that advice is now urgent rather than prudent, because three majors of drift mean the contract may already have changed shape once.

Sequencing. (1) Changelog review across 3.x–5.x — half a day. (2) Confirm Statamic/PHP support matrix and our current versions. (3) Re-run the security and storage-policy spike against 5.3.0 — the gating step. (4) Internal pilot form. (5) Production enablement behind a config flag for new forms only. (6) Reassess after one quarter of operational data before widening scope. Do not bundle this with a Statamic platform upgrade, and do not bundle it with other addon upgrades.

Operational Impact

Maintenance. Unchanged in substance and slightly worse in practice: we inherit ownership of storage configuration, retention policy, and cleanup jobs regardless of what the addon provides, and we now also inherit a platform-pairing obligation. Every future Statamic major becomes a dependency for this addon, and this addon becomes a gate on every future Statamic major. Budget ongoing effort for orphan sweeps, storage growth monitoring, and addon-major upgrade reviews. Uploads remain the classic source of unbounded cost creep.

Support. Support load shifts from developers to content editors, who in a Statamic install are the ones configuring forms. Expect tickets on size limits, rejected file types, and failed uploads on poor connections — issues that do not exist in a metadata-only form tool. The control-panel context makes this worse than the 2.2.0 assessment implied: editors can change field configuration without a deploy, so misconfiguration is a live, ongoing possibility rather than a launch-time decision. Provide documented limits and clear error messaging, and consider restricting who can edit file fields.

Scaling. File storage scales on a different axis than the application: object count, egress, and backup window rather than request volume. Confirm the target disk and whether backups now include user content, since that materially changes backup cost and restore time. Large or numerous files can hit PHP upload_max_filesize and post_max_size ceilings, which are environment-level changes requiring a deploy — and in a Statamic context, possibly a hosting-panel change outside our deployment pipeline.

Failure modes. Partial uploads leaving dangling records; silent success with a missing file reference if the storage write fails after the database commit; public exposure of a private disk misconfiguration; disk-full or quota exhaustion surfacing as generic 500s; and validation bypass if the form definition is control-panel-editable. Two additions specific to this release: a Statamic upgrade that outpaces the addon, leaving file fields broken or silently degraded on a site that depends on them; and behaviour drift from the un-reviewed 3.x–5.x majors, where something we relied on at 2.2.0 no longer holds. Each needs a defined behaviour — transaction ordering, quarantine, or explicit error — decided before launch.

Ramp-up. Low for the mechanics — a Statamic developer can wire a file field in under a day — and the platform framing actually reduces ramp-up versus a general Laravel package, because the integration surface is a known fieldtype contract rather than an open-ended one. The real ramp is still policy: what may be uploaded, where it lives, how long it is kept, and who can retrieve it. Assign that to a named owner. Given the single-line release note, the three-major gap since our baseline, and the newness of Statamic 6 support, treat 5.3.0 as an early-adopter release: adopt for internal or low-sensitivity use on Statamic 6 now, defer sensitive-document workloads until the storage contract, validation model, and cleanup behaviour are confirmed in writing against the current major.