Debugging & Packs

Hey Maxime,

It sounds like a CORS problem... or probably your assets are just not available. Could you open the URL that is failed with net::ERR_ABORTED error in a new tab? Did you see the same 404 error or you can load the asset successfully?

Cheers!

Hey

CSS and Images are not loading for me neither, I have a net::ERR_ABORTED 404 (Not Found).

My Symfony app is running in a docker container.

Shoud I have webpack for this?

Thanks!

Hey Coder!

Yea... this stuff is the worst. We don't have any plans to cover this, but I'll add it to our idea list - it's a question we DO get from time-to-time.

Good luck!

Hello, can you make a tutorial on how to debug xdebug when it does not stop on breakpoints. It just not stop without giving any message. In phpstorm and docker. I am sick of this. When running from command line.

Yes, the "composer remove symfony/profiler-pack" command really works.
Removed "symfony/profiler-pack": "^ 1.0" from the composer.json project. As needed.
And in the /vendor directory there is symfony/profiler-pack, as required.

Thank!

Yeah fine!! it perfectly works . Thank you Ryan

Hey Maxim Mandrik!

Hmm... yes, I think that would work just fine :). As you mentioned, your project depends on symfony/debug-pack, and it depends on symfony/profile-pack, so you should be able to remove symfony/profiler-pack and have no changes.

To test it, run this:

composer remove symfony/profiler-pack

If we're correct, then you will ONLY see symfony/profiler-pack being removed - you will not see any other libraries being removed.

Cheers!

Hey Maxim Mandrik!

I think that's an excellent suggestion - it confuses too many people (understandably). We'll add a note.

Cheers!

Hey yao!

Ah, interesting! So, don't worry about this :). This deprecation is not caused by your code, but bu SensioFrameworkExtraBundle. So, it needs to be fixed in *that* bundle (and then eventually you can upgrade to the fixed version). In fact, this was fixed a few days ago in that bundle (https://github.com/sensiola... and is available in the latest version of the bundle. Try running composer update sensio/framework-extra-bundle to get the latest version.

Cheers!

Hello guys,

After running composer require debug pack, i have this depreciations showing up on my browser down the page

error('A tree builder without a root node is deprecated since Symfony 4.2 and will not be supported anymore in 5.0.')

and another one

$rootNode = $treeBuilder->root('sensio_framework_extra', 'array');

I think i should replace "sensio_framework_extra " by " symfony_framework_extra " . What do you think about that.

I don't want to blow up my project so i am looking for advices.

Thank you.

I have a question about how Composer works.

I want to make the composer.json file at the root of the project minimalist.

There is a line in the project root in the composer.json file:
"symfony / profiler-pack": "^ 1.0"

In "symfony / debug-pack" composer.json is:
"symfony / profiler-pack": "*"

Can I remove the line from the root composer.json:
"symfony / profiler-pack": "^ 1.0"

How to do it better? Manually or some team in the composer?

Make at least a note with the text that in the previous lesson xdebug was used instead of var_dump.
This is confusing when learning, because it seems that something is not working as the author of the video and it needs to be fixed.

Hey Czar Pino!

Ahh, thank you! Made my morning :).

> Appreciate the enlightenment on XDebug. I just installed it and it worked like a charm

Awesome! Super happy that worked!

> I was originally just concerned with the dump behavior throwing off other learners before they get to this chapter

When you saw your message, i had the same thought! I wish I had thought about that when originally recording it. If we get another message about this, we'll add a note to the video.

Cheers!

Sir weaverryan I'm a fan of your work in the Sf community! Appreciate the enlightenment on XDebug. I just installed it and it worked like a charm (now my output matches the previous video). Actually, I was originally just concerned with the dump behavior throwing off other learners before they get to this chapter.

Hey Czar Pino!

You're 100% correct. Without the debug-pack installed, dump() in twig does exactly what you said: it's a var_dump(). The reason I didn't get a memory error is because I have XDebug installed, which makes var_dump() a bit prettier, and avoids recursive memory issues. But, either way, the debug pack gives us a much better situation anyways :).

Cheers!

Sorry in advance for not extensively investigating but executing a `{{ dump() }}` in twig (as instructed in the previous video "Web Debug Toolbar & the Profiler!") results in the `app` variable being effectively `var_dump`ed causing an out of memory error. Installing the debug recipe seemed to prevent this and also resulted in a prettier output (as shown in this video).

Diego Aguiar @Victor Bocharsky Tonight, I run "composer update" that moves me from v4.1.0 => v4.1.1. Now it works as expected. So we can mark as "solved". Thank you fy help.

Hey Yahya A. Erturan

If you are getting a blank screen, it means that the dd(); statement did execute, but probably your "$records" variable was empty? Try changing it to var_dump('hello', $records); die;
If that's not the case, I believe you require to install and activate "x-debug" in your system so the "dump" function works properly.

Cheers!

@Victor, thank you fy message but I believe I couldn't tell it properly. It is not about dd() or dump();die; It is about viewing the dump :) Here it is: I use Symfony 4.1, debug-pack and profiler-pack, all are installed. I am creating a new controller, ie. UserController and creating a new method, ie. list.

    /**
     * @Route("/users/list", name="users_list", methods={"GET"})
     * @param Request $request
     * @param EntityManagerInterface $entityManager
     */
    public function list(Request $request,
                                     EntityManagerInterface $entityManager)
    {
        $repo = $entityManager->getRepository(User::class);
        $records = $repo->findAll();

        dd($records);
    }

Boom! Blank screen. Before it was shown on the screen. Am I missing something? Check out please, I didn't decide to render a twig template, or respond in json. I just want to see the output of dump() or dd(). Blank screen!

Hey Yahya,

In Symfony 4 there's a "dd()" function which is equal to "dump(); die;" - you can upgrade and use it. But you can totally do like you said, i.e. manually add "die;" after "dump()": "dump($var); die;" - so your output won't go to the Web Debug Toolbar, instead, it will be printed in browser.

But if we're talking about end points that return JSON - probably showing Web Debug Toolbar is not a good idea, because your JSON response is invalid in this case. If you send AJAX requests - you can either find links to profiler pages of those requests (if you hover over AJAX icon in Web Debug Toolbar) or I use Google Chrome Debug Toolbar to open the request and see its content with dumped value, but in this case probably would be better to use var_dump() or print_r() functions instead, because dump()'s output contain extra HTML for syntax highlighting.

I hope it helps :)

Cheers!

Victor Bocharsky In controller, I want to dump($var);die; - How can I achieve this? Forcing us to render a html template (so that profiler will shown) is not a good solution. What if I am working on AJAX endpoint, no html? If I am not wrong, before we could use it in controller out of the box. Correct?

Well I can create a new Service with the below function:

 
function mydumper(array $arguments) {
    dump($arguments);
    return new Response('<html><body></body></html>');
}

In this case it works correctly; blank screen + debug bar + my dump inside and nothing else. But is this the right way?

Hey Petru,

Yes, if you interrupt executing with "die()" or dump() in Twig files - it prints the output immediately. But by design, if you dump() something in PHP files and do not interrupt with "die()" - it is not showed on the page - instead the output is putted into Symfony web debug toolbar, see a small target icon. It's on purpose to hide the debug output from the main content to prevent breaking the page.

Cheers!

Hi Ryan,

I have a problem with dump() in the show method.It doesn't show anything.... prior to an answer u gave on the previous chapter about installing debug pack this chapter i waited to test it out,yet it didnt solve the problem.If i {{ dump() }} in .twig template, everything's ok, but in the controller it just not show it if i dont use die; right after ... Any ideas on this?

@Victor,

Thank you so much. I find that dump in the Symfony Web Debug Toolbar below.

Hey Ramsey,

Please, make sure you have installed Var Dumper component with:

composer info symfony/var-dumper

IIRC, that this works in dev/test environments only. If you're in prod - it probably won't work. And keep in mind that in PHP files dump() works in a bit different way than in Twig templates: if you dump something in PHP file - you won't see the output on the page, but you can see it in the Symfony Web Debug Toolbar below.

P.S. If your output of var_dump() is just black/white, i.e. not colorful and nice - then you need to install and enable Xdebug PHP extension which makes var_dump() output much nicer.

Cheers!

Hey weaverryan

Your first part is 100% correct. Thanks what I have done before this chapter.

The second part, in my PHP, var_dump works, but in symfony4, dump() is not work. I don't why. That's why I ask at here hope someone can help me to fix it. I did cache clear, but the problem is still there.

You know, in my controller, dump() it's not work, it won't output anything. Only var_dump() works. but the output is uglier not prettier. Before this chapter, dump() in my controller works and pretty. My controller code is following:

/**
* @Route("/article/{slug}")
*/
public function testArticle ($slug)
{
$comments = [
'I ate a normal rock once. It did NOT taste like bacon!',
'Woohoo! I\'m going on an all-asteroid diet!',
'I like bacon too! Buy some from my site! bakinsomebacon.com',
];

dump($comments, $this);//dump at here is not work, it cannot do anything. Only var_dump works.

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

Hey Ramsey Jiang!

Hmm. This should *not* be the situation. You're 100% correct that, before this chapter, the dump() function in Twig was using var_dump. That is Twig's default functionality. But when you install the debug-pack, Symfony replaces this with the VarDumper component implementation (that is responsible for the pretty, black background).

But in PHP, the dump function is provided by the VarDumper component. If that component is not present, then the dump() function should not exist. And, of course, if it IS present, the VarDumper always prints "pretty". I can't think of how the dump() function would ever produce the uglier, var_dump version of the code :/. Just in case, try clearing your cache:

php bin/console cache:clear

If that doesn't work, could you post your controller code? I know it's simple - but I'm really not sure what the issue could be :).

Cheers!

Hey Diego Aguiar
You know, at the previous chapter, I could use dump in my controller. I could view a background color is black of that dump. In the twig, I also could use dump, but the dump is as the php var_dump.

After I viewed this chapter, the dump in my controller as the php var_dump. the dump in my twig, it has a black background color.

Now do you make sence what I mean in my question?

Hey Ramsey Jiang

What you mean with that you made controller's dump uglier?
When you dump something in a controller, don't you see a new input at your profiler's bar?

Cheers!

In previous chapter, I made prettier controller dump but ugly twig dump.
After I view this chapter, I made a prettier twig dump but ugly controller dump.

Who can help me to make prettier both controller dump and twig dump? My composer dev is following:

"require-dev": {
"easycorp/easy-log-handler": "^1.0.2",
"symfony/debug-bundle": "^3.3|^4.0",
"symfony/dotenv": "^4.0",
"symfony/monolog-bundle": "^3.0",
"symfony/phpunit-bridge": "^3.3|^4.0",
"symfony/profiler-pack": "^1.0",
"symfony/var-dumper": "^3.3|^4.0"
},

Hey Christian,

Yeah, no problem! The main thing is that it works ;)

Cheers!

Hi Victor,
I am sorry but I did not remember from which version of composer I updated.
I am on Mac os X High Sierra. I did sudo composer self-update. (I have put composer globally on /usr/local/bin/composer)
Since I wrote this question, I retried a lot of time and it works every time.
I am afraid it will remain a mystery.
Thanks for your reply.

Best regards

Christian

Hey Christian,

Hm, what OS are you on? I think it's a feature in Composer upgrade process. How did you upgrade to the latest version? Maybe during upgrade some symlinks were changed by Composer, but you didn't see actual changes in the same terminal tab. It's difficult to be sure without extra debugging which is pointless since now it works for you. Also, it's interesting to see the real version of composer when you saw that error, I bet you had not the latest one.

Anyway, I'm glad it works now for you.

Cheers!

I tried again after a system restart and now it works.
Don't know why, but it's cool

Hi Ryan,
I installed composer 1.6.2 and created project from symfony/skeleton.
Then I added debug pack.
When typing "composer unpack debug" I get the following error:

[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "unpack" is not defined.

I tried with composer 1.5.6 and I get the same error.
Do you have any idea ?

It all makes sense then! So, you definitely found a bug in Symfony - nice work! It's quite difficult to do :). When you have time to change the order of the bundles, it will fix the problem. But in the future (when the bug fix is merged), it won't make a difference thanks to your report!

Cheers!

I can't change the order of these bundles for now.
I'll do it tomorrow. ;)

Hmm, actually, I did not exactly do what you did after symfony/skeleton... :-s
Anyway, thanks you very much for your help. :)

bundles.php :
return [
Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
Doctrine\Bundle\DoctrineCacheBundle\DoctrineCacheBundle::class => ['all' => true],
Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle::class => ['all' => true],
Symfony\Bundle\DebugBundle\DebugBundle::class => ['dev' => true, 'test' => true],
Symfony\Bundle\MonologBundle\MonologBundle::class => ['all' => true],
Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true],
Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
Symfony\Bundle\SecurityBundle\SecurityBundle::class => ['all' => true],
Nelmio\Alice\Bridge\Symfony\NelmioAliceBundle::class => ['dev' => true, 'test' => true],
Fidry\AliceDataFixtures\Bridge\Symfony\FidryAliceDataFixturesBundle::class => ['dev' => true, 'test' => true],
Hautelook\AliceBundle\HautelookAliceBundle::class => ['dev' => true, 'test' => true],
Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle::class => ['all' => true],
Omines\DataTablesBundle\DataTablesBundle::class => ['all' => true],
Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle::class => ['all' => true],
];

... and here's the pull request to fix the bug https://github.com/symfony/... :).

What's interesting is that you should NOT have hit this bug if you installed the packages in the same order that I did. Did you install in a different order? That would explain it :).

Cheers!

Hey Thomas Talbot!

Indeed... I believe you are correct that the core dump() function is winning! And I think I've found the problem. Would you mind posting your config/bundles.php file here? I believe if you change the order of TwigBundle and DebugBundle in this file, it will fix it :). I'm going to open an issue or PR on Symfony's repo about this!

Cheers!

Thanks for the explanation. It was about what I thought. :)
Perhaps the twig-bridge's one is overriden by twig/twig ? weird...

Here the output of bin/console debug:container --show-private twig.extension.dump :

Information for Service "twig.extension.dump"
=============================================

---------------- ---------------------------------------------
Option Value
---------------- ---------------------------------------------
Service ID twig.extension.dump
Class Symfony\Bridge\Twig\Extension\DumpExtension
Tags twig.extension
Public no
Synthetic no
Lazy no
Shared yes
Abstract no
Autowired no
Autoconfigured no
---------------- ---------------------------------------------

Hey Thomas Talbot!

Ah, so it gets more interesting :). Well, in case it helps, let me show you how it works behind the scenes. When the DebugBundle is activated, it registers this service: https://github.com/symfony/.... This activates a dump() function (https://github.com/symfony/... that should OVERRIDE the one from core Twig: https://github.com/twigphp/...

Phew! So, you should *not* see the twig_var_dump in your compiled HTML. A few things to check:

1) Clear your cache, just in case
2) Try bin/console debug:container --show-private twig.extension.dump - does it show that this service exists?

Cheers!

My bad, I'v forgotten to say that I installed it via debug-pack.

So, I have this problem with symfony/debug-bundle installed. :/

Hey Thomas!

Yes, I know this! Actually, you did a very similar thing to what I did in the previous chapter. When I installed the profiler, that installed the var-dumper, which gave us the pretty dump() function in PHP. But in Twig, my dump() was ALSO "ugly" until THIS chapter, when I ran composer require debug. I believe the missing piece is Symfony's DebugBundle (which comes with the debug "pack"): this adds the integration between TwigBundle and VarDumper. So if you install that, or just install "debug" to get the debug pack, it should get pretty in Twig :).

Cheers!

Hi Ryan,

Thanks a lot for this course. :)

When you added symfony/var-dumper, your `{{ dump() }}` got prettier. :)
I have the symfony/var-dumper and symfony/twig-bundle... but it outputs with xdebug not VarDumper component.

In the var/cache/dev/twig/xxx.php, I have :
`echo twig_var_dump($this->env, $context);`
This is the dump function in the twig/twig.

Have you already seen this problem ?