- Is idci/contact-form-bundle a Laravel package?
- No. idci/contact-form-bundle is a Symfony bundle from the Symfony 2.1–2.3 era, registered through AppKernel.php and the Symfony bundle contract, and it ships no Laravel service provider, facade, or config file. There is no Laravel integration path for it, so on a Laravel roadmap this is a reuse-as-reference decision rather than an adoption decision.
- Can I install idci/contact-form-bundle in a Laravel app with Composer?
- No, Composer resolution fails deterministically. The bundle targets the PHP 5.3–5.6 era and pulls Symfony 2.x components plus Swiftmailer, while modern Laravel requires PHP 8.1 or 8.2 and actively maintained dependencies. This is a known-cost incompatibility, not an open question worth spiking.
- Which Laravel versions does idci/contact-form-bundle support?
- None. The package predates Laravel's current package auto-discovery and has no Illuminate contracts, service providers, or Blade views. It also has effectively no adoption signal, with roughly one star and zero dependents, so nobody is maintaining a Laravel bridge.
- How do I build a configurable contact form in Laravel instead?
- Use first-party Laravel pieces: a Blade view for the form, a FormRequest for validation rules, a Mailable sent through the Mail facade with queue-backed delivery, CSRF middleware, and the throttle middleware for rate limiting. Add a honeypot field or a maintained Altcha or CAPTCHA package for spam control. Field sets and recipients become config values or a small settings table, which gives you the configurability the bundle advertised without any porting.
- Is idci/contact-form-bundle still maintained or getting security updates?
- No. Symfony 2.x reached end of life in November 2018, and Swiftmailer, which the bundle likely depends on, went end of life in 2021, so there is no upstream security response. The bus factor is a single organization, with no issue triage or PR review activity to surface bugs.
- What are the alternatives to idci/contact-form-bundle for a Laravel contact form?
- The native Laravel stack is stronger than the bundle on every axis: FormRequest validation, Mailables with queued delivery, CSRF middleware, throttling, and maintained spam-protection packages. If you need a prebuilt form UI, choose an actively maintained Laravel package rather than a Symfony 2 artifact. Every capability the bundle advertises is either first-party in Laravel or covered by a package with current support.
- Is idci/contact-form-bundle safe to run in production with user PII?
- No. Contact forms ingest names, email addresses, and free-text messages, and routing that through abandoned code with unmaintained mailer and templating dependencies is an incident-response liability, not just a code-quality preference. Treat it as a compliance and risk issue rather than a stylistic one.
- How is idci/contact-form-bundle configured, and does that map to Laravel?
- It is configured through Symfony dependency-injection extensions, Resources/config/services.yml, annotation routing, Symfony Form types, and Twig templates. None of that maps to Laravel's config files, service container, routing, or Blade, so there is no adapter seam worth building. Read the configuration only to recover the intended field set and recipients.
- Can I port or reuse idci/contact-form-bundle code in a Laravel project?
- Porting will not converge, so don't budget for it. Strip the Symfony wiring and what remains is a form type, a mailer call, and a template, which is hours of native Laravel work rather than days of migration. Use the repository as a requirements reference: read the form type for fields and constraints and the templates for copy structure and error presentation, then discard the code and record the rejection so it is not re-litigated.
- How do I test a contact form in Laravel after replacing this bundle?
- Write feature tests that post to the contact route and assert validation errors, then use Mail::fake() to assert the Mailable was sent to the configured recipient with the expected data. Add tests for CSRF rejection, throttle limits, and honeypot or CAPTCHA behavior. Because the form is native Laravel code, these tests run against your real framework version instead of an end-of-life Symfony runtime.