Method dump() behaves like method dd().

[kosh2323]

Laravel Version

12

PHP Version

8.2

Database Driver & Version

MySQL 8.4

Description

Not working correctly dump()

Steps To Reproduce

If you update packages via composer or install a new version of Laravel, then for some reason method dump() behaves like method dd(), after applying dump(), the code is not processed, apparently some package is updated, which makes dump()=dd(), in old versions of packages this worked correctly. Why does this happen?

[Muffinman]

Not for me?

Route::get('/', function () {
    dump('test');
    return 'welcome';
});

it('returns a successful response', function () {
    $response = $this->get('/');

    $response->assertStatus(200);
    $response->assertSee('welcome');
});

[kosh2323]

This is what comes back

[Muffinman]

But have you tried it on a fresh L12 installation with no other packages or custom code installed?

[kosh2323]

But have you tried it on a fresh L12 installation with no other packages or custom code installed?

Tried on a new L12 installation, also on a new L11 installation, when installing new versions of dependencies/packages are loaded and it also works incorrectly. There are old projects (L11) with old packages and it works well there, but if you update the "composer update" packages, then the experience is incorrect, one of the packages does this.

[Muffinman]

I'm not sure what to suggest unless you can find the root cause within the var-dumper package. In which case, the bug report probably belongs there.

Maybe your composer has brought in a strange version, here is mine.

composer show symfony/var-dumper


name     : symfony/var-dumper
descrip. : Provides mechanisms for walking through any arbitrary PHP variable
keywords : debug, dump
versions : * v7.3.0
released : 2025-04-27, 1 month ago
type     : library
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage : https://symfony.com
source   : [git] https://github.com/symfony/var-dumper.git 548f6760c54197b1084e1e5c71f6d9d523f2f78e
dist     : [zip] https://api.github.com/repos/symfony/var-dumper/zipball/548f6760c54197b1084e1e5c71f6d9d523f2f78e 548f6760c54197b1084e1e5c71f6d9d523f2f78e
path     : /Users/matt/Sites/******/vendor/symfony/var-dumper
names    : symfony/var-dumper

support
source : https://github.com/symfony/var-dumper/tree/v7.3.0

autoload
files
psr-4
Symfony\Component\VarDumper\ => .
exclude-from-classmap

requires
php >=8.2
symfony/deprecation-contracts ^2.5|^3
symfony/polyfill-mbstring ~1.0

requires (dev)
ext-iconv *
symfony/console ^6.4|^7.0
symfony/http-kernel ^6.4|^7.0
symfony/process ^6.4|^7.0
symfony/uid ^6.4|^7.0
twig/twig ^3.12

conflicts
symfony/console <6.4

[browner12]

Can confirm this happened to me on an recent update as well, and I have not found a solution yet.

It's not behaving exactly like dd(), since you can call multiple dump()s and they'll all execute.

Route::get('/', function () {
    dump('test');
    dump('this executes');
    dump('this executes too');
    return 'welcome';
});

something is happening when it gets to the view. it appears to be truncating the generated HTML.

[kosh2323]

My code is the same

`name : symfony/var-dumper
descrip. : Provides mechanisms for walking through any arbitrary PHP variable
keywords : debug, dump
versions : * v7.3.0
released : 2025-04-27, 1 month ago
type : library
license : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage : https://symfony.com
source : [git] https://github.com/symfony/var-dumper.git 548f6760c54197b1084e1e5c71f6d9d523f2f78e
dist : [zip] https://api.github.com/repos/symfony/var-dumper/zipball/548f6760c54197b1084e1e5c71f6d9d523f2f78e 548f6760c54197b1084e1e5c71f6d9d523f2f78e
path : D:\OSPanel\home\lara122.loc\vendor\symfony\var-dumper
names : symfony/var-dumper

support
source : https://github.com/symfony/var-dumper/tree/v7.3.0

autoload
files
psr-4
Symfony\Component\VarDumper\ => .
exclude-from-classmap

requires
php >=8.2
symfony/deprecation-contracts ^2.5|^3
symfony/polyfill-mbstring ~1.0

requires (dev)
ext-iconv *
symfony/console ^6.4|^7.0
symfony/http-kernel ^6.4|^7.0
symfony/process ^6.4|^7.0
symfony/uid ^6.4|^7.0
twig/twig ^3.12

conflicts
symfony/console <6.4`

[kosh2323]

Can confirm this happened to me on an recent update as well, and I have not found a solution yet.

It's not behaving exactly like dd(), since you can call multiple dump()s and they'll all execute.

Route::get('/', function () {
dump('test');
dump('this executes');
dump('this executes too');
return 'welcome';
});
something is happening when it gets to the view. it appears to be truncating the generated HTML.

Yes, yes, I can’t find any information on official sources either.

[browner12]

I have tried downgrading symfony/var-dumper to 7.2, and also tried downgrading laravel/framework through all minors of v12. no luck

[Muffinman]

Sorry yeah I do get it when actually viewing the route manually. Concerning that the tests are behaving differently!

Note it also happens with redirects and exceptions:

// Doesn't redirect - This makes sense since headers are already sent
Route::get('/', function () {
    dump('test');
    return redirect()->route('dashboard');
});

// Doesn't throw the exception (or at least it isn't rendered/handled by Laravel)
Route::get('/', function () {
    dump('test');
    throw new Exception('test');
    return redirect()->route('dashboard');
});

[Muffinman]

Is it this? symfony/symfony@a69cf15

EDIT: Commenting out these lines does 'fix' the issue.

I'm not sure why they are attempting to resend a header() when two lines above has just determined that headers have already been sent.

[browner12]

If I downgrade symfony/symfony to "~7.2.0" the problem is fixed. Not saying that change is the problem, but it appears it happened on the v7.3 upgrade.

[daniser]

Probably related

[kosh2323]

In old projects with version symfony/symfony 7.1.5 and old packages this works.

[Muffinman]

Looks like they have literally just reverted that commit in the last few mins (until symfony 8.0).

One easy fix would have been for Laravel just to add ob_start() to HtmlDumper::dumpWithSource(). Not sure if that would have unintended consequences.