Statamic Resend Form Submissions Laravel Package

Technical Evaluation

Architecture fit. This is a deliberately thin Statamic control-panel addon: register an AddonServiceProvider, add a CP route behind statamic.cp middleware, register a small Vue component into the form submissions listing, and on click re-enter Statamic's existing form-notification pipeline against a stored submission record. It introduces no data model, no migrations, and no external services — it is a UX wrapper around functionality Statamic already owns (the Submission object plus the form's configured Email/notification recipients). As an architectural pattern it fits cleanly; the concern is not the shape of the integration but the fact that the integration point is one of the more volatile surfaces in Statamic (CP listing component registration and the internal form/email classes have shifted across the 3.x → 4.x → 5.x line).

Integration feasibility. Technically high: composer install, asset publish, cache clear, one route to smoke-test. The business capability is also genuinely useful — it converts "a customer says they never got the confirmation email" from a developer task (tinker/CLI re-send) into an editor-level recovery action. That is the entire value proposition, and it's a real one in a forms-heavy site.

Technical risk. High relative to the code's size:

• Archived, 0 stars, 0 dependents. There is no upstream maintenance, no issue triage, no security response. Adoption makes your team the de facto maintainer.
• Internal-API coupling. Re-sending almost certainly depends on semi-private Statamic classes and the submission repository (storage vs. database driver). Upgrades will break it in ways that are hard to predict without reading the source.
• Non-idempotent side effect. A CP button that fires outbound email with no idempotency key, no server-side throttle, and (presumably) no audit trail is a duplicate-send and reputation-risk vector.
• Authorization ambiguity. If the route isn't permission-gated to submission-view capability, any CP user can emit mail from your domain on your DKIM/SPF reputation.
• Metadata inconsistency. An "archived: yes" package carrying a future-dated last release (2026-04-01) with zero adoption is a signal to verify the package and its Packagist entry manually before trusting any of the metadata, including the version constraint.
• No visible test suite or CI matrix, so "works on my Statamic version" is the only guarantee.

Key questions to answer before any install.

1. Which Statamic versions are supported, and does it use public APIs or reflection/private methods?
2. Does a resend go to the recipient set captured at submission time, or to the currently configured form recipients? (The second is wrong for recovery use cases and dangerous if recipient lists have changed.)
3. Does it respect the configured mailer and queue (Mail::queue vs. synchronous), and what happens on SMTP failure — silent no-op, exception, or user-visible error?
4. Is there an audit log (actor, timestamp, submission ID, recipient list)? PII exposure matters here.
5. Is the action gated by Statamic permissions, and is there rate limiting/debounce?
6. Does it work with both file-based and Eloquent submission repositories, and with multi-site?
7. Is it actually published on Packagist in its archived state, or does it require a VCS/path repository?

Integration Approach

Stack fit. Statamic 3/4/5 on Laravel, composer-installed, no infrastructure footprint, no DB changes. It runs in the production control panel, so despite being a trivial addon it must be treated as production code with the same review, pinning, and rollback story as anything else.

Recommended migration path. Do not add an archived, zero-adoption package to the dependency tree. Two viable routes:

• Option A — Fork and own it. MIT permits this. Vendor the source as a path or VCS repository, pin it, and accept maintenance. Fastest if you need it this sprint and your Statamic minor matches.
• Option B — Reimplement in-house (recommended). This is roughly 1–3 developer-days: one CP route (POST /cp/forms/{form}/submissions/{submission}/resend), a permission check, a service that replays the form's email notification against the stored submission payload, a listing row action in a small Vue bundle, and a log entry. You get the capability, the audit trail, and zero dependency — cheaper than the fork within two Statamic upgrade cycles.

Compatibility. Pin to your exact Statamic minor and validate against Statamic 5's listing-action API before committing; expect to patch both the PHP route and the Vue registration if you're on 4.x/5.x and the package was written for 3.x. Test with multiple recipients, attachments, and both submission drivers.

Sequencing.

1. Confirm your Statamic version and that Forms is available/licensed in your tier.
2. Proof-of-concept in staging against a throwaway form; verify recipient semantics and error behavior.
3. Decide fork vs. build (default: build).
4. Add permission gating, server-side throttling, and audit logging before exposing to editors.
5. Ship behind a feature flag; document the recovery runbook.
6. If forked: add a CI matrix across supported Statamic versions, a changelog, and a pinned constraint.

Operational Impact

Maintenance. This is the dominant cost and it is entirely yours. Archived plus zero dependents means every Statamic major (and several minors) becomes a patch you own, on someone else's timeline. Expect to touch it once per Statamic upgrade cycle; the in-house reimplementation pays for itself within roughly two cycles.

Support. No upstream, no advisories, no triage. Escalation is internal-only. An archived dependency will also typically trip organizational SCA/policy gates ("no unmaintained packages in production"), which means you'll need an explicit exception or a fork to stay compliant.

Scaling. Effectively nil. Each click is a constant-time operation on an existing submission record; no throughput, storage, or query-cost impact. The only scaling concern is mailer volume and sender reputation if operators bulk-resend across a large submissions list — enforce per-user rate limits and make bulk resend impossible or explicitly capped.

Failure modes.

• Duplicate sends — no idempotency; a double-click sends twice. Needs disabled-state UI, debounce, and server-side throttle.
• Silent failure — SMTP errors surfaced as a success toast, leaving editors believing a customer was contacted.
• Wrong recipients — re-resolving current form config instead of the submission-time recipient set; can mail people added later or fail when a recipient was removed.
• Config drift — form renamed or email config deleted; action 500s or no-ops with no clear message.
• Authorization gap — unauthenticated-by-permission CP users triggering outbound mail from your domain; deliverability and spam-complaint risk.
• PII exposure — resend shows submission content to whoever clicks; pair with an audit log.
• Deploy breakage — an archived package frozen in composer.lock colliding with a PHP or Statamic bump, failing at autoload time rather than at review time.

Ramp-up. Near-zero for developers (one small addon, one route, one component). Non-trivial for editors: they need a one-page runbook covering when a resend is appropriate versus when the mailer or spam filter is the actual problem, how to confirm the recipient list, and the fact that every resend is logged and attributed.

Net position. The capability justifies a sprint-day of effort; the package as published does not justify a production dependency. Treat it as a reference implementation, copy the behavior into code you own, gate it with permissions, throttle it, and log every send.