Statamic Easy Forms Laravel Package

Technical Evaluation

Architecture fit. Easy Forms is a Statamic addon running on Laravel, so it inherits the host application's service container, config system, Blade/Antlers rendering, and queue/mail infrastructure. v2.1.0 deepens that fit rather than widening it: localization is driven by config (localize_submissions / EASY_FORMS_LOCALIZE_SUBMISSIONS) and reCAPTCHA degradation is handled through the existing package boundary (google/recaptcha). Both are consistent with Laravel conventions (config + env fallback), which is a positive signal for coupling and reversibility.

Integration feasibility. Low-to-moderate. The release is additive and fix-oriented; no migrations, no API surface removal, no signature changes are described. The multisite localization feature is opt-in via config, so existing single-site and non-localized deployments should behave identically. The reCAPTCHA fix removes a hard failure mode (secret set + package absent previously errored) and replaces it with skip-plus-warning. Placeholder translation fixes touch date, select, dictionary, and improved-select field types — these are presentation-layer changes with low blast radius.

Technical risk. The principal risk is the reCAPTCHA change: skipping validation with only a warning converts a fail-closed behavior into fail-open. If a production environment has a secret configured but the dependency dropped from the lockfile (e.g., a Composer prune or a deploy that skipped composer install --no-dev correctly but lost the package), forms will silently accept unvalidated submissions. That is an availability win and a spam/abuse risk simultaneously, and it must be paired with log monitoring. Secondary risk is localization correctness: locale resolution on multisite is subtle (page locale vs. site locale vs. user preference), and the toggle creates a second rendering path that needs coverage across all field types, not just the four named in the changelog. There is no evidence of breaking changes.

Key questions.

• What is the default for localize_submissions? If it defaults to true, this is a behavior change for existing multisite installs and should be called out as such.
• Which locale source wins on multisite — the entry/page locale, the site's default locale, or the request locale?
• Is the reCAPTCHA skip warning emitted via Laravel's logger at warning level, and is it emitted once per request or per form render?
• Does the skip path apply to both v2 and v3 reCAPTCHA, and does it distinguish "package missing" from "secret invalid"?
• Are the placeholder translations sourced from Statamic's lang files, the addon's own, or publishable overrides?
• Any minimum Statamic/Laravel version bump implied by the multisite locale APIs used?

Integration Approach

Stack fit. Assumes a Laravel + Statamic application. The addon slots in at the addon layer: config under config/easy-forms.php (or Statamic's addon config convention), env overrides for per-environment toggling, Antlers/Blade tags for form rendering, and Laravel's validation, mail, and event systems underneath. No new infrastructure is introduced — no queues beyond what the host already runs, no external services beyond reCAPTCHA (already optional).

Migration path. Effectively a composer version bump. Recommended sequence:

1. Pin the dependency and run composer update in a branch; verify google/recaptcha presence matches the intent for each environment.
2. Publish/merge config to surface localize_submissions explicitly rather than relying on the default — make the default visible in version control so the behavior is auditable.
3. Smoke-test all form field types (date, select, dictionary, improved-select) on both a localized and non-localized site if multisite is in play.
4. Exercise the reCAPTCHA path in staging: with the package installed and a valid secret, with the package removed and a secret set, and with no secret at all.

Compatibility. No breaking changes described; the release reads as semver-minor. The reCAPTCHA behavior change is technically a behavioral fix but could surprise teams who were relying on the error as an implicit deployment check — worth flagging in the upgrade note even though it is not an API break. Localization strings may shift rendered output for existing forms (placeholders that previously rendered in English now render translated), which is cosmetic but could affect snapshot or E2E tests.

Sequencing. Ship the version bump and config pinning together. Enable localize_submissions per site after translation coverage is confirmed, not globally on day one. Treat the reCAPTCHA warning as a monitored signal from the first deploy so the fail-open window is observable.

Operational Impact

Maintenance. Low. Config-driven toggles and env overrides mean per-environment behavior is managed without code changes. The main ongoing cost is translation maintenance: multisite localization multiplies the string surface by locale count, and Statamic lang file drift after Statamic upgrades is a recurring, if minor, chore.

Support. Expect support tickets of two kinds: (a) "form submits but no reCAPTCHA appears / validation seems off" — the new fail-open path; (b) "placeholder text is wrong language" — locale resolution mismatch between page locale and form locale. Both are diagnosable from logs and config, but support staff need a short runbook.

Scaling. Negligible runtime impact; localization is string lookup at render time. The reCAPTCHA skip path has no performance cost. At high form volume, the concern is spam ingress if reCAPTCHA is silently disabled, not compute.

Failure modes.

• Silent reCAPTCHA bypass — secret set, package absent, validation skipped, warning buried in logs. Mitigation: alert on the warning, add a health check asserting the package is installed when a secret is configured, and document the combination as an anti-pattern.
• Locale leakage — a form on a secondary site renders validation/error messages in the primary site's language. Mitigation: per-site E2E assertions on error output, not just on page copy.
• Partial translation coverage — new field types or addon strings untranslated in some locales. Mitigation: include translation completeness in the release checklist.
• Config drift — localize_submissions set inconsistently across environments, producing staging/production divergence. Mitigation: pin explicitly in config, not only via env.

Ramp-up. Low for a Laravel/Statamic-fluent engineer: one config file, one dependency to confirm, and a handful of form templates to test. Budget roughly half a day for the upgrade and verification on a single-site install, and one to two days where multisite localization is enabled, most of it spent on locale coverage QA rather than integration. The reCAPTCHA behavior change is the item that most needs explicit team agreement before release, because it trades a loud failure for a quiet one.