Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Krumo Bundle

Krumo Bundle Laravel Package

oodle/krumo-bundle

A Symfony bundle that integrates Krumo, the popular PHP debugging tool, to replace print_r and var_dump with clean, collapsible, syntax-highlighted dumps of arrays, objects, and variables. Speeds up debugging with readable structure inspection.

View on GitHub
Deep Wiki
Context7

Symfony2 bundle for using Krumo in symfony2

Frequently asked questions about Krumo Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle
adachsoft/api-version-bundle
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager