Statamic Multisite Forms Laravel Package

Getting Started

• Install from Packagist now that v0.6.1 documents it: composer require uams-web/statamic-multisite-forms (check the README for the exact vendor/package string before running). Statamic add-ons register themselves via package discovery, so no manual service-provider edit should be needed.
• First place to look is the README, then the wiki. As of v0.6.1 the wiki pages are explicitly marked as written against v0.6.1, so treat them as accurate for this tag and verify anything surprising against the source.
• Publish the add-on's config (php artisan vendor:publish --tag=...) and clear caches after any change: php artisan cache:clear and php artisan statamic:stache:clear. Multisite config changes are the most common cause of "my change did nothing".
• First use case to validate: a Statamic site with two or more sites (locale or domain based) where a form is rendered in more than one site context and submissions must be attributed to, and routed to the right people for, the site they came from. Build that minimal two-site form first; it exercises the add-on's core value and surfaces misconfiguration immediately.

Implementation Patterns

• Pin the version. This is pre-1.0 (0.6.1), so treat every minor bump as potentially breaking. Use an exact constraint ("0.6.1") or at minimum ~0.6.1 in composer.json, and review the changelog before bumping. The project itself says the Marketplace listing waits for v1.0.0 — plan for churn.
• Configure per site, then verify in the control panel. Set up the form once, then confirm that each site in config/statamic/sites.php resolves the expected form configuration, submission destination, and notification recipients. Walk through one submission per site rather than assuming inheritance works as you expect.
• Keep site context explicit. In Antlers/Blade, render forms inside the normal site-aware request lifecycle so the add-on can resolve the current site. Don't reach into the add-on's internals to set a site manually unless the docs show that path — it's the most likely thing to break on upgrade.
• Queue and console contexts. If you send notifications or process submissions in a queued job or an artisan command, there is no request and therefore no "current site". Pass the site handle explicitly through the job payload and resolve it inside the job; don't rely on ambient site state.
• Test with an explicit multisite fixture. In Pest/PHPUnit, boot with multiple sites and use Statamic\Facades\Site::setCurrent('...') around assertions so each site's behaviour is covered. Assert on both the stored submission's site attribution and the resulting notification target.
• Integration tip: treat this add-on as the site-resolution layer and keep your own form business logic (validation rules, custom fieldtypes, downstream integrations) in your app, not in the add-on's config, so an upgrade doesn't strand your customisations.

Gotchas and Tips

• Pre-1.0 stability is the headline risk. No deprecation policy is documented yet; the v1.0.0 milestone gates the Marketplace listing. Budget time for upgrade work and keep a thin integration surface.
• Docs are version-stamped. The wiki is written against v0.6.1 specifically. If you're on an older tag, or later on 1.x, check that the page you're reading hasn't drifted — the marking is a signal, not a guarantee for your version.
• Cache layers bite. Statamic has the Stache, the application cache, and (in production) config/route caching. After adding a site or changing the add-on's config, clear all three before debugging behaviour.
• Site inheritance assumptions. The most common failure mode in multisite add-ons is assuming a form defined on the default site is automatically available and correctly scoped elsewhere. Test the negative case: a form configured for site A should not silently deliver site B's submissions to site A's recipients.
• Notification routing is the highest-blast-radius setting. A misconfigured recipient sends real patient-adjacent or institutional email to the wrong team. Start with a catch-all internal address in staging, then narrow per site.
• Extension points to prefer: published config and documented events/hooks over subclassing or patching vendor code. Anything you override in vendor/ will be lost on the next 0.x bump.
• Attribution changed. v0.6.1 names the University of Arkansas for Medical Sciences as copyright holder. Confirm the licence in the repo is acceptable for your organisation, and update your third-party notices file if you maintain one.
• Marketplace guidance docs exist but the listing doesn't. The v0.6.1 documentation of Marketplace guidelines is aimed at contributors, not consumers; don't infer from it that a "stable" release is imminent.