- Is heliopsis/ezforms-bundle a Laravel package?
- No. It is a Symfony bundle written for the legacy eZ Publish 5.x platform, from the PHP 5.x and Symfony 2.x era. It depends on the Symfony kernel and bundle registration, the Symfony Form component, Twig, and eZ Publish's content model. Laravel's service container, request lifecycle, Eloquent, and validation stack do not map to those assumptions.
- Can I install heliopsis/ezforms-bundle in a Laravel app with Composer?
- Technically you can require it, but it will not work as a drop-in. There is no Laravel auto-discovery, no service provider compatibility, and no native form or validation integration. Getting it running would mean standing up a Symfony and eZ Publish runtime and bridging it to Laravel over HTTP.
- Which Laravel or PHP versions does ezforms-bundle support?
- None targeted at Laravel. The bundle is built for legacy PHP and Symfony 2.x alongside eZ Publish 5.x. It is almost certainly incompatible with PHP 8+ and Symfony 4+ without a fork. Verify the composer.json constraints before spending any spike time on it.
- Is the GPL-2.0 license a problem for a commercial Laravel SaaS?
- Possibly a hard stop. GPL-2.0 is a strong copyleft license, and linking it into a distributed or proprietary product can trigger obligations your legal team will want to review. For a SaaS-delivered Laravel product, treat this as a blocker until legal signs off in writing.
- How do I build forms bound to content nodes in Laravel without this bundle?
- Use Laravel-native primitives: form requests for validation, Eloquent polymorphic relations to attach submissions to content records, policies for permission checks, and Blade, Livewire, Inertia, or API endpoints for rendering and submission. This covers the same form-to-content binding pattern without the legacy runtime. Most teams can rebuild it in one to two weeks.
- Is heliopsis/ezforms-bundle actively maintained?
- There are no meaningful maintenance signals: roughly 11 GitHub stars, zero dependents, and a single maintainer. There is no visible security response process or upgrade path. Adopting it directly means your team owns patches, compatibility fixes, and the fork.
- What are the best alternatives to ezforms-bundle for Laravel developers?
- For Laravel-first projects, Laravel's built-in validation plus Blade, Livewire, Inertia, or Filament admin panels covers the same ground with first-party support. If you are on Symfony, the standard Symfony Form component is the modern equivalent. Only consider this bundle if your runtime is already eZ Publish 5.x.
- How do I migrate from eZ Publish ezforms-bundle to Laravel?
- Treat the bundle as a requirements source, not a port target. Catalog the behaviors it encodes, such as form definitions per content type, content-class-to-form binding, submission handling, permission checks, and Twig rendering, then rebuild them natively in Laravel. Do not copy bundle code across. Cut over behind feature flags with a rollback path for submissions and content association.
- Does ezforms-bundle work with PHP 8 and modern Symfony?
- Almost certainly not without a fork. It targets the Symfony 2.x and eZ Publish 5.x generation of tooling, well before PHP 8 type changes and modern Symfony contracts. Confirm the eZ Publish generation you run, since Ibexa is a different platform, and expect deprecation and compatibility work before any spike.
- When does it actually make sense to use heliopsis/ezforms-bundle?
- Only inside an existing Symfony plus eZ Publish estate where the runtime is already present and the GPL-2.0 license is cleared. Even then, isolate it as a sidecar service exposing a narrow HTTP contract and let Laravel act as the client. For a Laravel-only roadmap, use it as a design reference for form-to-content binding, not as a dependency.