Sulu Form Bundle Laravel Package

Product Decisions This Supports

• Feature enablement without a build: form capture (contact, lead-gen, sweepstakes, event registration, newsletter interest) becomes a configuration task in the Sulu admin rather than a multi-sprint engineering project. Content managers create, edit, and reorder fields in a grid themselves.
• Build vs. buy: for a Sulu-based site, this is a "buy/adopt" — it replaces an in-house form builder with a maintained MIT bundle built on Symfony Forms. Building a dynamic form builder + submission storage + notification emails internally is weeks of work this removes.
• Roadmap sequencing: forms move from "engineering backlog" to "content ops enablement," freeing capacity for CRM routing, analytics instrumentation, and design-system theming — the work that actually differentiates the product.
• Platform gate decision: this is effectively an argument about CMS strategy. If the answer to "are we on Sulu 2.0+/Symfony?" is yes, adopt. If not (Laravel, WordPress, headless Next.js), this package is out of scope and the real decision is evaluating alternatives.
• Scope decisions it forces early: submission retention and export (CSV export exists), notification email ownership (visitor + internal recipients are configurable by content managers), spam posture (honeypot and reCAPTCHA), localization (per-form, per-locale), file uploads/attachments, and Mailchimp list selection.
• Theming/design ownership: rendering inherits Symfony Form theming, so front-end form templates and accessibility are our responsibility, not the bundle's. Budget for it explicitly.
• Risk decision: community-driven with a small footprint (86 stars, 0 dependents) — adopt as a contained bet with a named internal owner and a fork/contingency plan, not as an unexamined platform dependency.

When to Consider This Package

Adopt when:

• The site runs Sulu 2.0+ on Symfony — compatibility is the hard prerequisite, and the bundle is tightly coupled to Sulu admin, Sulu entities, and Symfony Forms.
• Marketing/content needs self-serve form creation without engineering tickets: dynamic fields, grid positioning, configurable confirmation and notification emails.
• Requirements are "standard business forms": contact, registration, sweepstakes, surveys with basic field types, file upload, honeypot/reCAPTCHA, CSV export of submissions.
• Data residency matters — submissions land in your own database, not a third-party form SaaS.
• MIT licensing and internal ownership of templates/integrations are acceptable.

Look elsewhere when:

• You are not on Sulu. There is no portable value here; a Laravel or headless stack needs a different solution entirely.
• You need advanced marketing automation: multi-step wizards with conditional branching, deep native CRM/MAP integrations, A/B testing, progressive profiling, or enterprise-grade form analytics. Expect custom development on top of this bundle, or a dedicated platform.
• You require a commercial SLA or vendor support — this is a community project backed by partner companies, with a small adoption footprint and a correspondingly thin maintenance bench.
• Your security/compliance bar exceeds honeypot + reCAPTCHA, or you need audited retention and DSR tooling out of the box.
• Maintenance validation fails. Before committing, confirm the actual release cadence and upgrade path in the repo — the provided metadata lists a last release of 2026-09-30, which is anomalous and should not be treated as a maturity signal without verification.

Practical gate: run a 1–2 week spike covering install, upgrade path from the version you'd pin, the specific field types you need, theming against your design system, and notification delivery. Do not adopt on README alone.

How to Pitch It (Stakeholders)

Summary for executives: This is an official Sulu bundle that lets our content team build and publish forms — contact forms, registrations, lead capture — directly in the CMS, without engineering work per form. It is MIT-licensed, so there is no per-form or per-submission vendor cost, and submitted data stays in our own database rather than a third-party service. The trade-off is that it is a small, community-maintained project with modest adoption: it is a low-cost bet that should be scoped with an internal owner and a fallback plan, not treated as a strategic platform commitment. It only applies if Sulu remains our CMS.

For engineering: Symfony Form–based bundle, Sulu 2.0+, DI-registered controllers, post-save events for hooks, extensible field types, admin list views for submission data. Our real work is theming the form templates to our design system, wiring notification and integration points (CRM/ESP), and pinning plus tracking the version. Estimate the spike, not the feature.

For marketing/content: You get self-serve forms with drag-and-drop field ordering, per-locale versions, configurable confirmation and notification emails, file upload fields, spam protection via honeypot and reCAPTCHA, and CSV export of responses. Requests that currently wait on a sprint become same-day work.

Ask: Approve a short technical spike (install, upgrade path, field-type coverage, theming, email delivery) and name an internal owner. On a green spike, adopt; on a red one, we document the gap and evaluate a dedicated form platform instead — either way the decision is cheap and reversible.