Dumpio

This page covers the Symfony side of the dumpio/client package. Read the PHP library page first for the basics (dio(), Dumpio::dump(), typed helpers) — everything there works in Symfony too. Here we add the Dumpio bundle and its automatic capture.

Setup

Register the bundle — dev-only is recommended:

1// config/bundles.php
2return [
3    // …
4    Dumpio\Symfony\DumpioBundle::class => ['dev' => true],
5];

There's no configuration tree to write. The bundle (and the static client under it) reads everything from the environment:

Note the difference from Laravel. Symfony uses DUMPIO_DISABLE (off when set), not DUMPIO_ENABLED. Registering the bundle only for the dev environment (as above) is what keeps it out of production; within dev it's on unless you set DUMPIO_DISABLE.

What it captures automatically

Once the bundle is registered, it wires up capture based on which Symfony components you have installed. Nothing here needs code changes.

Exceptions (always on)

The bundle registers an exception subscriber that forwards every kernel.exception to the viewer as an exception dump with the current request context — so an error shows a parsed stack trace and request details instead of just the Symfony error page. See the app's Exceptions page for how they render.

Doctrine queries

If you have Doctrine DBAL 4, the bundle registers a doctrine.middleware that forwards every executed SQL statement as a query dump on the database channel. It captures the SQL, the bound parameters (positional binds collapse to an ordered list, named binds keep their :name keys — just like the Laravel query dump) and the execution time. On DBAL 3 (or without Doctrine) the middleware simply isn't registered.

Messenger

With symfony/messenger installed, the bundle forwards the message lifecycle — sent / received / handled / failed — as event dumps on the messenger channel. This is the Symfony equivalent of Laravel's queued-job listeners.

Mail

Set DUMPIO_LISTEN_MAIL=true (and have symfony/mailer) and the bundle captures every outgoing email via the MessageEvent, forwarding it as a mail dump with a rendered preview (HTML + text + envelope) in a sandboxed iframe. It's off by default because email payloads are large.

1DUMPIO_LISTEN_MAIL=true

Unlike Laravel, Symfony's MessageEvent has no cancel hook, so there is no intercept_mail here — the subscriber only captures mail, it can't swallow the real send. To stop dev mail from actually going out, point the mailer at a null transport instead:

1MAILER_DSN=null://null

Outgoing HTTP-client calls

Set DUMPIO_LISTEN_HTTP_CLIENT=true (and have symfony/http-client) and the bundle decorates the http_client service so every outgoing request is forwarded as an http dump with status and timing. The decorator is non-blocking and checks the flag per request. If your app defines no http_client service, the decorator is dropped cleanly.

Cache

Set DUMPIO_LISTEN_CACHE=true (and have symfony/cache) and the bundle decorates the app cache pool (cache.app) so every operation is forwarded as an event dump on the cache channel — cache.hit / cache.missed (with the key), cache.written, cache.forgotten and cache.invalidated (with the tags). The decorator is a pure passthrough built on Symfony's own TraceableAdapter: it never changes what the cache returns and never throws into your app; only the telemetry is added. This mirrors the Laravel cache events, so both frameworks land the same shape in the viewer. Off by default because it sits in front of every cache call. If your app defines no cache.app service, the decorator is dropped cleanly.

Twig templates

Set DUMPIO_LISTEN_VIEWS=true (and have twig/twig) and the bundle registers a Twig ProfilerExtension; on kernel.terminate each rendered template is forwarded as a measure dump on the views channel (template name + render time + memory), so you can see which views cost what. Off by default because the profiler instruments every template.

dump() / dd() interception

Set DUMPIO_INTERCEPT_DUMPS=true and Symfony's dump() / dd() (VarDumper) are routed into the viewer instead of rendering inline. dd() still stops the request.

Turning capture on and off at runtime

The bundle seeds sensible defaults at boot — exceptions, Doctrine queries, and Messenger are on; mail, dumps, the HTTP client, cache, and views follow their env flags — and every one of them is runtime-toggleable:

1Dumpio::stopShowingQueries();   // quiet the query firehose for a moment
2$service->run();
3Dumpio::showQueries();          // and back on
4 
5Dumpio::showAll();              // everything on
6Dumpio::stopShowingAll();       // everything off

There's a show…() / stopShowing…() pair for Queries, Exceptions, Jobs (Messenger), Mail, HttpClient, Cache, Views, and Dumps.

Send logs to the viewer (Monolog)

The Dumpio\Log\DumpioHandler works the same under Symfony — register it as a Monolog handler to stream your app logs into Dumpio as log dumps (level → color). It works with Monolog 2 and 3 and never throws back into the logging pipeline.

Manual dumps anywhere

The static client and global helpers work from anywhere in your code, independent of the automatic capture:

1\Dumpio\Dumpio::query($sql, $bindings, $timeMs);
2dumpio($entity, 'entity');
3dio($order)->green()->channel('checkout');

See the PHP library page for the full set of helpers.