- Can I use oodle/krumo-bundle in a Laravel application?
- No. oodle/krumo-bundle is a Symfony 2.x bundle whose only job is registering Krumo and wiring its assets through Symfony's DI container and bundle system, and Laravel has no bundle registry, AppKernel, or equivalent asset pipeline. There is no service provider, facade, publishable config, or package auto-discovery, so a Laravel install would need hand-written glue even if Composer resolved the constraints. Use dd(), dump(), Telescope, Debugbar, Ignition, or Ray instead.
- How do I install oodle/krumo-bundle?
- You require the package with Composer inside a Symfony 2 application and enable it in AppKernel, which exposes the krumo() helper and loads the Krumo assets for you. Because the package predates Symfony Flex, there is no recipe and no auto-discovery step. There is also no Laravel service provider, so the normal Laravel install flow does not apply.
- Which PHP and Symfony versions does oodle/krumo-bundle support?
- It is a Symfony 2-era bundle, so expect PHP 5.x bounds and Symfony 2 APIs; Symfony 2 itself reached end of life in 2019. Assume it will not install on PHP 7.4 or 8.x, or alongside Laravel 8 and newer, until a composer require --dry-run proves otherwise. Check the PHP constraint, Symfony version bounds, deprecated API usage, and autoload behavior before planning anything around it.
- What is the difference between krumo() and Laravel's dd() or dump()?
- Both render nested arrays and objects as inspectable trees, but krumo() writes its collapsible HTML straight into the response stream, while Laravel's dump() and dd() go through symfony/var-dumper and integrate with the framework's error handling and CLI output. dd() also halts execution, which Krumo does not do by default. For Laravel work the native helpers cover the same need and are actively maintained.
- Is it safe to enable Krumo output in production?
- No, treat it strictly as local debugging tooling. Krumo dumps can expose session contents, configuration secrets, and model internals to anyone who triggers them, and the raw script and style output corrupts JSON responses, redirects, streamed responses, and file downloads. If you adopt the underlying library at all, gate it behind an environment check or require-dev so it cannot reach a normal request.
- What should Laravel developers use instead of oodle/krumo-bundle?
- Start with framework-native tools: dump() and dd() from symfony/var-dumper, Telescope for queries, jobs, mail, and requests, Laravel Debugbar for the request timeline, and Ignition for exception pages. Ray is a solid option if the team wants a dedicated desktop inspector. All of these are maintained, Laravel-aware, and easy to keep out of production.
- How can I get Krumo-style collapsible dumps without the Symfony bundle?
- Use the standalone Krumo library, such as mmucklo/krumo, or vendor class.krumo.php directly and call it from a single wrapper helper. Put it in require-dev, keep it off the runtime path of normal requests, and contain the surface area to one function so the CSS and JS assets are all you maintain. That sidesteps the Symfony 2 bundle constraints entirely.
- Does oodle/krumo-bundle have active maintenance, tests, or security support?
- There is effectively no ecosystem around it: zero stars, zero dependents, a very low quality score, and no security response channel or upgrade path. Its own platform, Symfony 2, has been unsupported since 2019. If you adopt it in any form, your team owns patching, security review, and Composer constraint maintenance.
- Will krumo() break my JSON, API, or file download responses?
- It can. Krumo writes raw script and style tags directly to the output stream, so any response that depends on clean headers or a specific content type, including JSON APIs, redirects, streamed responses, and downloads, can be corrupted. Keep dumps confined to HTML debug views and never leave the helper enabled on a shared or production environment.
- I maintain a legacy Symfony 2 app. Should I keep oodle/krumo-bundle?
- It can still run where the Symfony 2 stack is intact, but there is no upgrade path and the platform itself is end of life. When you next touch the app, replace Krumo with symfony/var-dumper and the Web Profiler, which give the same readable dumps with actual support. Do not start a new project on this bundle, and pin it under kernel.debug only if a bounded pilot is unavoidable.