Zf1Wrapperbundle Laravel Package

Product Decisions This Supports

• Incremental modernization vs. big-bang rewrite. This package is a concrete artifact of the strangler-fig pattern: run the legacy Zend Framework 1 app in-process behind a modern framework, route to it, and carve out features one at a time. It gives a PM a reference implementation to point at when arguing against a multi-quarter freeze-and-rewrite — the highest-leverage roadmap decision on a legacy PHP estate.
• Build vs. buy vs. borrow. The answer here is borrow the pattern, not the package. That is a legitimate and common PM outcome: adopt the architectural approach (front-controller delegation, shared request/response abstraction, shared session/identity), reject the artifact. Document it so the team doesn't relitigate it in six months.
• Legacy decommission sequencing as a measurable bet. If the ZF1 app still carries revenue, wrapping it lets new work land on a maintained framework while the legacy surface shrinks behind an explicit boundary. That converts an unbounded legacy risk into a per-release burndown metric — "routes/requests still delegated to ZF1" — which is exactly the KPI a roadmap needs to justify continued spend.
• Scope framing for a consolidation investment. The existence of a wrapper implies someone judged the legacy app too large or too entangled to port outright. A PM should treat that as a prompt to quantify the legacy surface (controllers, Zend_Db usage, bootstrap coupling) before committing budget in either direction.
• Framework-fit caveat that shapes the decision. Despite this review's framing as a Laravel/PHP package, it is a Symfony 2 bundle, not a Laravel package. There is no drop-in Laravel path. Laravel and Symfony share HttpFoundation/HttpKernel, so the idea ports cleanly; the code does not. The PM decision is therefore about the pattern, on whichever modern framework you already run.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony 2.x with a Zend Framework 1 application you cannot yet retire.
• You want a short-term compatibility shim to unblock incremental porting, and you accept that you are adopting a thin, unmaintained dependency you will fork and own.
• The legacy surface is small enough that wrapping is cheaper than rewriting the affected flows.
• You have a named engineer who owns the fork and will carry it forward with a decommission date attached.

Look elsewhere — and this is the likely verdict — if any of the following apply:

• You are on Laravel. Wrong framework, wrong kernel integration. Use a route fallback or middleware that delegates to a ZF1 front controller, or front both apps behind a reverse proxy and route by path. That is roughly a day of work and zero dependencies.
• Platform support is a hard requirement. ZF1 reached end of life in 2016; Symfony 2 exited security support in 2018–2019. Both halves of this bridge are unsupported. Adopting it means pinning your new code to an EOL framework — introducing a second legacy stack rather than escaping one.
• Supply-chain posture matters. Zero stars, zero dependents, no evident test suite, no releases, no maintainer activity. A package with no dependents has no one else finding its bugs. Treat it as untrusted code requiring full internal review before it touches production.
• In-process bridging is not your only option. If the legacy app is stable and mostly read-only, splitting at the edge (path or subdomain routing) eliminates the entire dual-runtime failure class and lets the two halves deploy and scale independently.
• You are still deciding whether to modernize at all. A dead wrapper is not evidence the migration is viable; it is evidence one team tried once and stopped.
• You need a support contract, roadmap, or release cadence. There is none, and there will not be.

Net: this is a reference reading, not a dependency. Read the source for the delegation technique, then build the twenty-to-fifty lines you actually need inside your own codebase.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source bridge that lets a modern PHP application hand requests off to an old Zend Framework 1 application, so new features can ship in a maintained framework while the legacy system is retired piece by piece rather than all at once. The approach is sound and matches how we want to sequence this work — it is the difference between a controlled, measurable wind-down and a multi-quarter feature freeze. The specific package is not adoptable: it targets an obsolete framework version, has no community, no maintainer, and no security support, and adopting it would add a second end-of-life framework to our estate. Recommendation: adopt the pattern internally, budget a small amount of engineering to implement it ourselves, and treat the package as documentation. Cost avoided: a full rewrite. Cost incurred: a bounded, owned integration layer with a named owner and a kill date.

To engineering (one paragraph): Don't vendor this. It's a Symfony 2 bundle wrapping ZF1 — both EOL, zero dependents, no tests, and Composer will pin us to a Symfony 2 tree that defeats the point of the migration. If we're on Symfony, implement delegation against HttpKernel directly in a fraction of the surface area and own it. If we're on Laravel, build a middleware or route fallback that hands off to the ZF1 front controller, and own that instead. Either way: define the seam explicitly, decide the handoff direction and prove it survives real request lifecycles (routing, auth, CSRF, sessions, error pages, redirects, file downloads, streaming), and log every delegated request so we can track delegated-route count as our burndown metric. Expect the hard parts to be dual autoloaders, container leakage, divergent error handling, and session/identity sharing — plan for those explicitly. The one thing worth copying from this repo is the shape of the boundary, not the code behind it.

Ask: approve a scoped spike (1–2 engineer-weeks) to prove the delegation seam on the highest-traffic legacy routes, with a written governance rule that no new feature code lands on the ZF1 side. Gate the full migration budget on two signals: the spike passing real request lifecycles, and a delegated-route burndown curve that falls quarter over quarter. Without that commitment, we should choose edge-splitting or targeted rewrite instead — a permanent bridge buys nothing and costs a second EOL framework.