Zymfony Bundle Laravel Package

Getting Started

Install:

composer require saa/zymfony-bundle

Register the bundle (Symfony 4 uses config/bundles.php):

Saa\ZymfonyBundle\ZymfonyBundle::class => ['all' => true],

Where to look first: open the bundle's src/ directory and read Resources/config/services.yaml (or services.xml). That file lists every compatibility service the bundle exposes — it is the definitive map of what you can inject and what ZF1 behavior has been shimmed. Next, read the README.md and any CHANGELOG.md; migration bundles tend to accumulate per-version notes describing what ZF1 class was replaced and how.

First use case: pick one non-critical ZF1 controller — a read-only page, an admin report, an internal status endpoint. Register the Zymfony services it needs (typically a DB adapter or a Zend_View replacement) in config/services.yaml, then rewrite the controller as a Symfony controller that consumes those services. Deploy side-by-side with the remaining ZF1 code (both applications served behind the same web root or a front-controller switch) and verify the output matches byte-for-byte before touching anything transactional.

Implementation Patterns

Strangler-fig routing. Keep the ZF1 front controller for untouched routes and add a Symfony route (or an Apache/nginx rewrite) that sends newly migrated paths to public/index.php. A common pattern is a LegacyController in Symfony that forwards to the old Zend_Controller_Dispatcher for URLs under /legacy/* until each is individually rewritten.

Alias ZF1 service names to Symfony services. If the bundle registers compatibility classes under canonical ZF1 identifiers, configure aliases so legacy code that does Zend_Registry::get('db') resolves to a Symfony-managed service:

services:
    Zend_Db_Adapter_Abstract:
        alias: Saa\ZymfonyBundle\Db\Adapter

This lets you replace the implementation without touching a line of legacy code, and it's the cheapest way to migrate DB layers before controllers.

Wrap, don't rewrite. ZF1 code that reaches for static singletons (Zend_Db_Table::getDefaultAdapter(), Zend_Registry) is best left alone. Provide the singleton's value from a Symfony boot() or a compiler pass that pre-populates the legacy globals with services pulled from the container. This keeps the migration incremental: Symfony "owns" the wiring, ZF1 code "sees" what it expects.

Bridge the view layer. If Zymfony provides a Zend_View-compatible service, bind it to Twig for output escaping and reuse existing .phtml templates from inside Symfony until they are ported. Prefer Twig for anything new; the Zend-view bridge exists to buy time, not to migrate to.

Migrate tests alongside code. ZF1 code typically has zero meaningful tests. When you port a controller, write a Symfony functional test against the new route before deleting the old one. This is the only reliable way to prove behavior parity when you delete the ZF1 version.

Use the container's debug toolbar. In dev, the Symfony profiler (doctrine, http_client, dump) is your best window into the new code path. Legacy code will not appear in the profiler — if you need to profile it, wrap it: log entry/exit around the legacy call from the Symfony side.

Gotchas and Tips

• SF4 only. This bundle targets Symfony 4. If you are on SF5+, you will hit deprecations (controller-as-service, Bundle interface changes, autowiring differences). Pin symfony/* to ^4.4 or fork and patch. Do not start a greenfield project on this — it is a bridge, not a framework.

• Autoloading legacy code. ZF1's class naming (Zend_Db_Table_Abstract) needs a PSR-0 or classmap fallback in composer.json. Add "autoload": { "psr-0": { "Zend_": "vendor/zendframework/zendframework1/library/" } } and run composer dump-autoload. Without this you get silent "class not found" at runtime, not at build time.

• Global state bleed. Zend_Registry, Zend_Controller_Front::getInstance(), and Zend_Db_Table::setDefaultAdapter() are process-wide. In Symfony, this means once any request populates them, they persist for the worker's lifetime under RoadRunner/Swoole/PSR-7 workers. If you move off FPM, reset these between requests or the bundle's shims will cross-contaminate requests. On classic FPM this is a non-issue; on long-lived workers it is a landmine.

• Zend_Db vs Doctrine. The compatibility DB layer mirrors ZF1's fetchAll/fetchRow/query semantics, not Doctrine's entity model. Do not try to make DQL work against the Zymfony adapter — keep the two layers separate (ZendDbAdapter for legacy repositories, Doctrine for new entities) and only unify once legacy code is gone.

• Config quirks. ZF1's application.ini-style config rarely maps cleanly to Symfony's config/packages/*.yaml. Expect to duplicate configuration temporarily: Symfony's config is authoritative for new services, but legacy code may still read the old ini file. Keep both in sync via a build step or accept the drift and document it.

• Debugging. When a legacy call inside a Symfony controller fails, the stacktrace crosses the bundle's shim layer and is often unhelpful. Set xdebug.var_display_max_depth high and log the shim's input/output, or wrap the call in a try/catch that rethrows with a message naming the ZF1 class you were calling. This is the fastest way to isolate whether the bug is in your migrated code or the compatibility layer.

• Extension points. Most migration bundles expose a CompilerPass or a settable "legacy bridge" interface so you can register your own adapters (e.g., a custom logging adapter, or a Zend_Cache replacement). Check the bundle's DependencyInjection/ directory — anything tagged zymfony.adapter (or similar) is intended for this. This is where you should plug in your app-specific bridges rather than editing vendor code.

• Low maintenance risk. 32 stars, zero dependents, MIT license. Treat this as a throwaway scaffold: budget for a fork in your own vendor namespace so you can patch Symfony 5/6 compatibility yourself, and plan the exit (retire the bundle once ZF1 code is gone) from day one.