Ez Legacy Debug Bundle Laravel Package

Getting Started

This is a Symfony 2-era bundle — not a Laravel package — so the first step is deciding whether you actually have the target environment. It only makes sense inside a Symfony app running eZ Publish/eZ Platform Legacy (the ezpublish-legacy bridge), where the legacy stack has its own debug output that never reaches the Symfony profiler. The bundle's job is to pipe that output into a Web Profiler panel.

Minimal setup (inside that environment):

composer require --dev mmz-srf/ez-legacy-debug-bundle

Register it in app/AppKernel.php, dev/test only:

if (in_array($this->getEnvironment(), ['dev', 'test'])) {
    $bundles[] = new Srf\EzLegacyDebugBundle\SrfEzLegacyDebugBundle();
}

Clear the cache, then hit any page and open /_profiler — look for the eZ Legacy panel in the toolbar. That is the entire "hello world": one request, one panel, legacy debug lines visible next to the Symfony collector timeline.

Look first at the bundle's Resources/config/ and its Collector/DataCollector class. In a bundle this small, the collector is the documentation: it defines exactly which legacy globals/ezDebug output it reads and what the template renders.

First real use case: you have a legacy module or template override that silently does nothing, and you want to see the legacy debug log, template resolution path, and query activity without SSHing in and tailing var/log/ezpublish.log.

Implementation Patterns

Treat it as a dev-only observability shim, not a library you call. You rarely invoke its API directly; you enable it and then write legacy code that emits debug data it can pick up.

• Enable legacy debug at the source. The panel is only as good as what eZ Legacy writes. Ensure the legacy siteaccess settings (settings/override/site.ini.append.php) have debug output enabled (DebugSettings / [DebugSettings] DebugOutput=enabled), otherwise you get an empty panel and blame the bundle.
• Bracket a suspect code path. Wrap the legacy call you are debugging with eZDebug::accumulate() / eZDebug::writeDebug() calls, then reload and read the panel. This is the day-to-day workflow: instrument, request, inspect, remove instrumentation.
• Pair it with the Symfony collectors. The value is correlation — the legacy panel next to the Doctrine/Request/Time panels lets you confirm whether a slow page is the legacy template layer or the Symfony side.
• Keep it out of prod. Guard the kernel registration by environment (as above). The collector adds per-request overhead and profiler storage churn.
• Container/DI extension points. If the bundle exposes a config tree (many of these do, e.g. to toggle which debug sections render), configure it under srf_ez_legacy_debug: in config_dev.yml rather than editing vendor code — vendor edits vanish on the next composer update.
• In a Laravel shop, the transferable pattern is the idea: a dev-only service provider that registers a debugbar/Telescope collector reading a legacy subsystem's log. Port the concept (Debugbar::addCollector(...), a Telescope watcher), never the bundle itself.

Gotchas and Tips

• Archived, 2015, 2 stars, zero dependents. No maintenance, no security fixes, no PHP 7/8 compatibility. Expect fatal errors on modern PHP from old Symfony 2 APIs (getName(), getCollector() signatures, KernelInterface era assumptions). Budget for a fork-and-patch, not a composer require.
• Hard dependency on eZ Legacy. Without ezpublish-legacy present and bootstrapped, the collector either no-ops or throws on missing eZDebug/eZINI classes.
• Profiler-only visibility. Nothing renders outside /_profiler. "It doesn't show anything" is almost always: wrong environment, bundle not registered, or legacy debug output disabled upstream — check those three before touching the bundle.
• Panel is read-only. It surfaces information; it doesn't fix template resolution or cache issues. If legacy caches are stale (ezcache/var/cache), the panel will faithfully show you stale debug data. Clear caches first.
• Memory and log growth. Legacy debug accumulation can be heavy on large pages; if you see OOM in dev, disable the collector rather than chasing a phantom app bug.
• Debugging the bundle itself: the profiler panel template lives under Resources/views/Collector/; if a value is missing, var_dump from the collector's collect() method is faster than reading the Twig template.
• Forking is the realistic path if you must use it. Pin the fork, keep it in require-dev, and document the PHP version constraint. If you're on modern eZ Platform, the legacy bridge is itself deprecated — invest in Symfony's native profiler + Monolog channels instead.