Chapters
-
Course Code
Compatible PHP versions: ^7.1.3
Compatible PHP versions: ^7.1.3
- This Video
- Subtitles
- Course Script
Web Debug Toolbar & the Profiler!
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Make sure you've committed all of your changes - I already did. Because we're about to install something super fun! Like, floating around space fun! Run:
composer require profiler --dev
The profiler - also called the "web debug toolbar" is probably the most awesome thing in Symfony. This installs a few packages and... one recipe! Run:
git status
Ok cool! It added a couple of configuration files and even some routes in the dev
environment only that help the profiler work. So... what the heck is the profiler? Go back to your browser, make sure you're on the article show page and refresh! Voilà!
Hello Web Debug Toolbar!
See that slick black bar at the bottom of the page! That's the web debug toolbar! It's now automatically injected at the bottom of any valid HTML page during development. Yep, this JavaScript code makes an AJAX call that loads it.
Oh, and it's packed with info, like which route was matched, what controller was executed, execution time, cache details and even information about templates.
And as we install more libraries, we're going to get even more icons! But the really awesome thing is that you can click any of these icons to go into... the profiler.
Hello Profiler: The Toolbar's Powerful Sidekick
OoooOoo. This takes us to a totally different page. The profiler is like the web debug toolbar with a fusion reactor taped onto it. The Twig tab shows exactly which templates were rendered. We can also get detailed info about caching, routing and events, which we'll talk about in a future tutorial. Oh, and my personal favorite: Performance! This shows you how long each part of the request took, including the controller. In another tutorial, we'll use this to dig into exactly how Symfony works under the hood.
When you're ready to go back to the original page, you can click the link at the top.
Magic with The dump() Function
But wait, there's more! The profiler also installed Symfony's var-dumper
component. Find ArticleController
and go to showAction()
. Normally, to debug, I'll use var_dump()
to print some data. But, no more! Instead, use dump()
: dump the $slug
and also the controller object itself:
Show Lines
|
// ... lines 1 - 8 |
class ArticleController extends AbstractController | |
{ | |
Show Lines
|
// ... lines 11 - 21 |
public function show($slug) | |
{ | |
Show Lines
|
// ... lines 24 - 28 |
dump($slug, $this); | |
Show Lines
|
// ... lines 30 - 34 |
} | |
} |
Ok, refresh! Beautiful, colored output. And, you can expand objects to dig deeper into them.
Tip
To expand all the nested nodes just press Ctrl
and click the arrow.
Using dump() in Twig
The dump()
function is even more useful in Twig. Inside the body
block, add {{ dump() }}
:
Show Lines
|
// ... lines 1 - 4 |
{% block body %} | |
{{ dump() }} | |
Show Lines
|
// ... lines 7 - 29 |
{% endblock %} |
Tip
If you don't have Xdebug installed, this might fail with a memory issue. But don't worry! In the next chapter, we'll install a tool to make this even better.
In Twig, you're allowed to use dump()
with no arguments. And that's especially useful. Why? Because it dumps an associative array of all of the variables you have access to. We already knew we had title
and comments
variables. But apparently, we also have an app
variable! Actually, every template gets this app
variable automatically. Good to know!
But! Symfony has even more debugging tools! Let's get them and learn about "packs" next!
54 Comments
I found dump() which start infinite loop. Our Dear Sir explain in the next video let's forsake this go to next video Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeees!!!!!!!!!!!!!!!!!
FYI: In never versions of Symfony there is now dd($var);. This dump();'s your code and stops further execution. It's the same as dump($var); and then die();.
Hey Nicklas,
You're right! The dd() helper method was introduced in Symfony 4.1. Thanks for sharing this useful tip for others.
Cheers!
Hi! Thank you for this course, I didn't where to start with symfony before.
I've got a problem, on the profiler page I can't change panel, when I click on the left nav menu the page reload and stay on the Request/Response panel, any idea where that came from?
Hey Gaël W.
Thanks :)
That's odd. Do you see the nav items active? (in bold white color)
Which Symfony version are you using?
Cheers!
Thanks for the reply, I manage to find the issue by myself finaly, it was a small mistake but very annoying.
I put:
RewriteRule ^(.*)$ index.php?/$1 [L]
Instead of:
RewriteRule ^(.*)$ index.php/$1 [L]
In the .htaccess, so all my uri became a GET and the Request object was empty :)
Ha! nice catch man :)
Tried to get this tutorial going but errors out of the box. The only deviation from the course install instructions is I'm using Docker for the database. Here are the errors shown in the local webserver log as soon as I try to visit the homepage.
`[Web Server ] Mar 17 17:53:58 |ERROR | SERVER GET (500) / ip="127.0.0.1"
[Application] Mar 17 21:53:58 |CRITICA| PHP Uncaught Error: Argument 1 passed to Sensio\Bundle\FrameworkExtraBundle\Request\ParamConverter\DoctrineParamConverter::__construct() must be an instance of Doctrine\Common\Persistence\ManagerRegistry or null, instance of Doctrine\Bundle\DoctrineBundle\Registry given, called in C:\<project path>\var\cache\dev\ContainerTxdhTq6\App_KernelDevDebugContainer.php on line 6066
[Application] Mar 17 21:53:58 |CRITICA| REQUES Uncaught PHP Exception TypeError: "Argument 1 passed to Sensio\Bundle\FrameworkExtraBundle\Request\ParamConverter\DoctrineParamConverter::__construct() must be an instance of Doctrine\Common\Persistence\ManagerRegistry or null, instance of Doctrine\Bundle\DoctrineBundle\Registry given, called in C:\Users\ack\PhpstormProjects\Vue-Training-Take-1\var\cache\dev\ContainerTxdhTq6\App_KernelDevDebugContainer.php on line 6066" at C:\Users\ack\PhpstormProjects\Vue-Training-Take-1\vendor\sensio\framework-extra-bundle\src\Request\ParamConverter\DoctrineParamConverter.php line 46
[Application] Mar 17 21:53:58 |CRITICA| PHP Uncaught Error: Argument 1 passed to Sensio\Bundle\FrameworkExtraBundle\Request\ParamConverter\DoctrineParamConverter::__construct() must be an instance of Doctrine\Common\Persistence\ManagerRegistry or null, instance of Doctrine\Bundle\DoctrineBundle\Registry given, called in C:\Users\ack\PhpstormProjects\Vue-Training-Take-1\var\cache\dev\ContainerTxdhTq6\App_KernelDevDebugContainer.php on line 6066`
Hey @Aaron Kincer,
Weird issue, however how did you get Doctrine installed here? This tutorial shouldn't have this dependency installed.
As I see your issue caused by newer Doctrine version and probably php7.4 (BTW which php version do you use?) I can't say how composer allowed to install it, probably some issues with versioning, so to resolve it remove doctrine and if you need it, try to install older version :)
Cheers!
Hi,
on ONE of my pages the debug toolbar does not show. Instead
I am getting a "Uncaught ReferenceError: Sfjs is not defined". On every
other page it shows up. Any ideas to help me out.
By the way: if I do NOT load my js-file for this page, the toolbar is shown. The content of this file:
$(document).ready(function () {
$("#user_form_passwort_double").keyup (function () {
var password1 = $("#user_form_passwort").val();
var password2 = $("#user_form_passwort_double").val();
if (password1 == password2) {
$(".passwortmeldung").addClass("verbergen");
$("#submitbutton").prop("disabled", false);
} else {
$(".passwortmeldung").removeClass("verbergen");
$("#submitbutton").prop("disabled", true);
}
});
$("#user_form_passwort").keyup (function () {
$(".passwortmeldung").removeClass("verbergen");
$("#submitbutton").prop("disabled", true);
});
});
The code works as intended but prevents the toolbar to be shown.
Thx
Oliver
Hey Oliver W.!
Wow, that's wild! The short answer is: I have no idea why this would be happening. Even a JavaScript error in this file, I think, wouldn't kill the JavaScript coming from the web debug toolbar. Do you have a closing /ltl;/script>
tag when you include this JavaScript file? It's gotta be something weird like that. I would try reducing the contents of this file piece-by-piece until it finally DOES work.
Let me know what you find out - I'm curious!
Cheers!
Hi weaverryan
I've even forgotten the closing >. So you were completly right.
Thx again!!! PHPStorm is genious but it finds less errors than you do ;-).
Oliver
Woohoo! Ok, that was a lucky guess but i'll take it :D.
Cheers!
Hello, I ran into issues with the debug pack since yersterday and I can't sort out how to debug it out. It's so fookin annoying:
When I navigate to my webserver (with bin/console server:start), the bar have a text indicating me : An error occurred while loading the web debug toolbar.
and when I look to the console I have a couple of errors like :
GET http://127.0.0.1:8000/_wdt/822837 500 (Internal Server Error)
and
`Uncaught TypeError: Cannot read property 'accountAdministration' of null
at HTMLDocument.<anonymous> (index.js:formatted:4271)
(anonymous) @ index.js:formatted:4271`
Help !! Thanks in advance. Don't hesitate to ask if you need something from my code (also present on github)
Hey Random,
Looks like the error message you give us is JS error. Where do you have that "accountAdministration" property? It seems that somehow you're trying to call this property on a variable that's null. Please, make sure that the object exist, like add an if statement to make sure it's not null, and if it's not - only then call "accountAdministration" on it.
About the 500 error in your console - check your logs! I suppose you're loading your application in "dev" mode, if so - check the var/log/dev.log file, you can tail it with:
$ tail -f var/log/dev.log
They try to reproduce the error and see the logs, they would have more context about what exactly went wrong and why you see the 500 error. Then, when you know the reason behind of it - you would just need to fix it :)
Cheers!
The problem is there ! I have no accountAdministration variable in my JSs, I have inspected a littlebit the code in my nav's developer console and I noticed that the error comes from the code that the debuger inject into my page for the toolbar...
for the 500 error, I digged up and found this :
https://imgur.com/30XzwlA
and so I went ahead and searched for this exact file into my vendor folder, and it is present
I don't understand what is happening, I tried to remove my vendor folder and to run composer install to install everything back, does not resolve anything.
Hey Random,
Hm, it sounds like you should upgrade the WebProfilerBundle, try to execute: "$ composer update symfony/web-profiler-bundle". Btw, what version of Symfony do you use? And what version of "symfony/web-profiler-bundle" package, you can know it with "$ composer info symfony/web-profiler-bundle". Also, is it your personal project or you downloaded this project from this course page? If you downloaded it, in which folder you're in: start/ or finish/ ?
Cheers!
Just updated the packages with "composer update", everything solved. Why haven't I thinked about that earlier.. Thanks anyway for the help and the effort !
Hey Random,
Ah, probably it was more complex than just upgrading the WDT. Thank you for confirming that package upgrade helped you.
Cheers!
Hello, I tried to update the bundle, it does not resolve anything.
I use Symfony 4.3.6 with
`
[ir@ir-pc DiscordBotsManager]$ composer info symfony/web-profiler-bundle
name : symfony/web-profiler-bundle
descrip. : Symfony WebProfilerBundle
keywords :
versions : * v4.3.7
type : symfony-bundle
license : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
source : [git] https://github.com/symfony/web-profiler-bundle.git 6ce12ffe97d9e26091b0e7340a9d661fba64655e
dist : [zip] https://api.github.com/repos/symfony/web-profiler-bundle/zipball/6ce12ffe97d9e26091b0e7340a9d661fba64655e 6ce12ffe97d9e26091b0e7340a9d661fba64655e
path : /home/ir/Documents/Developpement/Web/DiscordBotsManager/vendor/symfony/web-profiler-bundle
names : symfony/web-profiler-bundle
autoload
psr-4
Symfony\Bundle\WebProfilerBundle\ => .
exclude-from-classmap
requires
php ^7.1.3
symfony/config ^4.2
symfony/http-kernel ^4.3
symfony/routing ~3.4|~4.0
symfony/twig-bundle ~4.2
symfony/var-dumper ~3.4|~4.0
twig/twig ^1.41|^2.10
requires (dev)
symfony/console ~3.4|~4.0
symfony/dependency-injection ~3.4|~4.0
symfony/stopwatch ~3.4|~4.0
conflicts
symfony/dependency-injection <3.4
symfony/form <4.3
symfony/messenger <4.2
symfony/var-dumper <3.4
`
Running composer require profiler --dev
not installing packages.
I have output
$ composer require profiler --dev<br />Using version ^1.0 for symfony/profiler-pack<br />./composer.json has been updated<br />Loading composer repositories with package information<br />Updating dependencies (including require-dev)<br />Restricting packages listed in "symfony/symfony" to "4.3.*"<br />Nothing to install or update<br />Generating autoload files<br />Executing script cache:clear [OK]<br />Executing script assets:install public [OK]
Hey Askar K.
Probably it's already installed, check your composer.json
for symfony/profiler-pack
row.
Cheers!
Yeah, I see it's installed. But why I don't see the debug toolbar in the browser then?..
My .env
has APP_ENV=dev
, so I'm running in the dev env.
My composer.json
:
`{
"type": "project",
"license": "proprietary",
"require": {
"php": "^7.1.3",
"ext-ctype": "*",
"ext-iconv": "*",
"sensio/framework-extra-bundle": "^5.4",
"symfony/console": "4.3.*",
"symfony/dotenv": "4.3.*",
"symfony/flex": "^1.3.1",
"symfony/framework-bundle": "4.3.*",
"symfony/twig-bundle": "4.3.*",
"symfony/web-server-bundle": "4.3.*",
"symfony/yaml": "4.3.*"
},
"require-dev": {
"symfony/profiler-pack": "^1.0"
},
"config": {
"preferred-install": {
"*": "dist"
},
"sort-packages": true
},
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"App\\Tests\\": "tests/"
}
},
"replace": {
"paragonie/random_compat": "2.*",
"symfony/polyfill-ctype": "*",
"symfony/polyfill-iconv": "*",
"symfony/polyfill-php71": "*",
"symfony/polyfill-php70": "*",
"symfony/polyfill-php56": "*"
},
"scripts": {
"auto-scripts": {
"cache:clear": "symfony-cmd",
"assets:install %PUBLIC_DIR%": "symfony-cmd"
},
"post-install-cmd": [
"@auto-scripts"
],
"post-update-cmd": [
"@auto-scripts"
]
},
"conflict": {
"symfony/symfony": "*"
},
"extra": {
"symfony": {
"allow-contrib": false,
"require": "4.3.*"
}
}
}`
Which webserver do you use? Do you have correct html markup? I just tested your composer.json
and it works
Profiller doesnt work :((
I reloaded pages, opened source pages... and saw nothing
PHP 7.2
Symfony 4.3
I start server with
./bin/console server:run
php -S 127.0.0.1:8000 -t public
profiler was installed like in tutorial
Hey Howto!
Are you sure you ran the website in dev mode? What values do you have for APP_ENV env var in .env and .env.local files? Also, please, make sure you have the correct HTML base markup in your template, i.e. it has html/head/body tags, otherwise Profiler won't be added.
Cheers!
Hello. Thanks for the tutorial. I cant open the debug toolbar. After clicking on an element on the toolbar I receive the following error: Twig_Error_Runtime. <br />An exception has been thrown during the rendering of a template ("Warning: SessionHandler::read(): open(C:\Development\xampp\tmp\sess_nn9gqras422muqg9imam0ipa9u, O_RDWR) failed: No such file or directory (2)").
Any advice how to fix this ? Cheers
I'm wondering, how did Symfony deduce the route name as `app_article_show`?
Hey John alcher
It's quite simple. Route name `app_article_show` is autogenerated from root namespace, current controller name and current action. This happens because we did not specify `name` parameter in the `@Route` annotation.
Cheers!
And this is *also* why we recommend actually giving your route a specific name, once you actually need to link to it (because we don't want this route name to change accidentally, once we're using it!).
Cheers!
Makes sense! Can you suggest a naming convention to follow? The autogenerated one looks good enough for me.
Hey @JoJohn alcher!
Yea, I kinda like the autogenerated naming convention too! I don't follow it exactly... but I more or less do - e.g. app_CONTROLLERCLASS_METHODNAME ... or something near this :). I like the app_ prefix because it makes it very easy to search your entire project for that route... if you ever need to.
Cheers!
Hi !! in Symfony 4.1.3, the debugger is already installed adn twig also.
No problem else that when I put dump in my controller, it shows nothing.
How can I resolve this ?
Thanks for your course, it's amazing !
Hey Wo
If you installed the "website-skeleton", then yes, all those packages and more will be installed by default
To your question. Where did you call it? inside a twig's template? then you have to look for the dumped content inside the debug profiler tab
Cheers!
I call it in ArticleController. In the twig template, it's working well :-)
I think it could be good :-)
I have a notification in my profiler, I don't know if there is a link : User Deprecated: The "Sensio\Bundle\FrameworkExtraBundle\Configuration\Route" annotation is deprecated since version 5.2. Use "Symfony\Component\Routing\Annotation\Route" instead.
Ah, yes, that's a deprecation about using "Routing annotations" I believe you just have to change the import from "Sensio\Bundle\FrameworkExtraBundle\Configuration\Route" to "Symfony\Component\Routing\Annotation\Route"
Been trying to figure out how to get the dump function to work in twig. No matter which twig template I call it in, it throws a 500 error.
Looking in my logs, it tells me:
[2018-05-31 23:50:02] php.CRITICAL: Fatal Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 81805312 bytes) {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\OutOfMemoryException(code: 0): Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 81805312 bytes) at /srv/cadence/vendor/twig/twig/lib/Twig/Extension/Debug.php:48)"} []
Anyone else run into this?
It works in the Controller. I also read somewhere that there should be a place to see the dump'd variables in the profiler, but I can't find such a place.
Hey Geoff,
Oh, you have a memory error. The possible solution - increase your memory limit in php.ini. If you have this problem locally (that is probably true) - it's easy to fix. On VPNs sometimes you have limited memory, which means you need to upgrade to another plan to get more memory. I wonder what memory limit you currently have. Search for memory_limit in your php.ini and try to increase it. Don't forget to restart php-fpm or built-in web server so changes take the effect.
Yes, dump component stores dump-ed data in profiler, but it works only for dumped values in PHP code, not in the templates. To see it - dump something in your controller and find target icon in the profiler.
Cheers!
I'm running locally on my desktop in a container. I was using the default setting for memory_limit (128M), and upped the memory_limit to 1024M, but still getting the same error when I call {{ dump() }}
However, I did more testing and if I call {{ dump('test') }} or dump any single, simple variable that was passed, it works. But if I dump a more complex object or with no parameters, it runs out of memory. Does this really require that much memory?
Seems odd because when I dump an object in the controller, it works fine.
Interesting. When you call "dump" without params, it tries to dump all the available variables that you can access in the template, in somewhere must be an infinite loop, or something like that causing a huge memory usage.
What Symfony & Twig version are you using?
4.1
Hey Geoff,
I see you tried to increase memory_limit up to 1024M, but are you sure it was applied? Because to take effect you have to restart your PHP-FPM or restart your running built-in PHP web server. To make sure about *actual* memory_limit value you can in the web debug Symfony toolbar hover over Symfony version in the right bottom corner and click on "View phpinfo()" link near your PHP version, then search for "memory_limit". I have "-1" there on my laptop which means no limit at all, you can try this value as well.
Btw, do call this dump() function in dev environment?
Cheers!
I did confirm that the memory_limit was updated by checking phpinfo, and it did update. I didn't try setting the limit to -1 yet, but I will just to see what happens.
Hey Geoff,
Really weird... btw, did you have any recursion in dumped classes, such as User entity, etc. that is dumped with empty dump() function? And could you try to upgrade your dependencies to the latest versions? Probably there was a memory leak bug which may be fixed lately, if not, probably you need to report an issue about it or do some debugging yourself to find the root of the problem.
Cheers!
Hi,
In case you got same error whit memory limit just install xdebug and setup it. Its pretty easy and you will be fine,..
Hey Silvestr,
Thanks for sharing it! Yes, Xdebug may help but with var_dump() function only, but Geoff was talking about Symfony's dump() function, i.e. VarDumper Component, see https://symfony.com/doc/cur... for the reference.
Cheers!
Hello, I have a problem with profiler. 'An error occurred while loading the web debug toolbar. Open the web profiler.' After clicking 'Open the web profiler' shows 404 error page. I have 5 console errors on Chrome 'Failed to load resource: the server responded with a status of 404 (Not Found) ' for '/_wdt/05cb53' directory. Installation process was ended succesfull.
It was problem with Apache server. It doesn't work together.
"Houston: no signs of life"
Start the conversation!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"sensio/framework-extra-bundle": "^5.1", // v5.1.3
"symfony/asset": "^4.0", // v4.0.3
"symfony/console": "^4.0", // v4.0.14
"symfony/flex": "^1.0", // v1.17.6
"symfony/framework-bundle": "^4.0", // v4.0.14
"symfony/lts": "^4@dev", // dev-master
"symfony/twig-bundle": "^4.0", // v4.0.3
"symfony/web-server-bundle": "^4.0", // v4.0.3
"symfony/yaml": "^4.0" // v4.0.14
},
"require-dev": {
"easycorp/easy-log-handler": "^1.0.2", // v1.0.4
"sensiolabs/security-checker": "^5.0", // v5.0.3
"symfony/debug-bundle": "^3.3|^4.0", // v4.0.3
"symfony/dotenv": "^4.0", // v4.0.14
"symfony/monolog-bundle": "^3.0", // v3.1.2
"symfony/phpunit-bridge": "^3.3|^4.0", // v4.0.3
"symfony/profiler-pack": "^1.0", // v1.0.3
"symfony/var-dumper": "^3.3|^4.0" // v4.0.3
}
}
If you run into any memory issues or "ugly" dumped variables, just go to the next chapter, it will "fix" the issue.