- Is mainlycode/zf1wrapperbundle a Laravel package?
- No. It is a Symfony 2 bundle that bridges Zend Framework 1 components into Symfony applications; there is no Laravel service provider, middleware, or container bridge. If you are evaluating it for a Laravel app, none of its integration code applies. In Laravel the equivalent seam is something you write yourself, typically a catch-all route or middleware delegating to the ZF1 front controller.
- Can I install this bundle in a Laravel application with Composer?
- Composer resolution will fail against any supported Laravel or Symfony version because the package pins a Symfony 2.x tree and an old PHP constraint. Even if you forced the install, there is no Laravel integration code to use. Treat it as a published reference implementation of an idea, not a dependency.
- What does Zf1WrapperBundle actually do?
- It registers and bootstraps ZF1 resources inside a Symfony application, exposes ZF1 services through the Symfony container, and provides configuration glue for legacy integration. The intended use is route-by-route migration: new feature work lands on Symfony while legacy ZF1 modules keep serving traffic behind a seam. It keeps ZF1 dependencies isolated rather than requiring a full rewrite.
- Which Symfony and PHP versions does this bundle support?
- It targets Symfony 2.x, and Symfony 2.8 exited security support in late 2018. Its PHP constraint almost certainly predates PHP 8. There are no releases or compatibility updates, so do not assume it runs on any currently supported Symfony or Laravel version.
- How do I install and configure Zf1WrapperBundle?
- There are no published releases and no visible test suite, so installation would be from source and effectively unverified. Conceptually you register the bundle in the Symfony kernel, point it at your ZF1 library paths and bootstrap resources, and let it wire the autoloader and container. In a modern application the Composer constraints will block you long before configuration matters.
- How do I access ZF1 services from the Symfony container?
- The bundle's container handoff is Symfony 2 shaped: ZF1 services are registered into the Symfony dependency injection container. Laravel's container is a different abstraction and there is no adapter, so you would have to write that bridge yourself. Expect the hard parts to be sessions, authenticated identity, error handlers, and autoloader coexistence, not the service lookup itself.
- Can I migrate a legacy Zend Framework 1 app incrementally to Symfony with this bundle?
- Yes as a pattern, not as this package. Wrapping legacy code, routing unmatched requests across a seam, and carving out route by route is a legitimate anti-corruption strategy with per-route cutover. But adopting this artifact freezes the new side at Symfony 2, which means introducing a second legacy framework rather than escaping one. The cost is never in the bridge; it is in the surrounding ZF1 application, and this package does nothing for that.
- What are the risks of running ZF1 and Symfony in the same PHP process?
- You get two DI containers, two autoloaders, two error handlers, two session abstractions, and two logging stacks in one process. Failures across those boundaries are subtle and hard to attribute during incident response, which lengthens MTTR exactly when the legacy system is least understood. Also, fronting an end-of-life ZF1 runtime with Symfony 2 does not remediate unpatched CVEs and can create a false impression of modernization for stakeholders.
- Is Zf1WrapperBundle maintained, tested, or safe for production?
- The signals are poor: zero stars, zero dependents, no releases, and no visible test suite. Both halves of what it bridges are end-of-life, with ZF1 losing upstream support in 2016 and Symfony 2.8 leaving security support in 2018. That combination is the strongest available signal that nobody runs this in production and nobody is fixing it, so every defect you hit you own entirely.
- What are the alternatives to Zf1WrapperBundle for Laravel or Symfony?
- For Laravel, the seam is a catch-all route or middleware delegating to the ZF1 front controller, or an ingress-level path split, which is roughly a day of work and zero third-party surface. For Symfony, the bridge surface is thin: autoloader coexistence, request and response translation, container handoff, and session and identity sharing, typically a few hundred lines. Forking or reimplementing is usually cheaper and safer than depending on this bundle, provided you also set a rule that no new code lands on the ZF1 side and agree a decommission date.