If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
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:
... lines 1 - 5 | |
class AppKernel extends Kernel | |
{ | |
public function registerBundles() | |
{ | |
... lines 10 - 16 | |
$bundles[] = new \Symfony\Bundle\WebProfilerBundle\WebProfilerBundle(); | |
... lines 18 - 19 | |
} | |
... 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%
:
... 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
:
... lines 1 - 8 | |
$debug = true; | |
... lines 10 - 17 | |
$kernel = new AppKernel($env, $debug); | |
... 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%
:
framework: | |
... lines 2 - 6 | |
profiler: | |
enabled: %kernel.debug% | |
... 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:
... 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.
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!
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?
Of course, I find the answer right after posting my comment... :)
We just need the proper .htacces file in web folder.
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?
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!
// 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
}
}
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?