Ezpublish Legacy Utility Bundle Laravel Package

Getting Started

• Install with composer require snce/ezpublish-legacy-utility-bundle. The package is tagged GPL-2.0 and its last release is from February 2018, so pin an explicit constraint (^1.0 or the exact tag) and check its composer.json for PHP/eZ version requirements before upgrading other dependencies.
• Register the bundle in ezpublish/EzPublishKernel.php inside registerBundles(). As with any eZ 5+ bundle, it must be registered in the kernel, not only in config.yml.
• Look first at:
  • DependencyInjection/ and Resources/config/ — these tell you which services and parameters the bundle exposes.
  • The bundle's README and any Resources/doc/ — small utility bundles usually document their helpers there rather than in code comments.
  • Twig/ or Templating/ if present — that is where legacy-facing Twig extensions usually live.
• First use case: call legacy APIs from new-stack code. Boot the legacy kernel through the ezpublish_legacy.kernel service and run legacy calls inside its callback, rather than including legacy files manually. Typical example:

$legacyKernel = $this->get('ezpublish_legacy.kernel');
$legacyKernel->runCallback(function () {
    // eZContentObject, eZINI, eZUser, etc. are now available
    return eZContentObject::fetch($id);
});

• A second early use case is reusing legacy helpers (INI access, content lookups, legacy URL handling) from a Symfony controller or a Twig template without duplicating the old template stack.

Implementation Patterns

• Legacy call wrapper service. Wrap ezpublish_legacy.kernel->runCallback() in a small application service so controllers and commands do not depend on the raw kernel. This keeps the boundary between new and legacy code explicit and testable.
• Twig-side helpers. If the bundle registers a Twig extension, prefer exposing narrow functions (e.g. legacy INI lookup, content fetch by ID) over a general "run arbitrary legacy code" function. Broad escape hatches tend to spread legacy assumptions into new templates.
• Incremental migration. Keep legacy templates and modules running, and use the bundle from the new stack to call shared legacy logic. Add new Symfony routes/controllers alongside old modules rather than rewriting a module wholesale.
• Siteaccess awareness. When calling legacy code from a Symfony request, make sure the legacy siteaccess is set (eZSiteAccess::change(...) or the siteaccess resolved by the legacy kernel) before accessing INI or content. Utility bundles usually assume the kernel has already resolved the siteaccess.
• Reuse from commands and workers. The legacy kernel can be driven from Symfony console commands and long-running workers too. Wrap each unit of work in a fresh runCallback() and avoid sharing legacy globals across iterations.
• Compose with eZ's own legacy bridge. The bundle is additive: use your normal ezpublish_legacy.kernel / legacy routing setup, and treat this bundle's services as helpers layered on top. Check Resources/config/services.yml for aliases you can inject instead of fetching from the container.
• Configuration. Merge the bundle's config into config.yml under its root key if it exposes one; otherwise its services are auto-wired by the standard extension. Keep environment-specific legacy paths/INI overrides in config_<env>.yml.

Gotchas and Tips

• Unmaintained by default. Two stars, no dependents, and a 2018 release mean no upstream fixes for newer eZ/PHP versions. Audit the code before relying on it, and consider copying the handful of helpers you actually use into your own bundle.
• PHP and eZ version drift. Old bundles frequently use APIs removed or changed in later eZ 5.x/6.x and in PHP 7.2+. Run composer why-not and check the bundle's requirements before upgrading the platform.
• Legacy kernel boot cost. Every runCallback() boots/uses the legacy kernel. Do not call it per item in a loop if you can batch; the overhead dominates for large imports and reports.
• Globals and state leakage. Legacy code relies on globals ($http, eZINI caches, current user). In long-running processes or tests, reset or reinitialize between requests; otherwise one request's siteaccess/user leaks into the next.
• Autoloading. Legacy classes are not PSR-4. If a helper returns legacy objects, keep them behind your wrapper and convert to new-stack Value Objects before they cross into controllers or templates.
• Cache clearing is two-sided. After changing bundle config, clear both the Symfony cache (php app/console cache:clear, or bin/console on newer setups) and the legacy cache (php bin/php/ezcache.php --clear-all or the legacy admin). A stale legacy cache hides config changes.
• Debugging. Enable ezpublish.debug and legacy DebugSettings together; a failing legacy call inside runCallback() often surfaces as a generic exception unless legacy debug output and logs are on. Check ezpublish/logs/ and the legacy var/log/ directory.
• Extension points. Before editing vendor code, override the bundle's services in your app's services.yml (same service ID), or decorate them. Twig extensions can be replaced by registering your own with the same function names.
• Composer hygiene. Fork or use a VCS repository entry if you need patches, and keep a changelog note in your app repo explaining the pin, since the upstream is unlikely to tag new releases.