Ezforms Bundle Laravel Package

Product Decisions This Supports

• Platform-fit correction: This is not a Laravel package. heliopsis/ezforms-bundle is a legacy Symfony bundle for eZ Publish. A PM should treat it as a reference pattern or legacy stopgap, not a Laravel dependency.
• Build vs. buy: If the requirement is “attach a Symfony form to an eZ Publish content class,” the bundle may save glue code. If the requirement is “attach forms to content in a Laravel product,” build natively with Laravel form requests, validation, policies, Eloquent/content models, and Livewire/Inertia/API endpoints.
• Roadmap sequencing: Adopting it commits the team to keeping an eZ Publish-era estate alive. Do not combine adoption with a migration to Laravel or Ibexa in the same planning horizon.
• Feature scoping: It supports narrow content-driven capture such as contact pages, applications, or surveys bound to content nodes. It does not support a general form-builder roadmap with conditional logic, multi-step flows, payments, CRM routing, webhooks, or spam tooling.
• Licensing gate: GPL-2.0 is a product-distribution decision, not just an engineering one. For proprietary or SaaS-delivered products, legal review should be a hard gate before adoption.
• Vendor-risk budgeting: 11 stars, 0 dependents, and a single-maintainer profile mean the team owns the code if adopted. PM should budget a fork owner, upgrade path, and security-patching plan.
• Laravel leverage: The reusable value is architectural: form definitions bound to content, handler/service separation, validation and rendering flow. Reimplement that pattern natively rather than bridging Symfony/eZ Publish into Laravel.

When to Consider This Package

Consider it when:

• You already operate an eZ Publish 5.x/Symfony 2.x-era estate and cannot migrate this cycle.
• The need is genuinely “forms bound to eZ Publish content classes,” not a broad form-builder capability.
• Your team is already on Symfony forms and wants to reuse that stack.
• GPL-2.0 is compatible with your distribution model, or legal has cleared it.
• PHP, Symfony, eZ Publish, and Composer compatibility have been verified against the runtime.
• You are prepared to fork, vendor, and maintain it internally with a dated exit plan.

Look elsewhere when:

• The target stack is Laravel or a modern Symfony application. There is no clean native fit.
• You are on Ibexa/eZ Platform; the successor platform has different form and content APIs.
• You need SLAs, active security patching, or a maintained vendor relationship.
• The product is proprietary and distributed without GPL-2.0 clearance.
• The requirement is a general-purpose form builder with workflows, payments, integrations, or advanced submission management.
• The scope is small enough that a short in-house implementation is cheaper than licensing review and long-term fork ownership.

How to Pitch It (Stakeholders)

To executives: This is a small, single-maintainer Symfony/eZ Publish bundle — not a Laravel package. It is cheap in license fees but expensive in ownership: near-zero community adoption means we fix it if it breaks, and GPL-2.0 creates a distribution risk that legal must clear. Recommendation: do not adopt for new Laravel or product work. Only justify it as a legacy stopgap on an eZ Publish estate with a funded owner and a dated exit plan.

To engineering: Do not composer require this into a Laravel application. Treat it as a reference for the “form bound to content” pattern and rebuild natively using Laravel validation, policies, content models, and Livewire/Inertia/API endpoints. If eZ Publish must remain, isolate the Symfony side behind a narrow API contract and fork the bundle internally. Verify PHP/Symfony/eZ compatibility before any spike.

One-line ask: Fund either a short compatibility-and-legal spike for legacy eZ Publish use, or fund the small native Laravel equivalent — but do not let it enter the stack unexamined as “just a Composer dependency.”