Form Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Sulu CMS Integration: The bundle remains tightly coupled with Sulu CMS (v2.0+), leveraging its admin UI, content management, and workflow systems. This makes it suitable only for projects already committed to Sulu and introduces vendor lock-in if migrating away. 3.0.1 adds no decoupling — there is still no headless/API-first mode.
• Symfony Form Component: Built on Symfony’s Form Component, ensuring compatibility with Symfony’s validation, theming, and data binding. This aligns conceptually with Laravel’s Form Requests and Validation, but requires abstraction layers for adoption. 3.0.1 widens the supported Symfony window to include Symfony 8, which extends the bundle’s useful life but also signals that upstream is tracking Symfony majors aggressively.
• Dynamic Forms: Supports no-code form creation via Sulu’s admin panel, reducing backend effort, but still limits custom validation logic and complex business rules without extensions.
• Event-Driven: Integrates with Sulu’s ActivityBundle for submission event tracking. Useful for analytics; adds listener complexity when proxying into a Laravel runtime.
• Service Definition Style (new in 3.0.1): Migration from XML to PHP service definitions makes the DI graph introspectable and diffable in PHP. For a TPM this is a modest but real win: the adapter layer a Laravel service provider must bridge is now easier to read, static-analyze, and review in code review, rather than parsed from XML.

Integration Feasibility

• Laravel Compatibility: Low, unchanged by 3.0.1.
  • Dependency Injection: The bundle relies on Symfony’s DI container. Laravel’s IoC would require adapters or facades. The PHP service definitions in 3.0.1 make it easier to enumerate what must be bridged, not easier to bridge it.
  • Routing: Uses Symfony routing conventions. Laravel resource routing or custom routes need mapping.
  • CSRF Protection: Deprecated DisabledCsrfTokenManager conflicts with Laravel’s built-in CSRF; custom middleware required.
  • Request Handling (relevant to 3.0.1): The release replaces $request->get() with the correct accessor methods for Symfony 8. Any adapter layer that proxies a Laravel Request into Symfony’s Request must map query / request / attributes explicitly — the implicit get() fallback behavior can no longer be relied on. This is a concrete adapter-design constraint, not just a cosmetic fix.
• Workarounds (unchanged):
  • Wrapper Layer: A Laravel service provider bridging Symfony services (e.g. FormHandler) into Laravel’s container.
  • API Proxy: Expose the bundle as a microservice if tight coupling is unavoidable — still the lowest-risk option.
• Database Schema: Uses Doctrine ORM (form, form_field, form_submission) plus PHPCR (Jackalope) for content. Requires migration scripts, a data mapper, or a hybrid storage layer.

Technical Risk

• High Integration Risk (unchanged in substance):
  • Symfony-specific features — Twig templating, FormType, EventDispatcher — require rewrites or polyfills.
  • CSRF/session handling divergence between Symfony 5.4+ ESI tokens and Laravel sessions.
  • Media handling depends on MediaManagerInterface; requires Spatie Media Library or similar.
• Version-Skew Risk (revised downward slightly, then re-raised): 3.0.1 allows Symfony 8, so the bundle now spans a wide Symfony window. That reduces the near-term risk of being stranded on an unsupported Symfony. However, Symfony 8 requires PHP 8.4+, which forces the hybrid runtime onto Laravel 11/12 (Laravel 10 tops out below PHP 8.4). If both run in one process, the PHP floor is now set by the bundle, not by Laravel. This is a planning constraint worth confirming against composer.json constraints before scheduling work.
• Behavioral Risk from 3.0.1: Two changes deserve regression coverage — external redirect links now use the link provider, and the built form cache is reset between requests. The first can alter redirect targets for existing forms; the second changes cache lifecycle assumptions. Both are low-probability, medium-impact for existing forms.
• Maintenance Risk: Forking still required for deep adaptation; custom adaptations diverge from upstream and increase merge conflicts. XML→PHP service definitions will also conflict heavily with any fork that still carries XML overrides — a fork-rebase cost to budget for.

Key Questions

1. Why Laravel? — Is Sulu’s admin UI a hard requirement, or can forms be decoupled via API? Are there Laravel-native alternatives (Filament Forms, Laravel Collective) that meet the need?
2. Scope — Replace all Laravel forms or a narrow use case (e.g. contact forms)? Is the Sulu admin panel necessary, or frontend-only?
3. PHP/Laravel floor (new) — Does adopting 3.0.1 with Symfony 8 support force PHP 8.4 and therefore Laravel 11/12? Confirm the composer constraint matrix before committing.
4. Cache lifecycle (new) — Does the per-request form cache reset change behavior for our deployment model (queue workers, Octane, long-running processes)? Is that a fix we depend on or a change we must test?
5. Team Expertise — Does the team have Symfony/Laravel hybrid experience and budget for custom development?
6. Long-Term Viability — Will the project remain Sulu-dependent, or is extraction a goal?

Integration Approach

Stack Fit

• Laravel Core:
  • Forms: Replace Symfony FormType with Laravel Form Requests or Livewire/Alpine.js.
  • Validation: Laravel Validator instead of Symfony constraints.
  • Routing: Map Sulu REST routes to Laravel API resources / controller methods.
  • Templating: Blade or Inertia.js instead of Twig.
  • Request bridging: Explicitly translate Laravel request data into Symfony request query/request/attributes — do not depend on get() semantics.
• Database:
  • Option 1: Migrate PHPCR data to Eloquent (high effort).
  • Option 2: Use Doctrine DBAL in Laravel against Sulu’s existing tables.
  • Option 3: Hybrid — form definitions in Laravel DB, editing via Sulu admin over API. Still the recommended default.
• DI Bridging (easier in 3.0.1): With PHP service definitions, generate the list of services to bridge programmatically and pin it in the adapter layer’s test suite so upstream definition changes surface as test failures rather than runtime errors.
• Auth: Map Sulu RBAC to Laravel Gate/Policy or Sanctum/Passport.
• Media: Replace MediaManagerInterface with Spatie Media Library.

Migration Path

Compatibility

• Symfony 8 (new): Now permitted by 3.0.1. Implies PHP 8.4+, and therefore Laravel 11/12 if co-hosted in one runtime. Laravel’s PSR-15 middleware and HTTP client can substitute for Symfony’s EventDispatcher/HttpClient.
• Symfony 6/7: Confirm the 3.0.x constraint set — if the Symfony 8 allowance came with a minimum-version bump, older deployments must upgrade Symfony before taking 3.0.1. Verify before scheduling.
• PHP 8.4: No conflicts; supported by the bundle and by Laravel 11/12.
• Sulu-Specific: Workflow (draft/publish) replication via a Laravel workflow package; shadow locales require custom localization logic.

Sequencing

1. Pilot Phase: Integrate one form type (e.g. contact form) via API proxy as proof of concept. Pin 3.0.1 for the pilot rather than 3.0.0 — it is a patch release and carries the compatibility fixes you would otherwise inherit as debt.
2. Upgrade Gate: Validate redirect-link behavior and per-request cache reset in staging; confirm PHP/Laravel floor against the composer matrix.
3. Core Integration: Form submission handling in Laravel; replace FormType with Laravel equivalents.
4. Admin Panel: Choose Sulu admin (API-driven) vs Laravel admin.
5. Advanced Features: Mailables-based provider integrations; custom validation rules.

Operational Impact

Maintenance

• Release Cadence: Upstream ships frequently and now tracks Symfony majors quickly (Symfony 8 support landed in a patch release). Laravel’s slower cycle means version skew is structural, not incidental. Mitigate with Composer platform-check and CI matrix testing across supported Symfony/Laravel combinations.
• 3.0.1 Maintenance Read: Low-risk patch — no deprecations, no removals, no migration guide required. Two behavioral changes to watch (redirect links, form cache reset) and one refactor (XML→PHP service definitions) with no API surface change.
• Fork Cost (increased slightly): Any fork carrying XML service overrides must be rebased onto PHP definitions. Budget a rebase task, not a merge.
• Adapter Layer: Ongoing maintenance to stay in sync with upstream definition changes; pin the bridged service list in tests.
• Documentation: SuluFormBundle docs assume a Symfony/Sulu context and do not cover Laravel integration; the adapter layer will be effectively undocumented unless the team writes it.

Support

• Upstream Support Posture: Healthy — active contributors, including two first-time contributors in this release, and prompt Symfony 8 enablement. Good signal for longevity.
• Internal Support Burden: Concentrated in the adapter layer, which is bespoke and unsupported upstream. Identify a named owner; this is the single point of failure for the integration.
• Vendor Escalation: No commercial support path; reliance on community issue triage for defects in the bundle.

Scaling

• Form Submission Throughput: Submission handling is request-scoped and cache-backed; the per-request cache reset in 3.0.1 is favorable for correctness but means form definitions are rebuilt per request. Under high volume, benchmark definition-build cost or front with a cache warmer.
• Long-Running Processes: The cache reset removes a class of stale-definition bugs in queue workers and Octane-style runtimes — a genuine operational improvement for the Laravel side of a hybrid deployment.
• Admin UI Load: Sulu’s admin remains the heaviest component; keep it on a separate service/container from the Laravel frontend so drag-and-drop field operations cannot degrade request latency.
• Data Layer: PHPCR queries remain the scaling weak point when bridged into a relational Laravel environment; plan a read-path cache.

Failure Modes

• Symfony/PHP Floor Mismatch: Co-hosting the bundle and Laravel in one runtime pins PHP to the higher of the two requirements — now potentially 8.4. A mismatch surfaces as a hard composer resolution failure or, worse, a runtime fatal.
• Implicit Request Accessor Reliance: Post-3.0.1, any adapter assuming Request::get() fallback behavior will silently return null for attributes — manifesting as missing form data rather than an exception. Highest-value regression test to write.
• Redirect Breakage: External redirect forms now resolve through the link provider; misconfigured or unmapped targets can produce dead redirects in production.
• Cache Staleness (inverted): If the host application implements its own form-definition cache layered on top, the bundle’s per-request reset will not help; stale definitions persist independently.
• Fork Drift: Diverged forks fail to absorb security patches; detection is delayed because the fork is not in upstream CI.

Ramp-Up

• Skills: Requires Symfony DI, Doctrine, and Sulu admin familiarity on top of Laravel — a genuinely scarce combination. The PHP service definitions in 3.0.1 lower the reading barrier for the DI graph but do not reduce the conceptual load.
• Onboarding Time: Estimate the adapter layer as a multi-sprint workstream before the first production form; the pilot in Sequencing step 1 is the cheapest way to calibrate that estimate.
• Documentation Debt: Assume the team writes its own integration runbook; upstream docs will not cover the Laravel path.
• Recommendation: Adopt 3.0.1 over 3.0.0 for any new work — it is a safe patch that buys Symfony 8 runway and fixes request-accessor correctness. But it does not change the strategic verdict: the Laravel integration remains low-feasibility and high-effort, and the buy-vs-build question (Filament Forms / Laravel-native) should still be answered before the abstraction phase begins.