Krumo Bundle Laravel Package

Getting Started

Be clear about what you are installing. mmucklo/krumo-bundle is a Symfony 2/3 bundle that wraps the legacy Krumo dumper. It is not a Laravel package: there is no service provider, no config/app.php entry, no auto-discovery, and nothing in it touches Laravel's container or HTTP kernel. On a Laravel codebase you cannot "leverage the bundle" — the most you can do is vendor the underlying mmucklo/krumo library standalone. Everything below is written for the realistic day-to-day case: you have inherited a legacy Symfony app (or you are deliberately spiking Krumo's output) and want to get useful dumps fast.

Install

composer require --dev mmucklo/krumo-bundle

If Composer resolution fails against a modern stack (very likely — old Symfony/Twig/PHP constraints), fall back to the library only:

composer require --dev mmucklo/krumo

Register — dev/test only, never prod

// app/AppKernel.php  (Symfony 2.x / 3.x)
if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
    $bundles[] = new \Mmucklo\KrumoBundle\MmuckloKrumoBundle();
}

Confirm the exact FQCN and bundle alias inside vendor/mmucklo/krumo-bundle/ before trusting that line — the class name is not documented in the README and follows the vendor/bundle convention, so it is easy to get wrong.

Clear cache, then dump

$products = $em->getRepository(Product::class)->findAll();
krumo($products);      // helper, if the bundle registered it
\Krumo::dump($products); // always-available static form

Where to look first

1. vendor/mmucklo/krumo-bundle/DependencyInjection/Configuration.php — the YAML root key (typically the bundle alias, e.g. mmucklo_krumo) and which knobs actually exist.
2. vendor/mmucklo/krumo-bundle/Resources/config/services.xml — what the bundle really wires. Usually this is little more than autoloading the Krumo class plus (maybe) a Twig extension. Don't assume a Twig function exists.
3. vendor/mmucklo/krumo/ — the dumper itself. Skins, depth limits, and output config live here, not in the bundle.

First use case: replacing a wall of print_r on a nested Doctrine entity or collection with a collapsible, colour-coded tree that shows class names, property visibility, and recursion guards. That is the entire value proposition; it is genuinely nicer than var_dump on deep object graphs.

If you are actually in Laravel, skip the bundle and use what you already have: dump() / dd() (via symfony/var-dumper, already installed), Illuminate\Support\Facades\Log, Telescope for request/query context, or Debugbar. dump() writes HTML in web requests and to stderr in CLI, which covers the same ground with zero legacy surface.

Implementation Patterns

Controller inspection loop. The reliable rhythm is dump → stop → read the tree:

public function showAction($id)
{
    $order = $this->getDoctrine()->getRepository(Order::class)->find($id);

    krumo($order);              // inspect the entity
    krumo($order->getLines());  // inspect the relation
    die;                        // stop before the template renders

    return $this->render('order/show.html.twig', ['order' => $order]);
}

Always die/exit after the dump you care about, or the output ends up mid-template.

Dump collections, not items. Krumo paginates and collapses large arrays far better than looping:

\Krumo::dump($order->getLines()->toArray());

It also survives self-referencing graphs (Doctrine proxies, bidirectional relations) that would recurse forever under print_r.

Environment-gated service debugging. If you leave a dump in a service, gate it on the debug flag so it is inert elsewhere:

if ($this->getParameter('kernel.debug')) {
    \Krumo::dump($payload);
}

Introspection helpers. Handy when you need to know what the framework loaded mid-request:

\Krumo::backtrace();  // call stack
\Krumo::includes();   // required files
\Krumo::classes();    // declared classes
\Krumo::functions();  // declared functions

Global presentation, set once. Skins are static state (bootstrap, macosx, vista, modern, …). Set it in a dev bootstrap or kernel boot listener rather than per call site:

\Krumo::$skin = 'macosx'; // confirm the property/config shape in the vendored version

If the bundle exposes this via YAML, check Configuration.php for the real root key before writing config that silently does nothing.

Twig: verify before use. Symfony templates cannot call arbitrary PHP functions. Only use {{ krumo(var) }} if services.xml registers a Twig extension — otherwise dump in the controller and pass the rendered string, or just dump and die.

Build a swap-ready wrapper now. Because the bundle is thin and unmaintained, isolate it behind one helper so replacement is a one-file change:

// src/AppBundle/Debug/Dumper.php — dev usage only
final class Dumper
{
    public static function dump($value): void
    {
        class_exists('Krumo') ? \Krumo::dump($value) : dump($value);
    }
}

Call Dumper::dump() everywhere. When you migrate to Symfony VarDumper (or move to Laravel), you edit this class and nothing else.

Never dump into machine-readable output. Krumo emits HTML plus inline CSS/JS. JSON API actions, console commands, and XHR handlers will be corrupted — use var_export()/dump() for CLI and the profiler for AJAX.

Gotchas and Tips

• Dev-only registration is not optional. Krumo renders complete variable contents into the response — passwords, API tokens, session data, SQL parameters. Conditional registration in AppKernel.php is the only guardrail between a debug dump and a data leak. Treat any Krumo output visible outside local dev as a security incident.
• XSS and information disclosure. Krumo writes raw values into markup; hostile or user-controlled strings can execute. Never enable it in staging/production, never screenshot it into tickets, and never leave it reachable on a shared environment.
• Non-HTML responses break. See above: no JSON, no CLI, no XHR. This is the single most common cause of "why is my API returning garbage."
• die after dumping. Symfony keeps rendering otherwise, and Krumo's assets are emitted once per request — a dump inside <head> typically destroys layout and subsequent JS.
• Symfony 2/3 only. No Flex recipe, no config/bundles.php support, no auto-discovery. On Symfony 4+ either register manually or drop the bundle and composer require --dev mmucklo/krumo and call \Krumo::dump(). The bundle adds little beyond autoload convenience.
• PHP 8+ compatibility is unestablished. Expect deprecations, E_STRICT-era code, and possible fatals on modern PHP. This repo targets PHP 5.x/7.x. Test in an isolated dev container before assuming it runs.
• Composer conflicts. Old Symfony/Twig constraint ranges will fight a modern dependency tree. If you must keep it, isolate it in a dev-only require-dev block and expect --no-dev production installs to be clean while local installs are not.
• Zero maintenance backstop. 6 stars, 0 dependents, no support contract. File a bug and you are the maintainer. Plan removal, not support.
• Static global state. Krumo::$skin and friends are process-wide; behaviour can differ between an HTTP request and a CLI command in confusing ways. Set them in one place.
• Large object graphs cost memory. Dumping a big Doctrine collection can inflate response size and exhaust memory. Dump a slice (array_slice, ->slice(0, 10)) when you only need the shape.
• Verify names, don't guess. The bundle alias, config root key, FQCN, and whether a Twig extension exists are all undocumented. Read Configuration.php and services.xml in vendor/ before writing config or templates — silent no-ops here are the norm.
• Replacement path, for when you're ready: symfony/var-dumper (dump()/dd()), Symfony Web Profiler, or — on Laravel — Laravel Telescope, Debugbar, Clockwork, or Ray. All are actively maintained, PHP 8+ compatible, and already present in most modern stacks.