Chapters

8 Chapters | 37:26 |

01

Bootstrapping Micro-Symfony

9:16
02

AppBundle, Routing and Annotations

4:53
03

Container, Twig: All Smooth

2:14
04

Web Debug Toolbar and Profiler

2:16
05

dotenv: Environmental Variables

3:24
06

Environments

7:14
07

Where's my app/console

2:59
08

Logging and Adding other Tools

5:10

This tutorial has a new version, check it out!

> Symfony 3 > The Symfony Micro-Framework

Buy Access to Course

04.

Web Debug Toolbar and Profiler

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $10.00

Previous Chapter

Next Chapter

Right now, there's no floating web debug toolbar on our pages. That's one of the best features of Symfony, and so I want it in my micro-edition too.

Instead of getting a lot of features automatically, we need to enable things one-by-one when and if we need them. The same is true for the web debug toolbar: it comes from the WebProfilerBundle. This lives in our project, but it's not enabled yet. Add it in AppKernel down below the others:

            Copy Code

                            Show All Lines

                        27 lines
            |
            AppKernel.php
        
                Show Lines

                                                    // ... lines 1 - 5
                            
            class AppKernel extends Kernel
        
            {
        
                public function registerBundles()
        
                {
        
                Show Lines

                                                    // ... lines 10 - 16
                            
                    $bundles[] = new \Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
        
                Show Lines

                                                    // ... lines 18 - 19
                            
                }
        
                Show Lines

                                                    // ... lines 21 - 25
                            
            }

Next, head into config.yml - we need a little bit of configuration. Add a web_profiler key with a toolbar option. Set this to %kernel.debug%:

            Copy Code

                            Show All Lines

                        12 lines
            |
            config/config.yml
        
                Show Lines

                                                    // ... lines 1 - 9
                            
            web_profiler:
        
                toolbar: %kernel.debug%

That's a special parameter that's equal to the debug argument we pass to AppKernel in index.php:

            Copy Code

                            Show All Lines

                        24 lines
            |
            web/index.php
        
                Show Lines

                                                    // ... lines 1 - 8
                            
            $debug = true;
        
                Show Lines

                                                    // ... lines 10 - 17
                            
            $kernel = new AppKernel($env, $debug);
        
                Show Lines

                                                    // ... lines 19 - 24

Mostly, this flag is used to hide or show errors. But for now, we'll also use it to decide if the web debug toolbar should show up or not.

Also, under framework, add a profiler key with an enabled option that we'll also set to %kernel.debug%:

            Copy Code

                            Show All Lines

                        12 lines
            |
            config/config.yml
        
            framework:
        
                Show Lines

                                                    // ... lines 2 - 6
                            
                profiler:
        
                    enabled: %kernel.debug%
        
                Show Lines

                                                    // ... lines 9 - 12

We have debug set to true, so try it! No toolbar yet - just this nice error:

Unable to generate a URL for the named route "_wdt" as such
route does not exist.

This is the error you usually get if you're generating a URL to a route, but you're using a bad route name. The web debug toolbar and profiler are fueled by real Symfony routes, and those routes need to be included for this all to work. On the Standard Edition, I already have the app/config/routing_dev.yml file open, because we need to copy the top two entries. Find config/routing.yml and paste those there:

            Copy Code

                            Show All Lines

                        12 lines
            |
            config/routing.yml
        
                Show Lines

                                                    // ... lines 1 - 4
                            
            _wdt:
        
                resource: "@WebProfilerBundle/Resources/config/routing/wdt.xml"
        
                prefix:   /_wdt
        
            _profiler:
        
                resource: "@WebProfilerBundle/Resources/config/routing/profiler.xml"
        
                prefix:   /_profiler

Try one more time. There's the toolbar, with all of the goods we love.

7 Comments

Sort By

MattWelander 2 years ago

Hi! I have an issue with internal redirects (http504) is there a way to track internal redirects? I know that the profiler toolbar lets me see where the current response was redirected from (if any), but according to the webhost, I exceed the limit of 10 internal redirects... I'm not doing any redirects in my code, so it must be a configuration thing. Either in my symfony setup/routing, or in the nginx setup... Is there any logg or such in symfony that can reveal this to me?

| Reply |

Victor SFCASTS MattWelander 2 years ago

Hey Matt,

Yeah, you need to enable redirects intercepting in the profiler, see the docs about how to enable it: https://symfony.com/doc/current/reference/configuration/web_profiler.html#intercept-redirects

Other than that feature, I'm not sure there's anything that could help you to debug it. Well, you can try to dd() somewhere in the code to actually stop at some point, but that's probably it. Just look closer at the page from which you're redirected, i.e. inspect that code for any redirects, etc. Oh, there's also a useful debug_backtrace() PHP function that might help you, but you need to find a good way where to call it in your code, though IIRC the Symfony profiler with enabled redirects intercepting will give you the same info, or even more. So, just look at the WDT closer. Or, try to google for a better way maybe, not sure if it's possible to do it on a higher level - there might be a better way I didn't know about probably.

But still, even 10 redirects per 1 request sounds not quite right, so I bet you just have circular redirects.

Cheers!

| Reply |

Roberto 6 years ago

Nice tuts!
But got a 404 on "_wdt/6d6966" while refreshing the index page.

I have _wdt route definition below "app_annotations" in config/routing.yml.

Any idea?

| Reply |

Roberto Roberto 6 years ago

Of course, I find the answer right after posting my comment... :)
We just need the proper .htacces file in web folder.

1 | Reply |

Nina 6 years ago

Hello

Why we use:
$bundles[] = new \Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();

And not put new \Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
шnto an existing array $bundles in the AppKernel.php?
Why my tool bar looks different from you show in the lesson

What mean % around %kernel.debug%?
What function they perform?

| Reply |

Victor SFCASTS Nina 6 years ago

Hey Nina,

Well, in this chapter there's no any important reason do it with "$bundles[]" instead of putting it into $bundles array on initialization. But answer is simple: this bundle is related to development mode and should not be used in production. That's why we separate it from other bundles which we use in both development and production. In shorts, we can easily exclude it for production later. But technically, there're no any difference for PHP interpreter ;)

It could look differently if you upgrade Composer packages. But if you will use our locked dependencies, i.e. download course code and execute "$ composer install" instead of upgrade - it will look the same I think.

"%" is a special character when Symfony parse YAML files which means we're referencing to a parameters, i.e. "%kernel.debug%" means we're referencing to the "kernel.debug" parameter, so when Symfony parses this YAML file it will be replaced with its real value.

Cheers!

| Reply |

Nina Victor 6 years ago

Thanks for the detailed explanation!

| Reply |

Symfony 2

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "symfony/symfony": "^2.7", // v2.7.2
        "sensio/framework-extra-bundle": "^3.0", // v3.0.9
        "vlucas/phpdotenv": "^2.0", // v2.0.1
        "symfony/monolog-bundle": "^2.7" // v2.7.1
    }
}

Previous Chapter

Next Chapter

Web Debug Toolbar and Profiler

Share this awesome video!

Keep on Learning!

7 Comments

Delete comment?

What PHP libraries does this tutorial use?

Show Lines	// ... lines 1 - 5
	class AppKernel extends Kernel
	{
	public function registerBundles()
	{
Show Lines	// ... lines 10 - 16
	$bundles[] = new \Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
Show Lines	// ... lines 18 - 19
	}
Show Lines	// ... lines 21 - 25
	}

Show Lines	// ... lines 1 - 9
	web_profiler:
	toolbar: %kernel.debug%

Show Lines	// ... lines 1 - 8
	$debug = true;
Show Lines	// ... lines 10 - 17
	$kernel = new AppKernel($env, $debug);
Show Lines	// ... lines 19 - 24

	framework:
Show Lines	// ... lines 2 - 6
	profiler:
	enabled: %kernel.debug%
Show Lines	// ... lines 9 - 12

Show Lines	// ... lines 1 - 4
	_wdt:
	resource: "@WebProfilerBundle/Resources/config/routing/wdt.xml"
	prefix: /_wdt

	_profiler:
	resource: "@WebProfilerBundle/Resources/config/routing/profiler.xml"
	prefix: /_profiler