Chapters

20 Chapters | 1:53:05 |

01

Setting up our Symfony App

4:34
02

Getting to Know our Tiny Project

4:14
03

Routes, Controllers & Responses

6:17
04

Magical Flex Recipes

5:40
05

Twig & Templates

8:12
06

Twig Template Inheritance

3:50
07

Debugging with the Amazing Profiler

4:28
08

Creating JSON API Endpoints

7:17
09

Services: The Backbone of Everything

7:47
10

Creating your own Service

7:04
11

Fancier Routes: Requirements, Wildcards, and More

6:56
12

Generating URLs

5:31
13

CSS & JavaScript with Asset Mapper

6:17
14

Tailwind CSS

6:15
15

Twig Partials & for Loops

2:44
16

PHP Enums

3:30
17

Smart Model Methods & Making the Design Dynamic

4:44
18

Stimulus: Writing Pro JavaScript

8:00
19

Turbo: Your Single Page App

4:32
20

Maker Bundle: Let's Generate Some Code!

5:13

> Symfony 7 > Cosmic Coding with Symfony 7

07.

Debugging with the Amazing Profiler

Autoplay

Symfony boasts some of the most epic debugging tools of all the Internet. But because Symfony apps start so small, we don't even have them installed yet. Time to fix that. Head over to your terminal and, like before, commit all of your changes so we can check out what the recipes will do. I already did that.

Installing the Debugging Tools

Then run:

composer require debug

Yup! That's another Flex alias. And... it installs a pack. This installs four different packages that add a variety of debugging goodness to our project. Spin over and open composer.json.

            Copy Code

                            Show All Lines

                        80 lines
            |
            composer.json
        
            {
        
                Show Lines

                                                    // ... lines 2 - 5
                            
                "require": {
        
                Show Lines

                                                    // ... lines 7 - 14
                            
                    "symfony/monolog-bundle": "^3.0",
        
                Show Lines

                                                    // ... lines 16 - 20
                            
                },
        
                Show Lines

                                                    // ... lines 22 - 78
                            
            }

Ok, the pack added one new line under the require key for monolog-bundle. Monolog is a logging library.

Then all the way at the bottom, it added three packages to a require-dev section.

            Copy Code

                            Show All Lines

                        80 lines
            |
            composer.json
        
            {
        
                Show Lines

                                                    // ... lines 2 - 73
                            
                "require-dev": {
        
                    "symfony/debug-bundle": "7.0.*",
        
                    "symfony/stopwatch": "7.0.*",
        
                    "symfony/web-profiler-bundle": "7.0.*"
        
                }
        
            }

These are known as dev dependencies... which means they won't be downloaded when you deploy to production. But otherwise, they work the same as packages under the require key. All three of these help power something called the profiler. We'll see that in just a minute.

Before we do, go back to your terminal and run

git status

so we can see what the recipes did. Ok: it updated the normal files, enabled a few new bundles and gave us three new configuration files for those bundles.

What's the end result of all this new stuff? Well, first, we now have a logging library. So, like magic, logs will start popping into a var/log/ directory.

But the mind-blowing moment happens when we refresh the page. Woh! A beautiful new black bar at the bottom called the web debug toolbar.

This is bursting with info. Over here, we can see the route and controller for this page. That it makes it easy to go to any page on your site - maybe one you didn't even build - and quickly find the code behind it. We can also see how long this page took the load, how much memory it used, and even the twig template that was rendered and how long that took.

But the real magic of the web debug toolbar happens when you click any of these links: you hop into the profiler. This has ten times more info: details about the request and response, logs that occurred while loading that page, routing details, and even stats about which Twig templates were rendered. Apparently six templates were rendering: our main one, the base layout and a few others that power the web debug toolbar, which, by the way, won't be rendered or shown when we deploy to production. But we'll talk about that in the next tutorial.

Then there's probably my favorite section: Performance. This slices our entire page load time into different pieces. I love this. As you learn more about Symfony, you'll get more familiar with what these different pieces are. This section is useful for knowing which part of your code might be slowing down the page... but it's also a fantastic way to dive deeper into Symfony and understand all its moving pieces.

We're going to use the profiler throughout this series, but let's turn to another debugging tool: one that's been installed in our app this whole time!

Hello bin/console!

Head over to the command line and run:

php bin/console

Or, on most machines, you can just say ./bin/console. This is Symfony's console, and it's packed with commands that can do all sorts of stuff! We'll learn about them along the way. You can also add your own commands, which we'll do at the end of the tutorial.

Notice that a bunch of these start with debug - like debug:router. Try that:

php bin/console debug:router

Cool! This shows us every route in our app: the homepage route at the bottom and a bunch of routes added by Symfony in the dev environment that power the web debug toolbar and profiler.

Another command is debug:twig:

php bin/console debug:twig

This tells us every Twig function, filter or other thing that exists in our app. This is like the Twig docs... except it also includes extra functions and filters that are added to Twig by bundles that we have installed. Pretty cool.

These debug commands are super useful, and we'll keep trying more of them along the way.

Next, let's create our first API endpoint and learn about Symfony's powerful serializer component.

26 Comments

Sort By

pasquale_pellicani 9 months ago

I add a suggestion that can avoid wasting an hour of attempts to make the call to the _wdt route work!
install this, after composer require debug command:
composer require symfony/apache-pack

2 | Reply |

Victor SFCASTS pasquale_pellicani 9 months ago edited

Hey @pasquale_pellicani ,

Thanks for this tip! Indeed, if you're using Apache instead of built-in Symfony web server that we're using in the screencast - you would need that symfony/apache-pack package that will bring an .htaccess file into your app.

Cheers!

1 | Reply |

Mahmut-A 4 months ago

Hello,

I have two questions for this topic:

I am removing debug by command composer remove debug. But it is still exists. Is there any trick to apply it?
In my symfony, by default there is debug. but var/log directory has a log.dev file. not direct log file.Is it important or does it depend to version of symfony or something else? I am using ubuntu server and I installed symfony via composer command.

| Reply |

sadikoff SFCASTS Mahmut-A 4 months ago edited

Hi @Mahmut-A

What do you mean still exist?
Logging can be configured with monolog bundle

Can you provide more details what exactly you want to achieve?

Cheers

| Reply |

Mahmut-A sadikoff 4 months ago

Hi Sadikoff,

I used composer remove debug command. But all debug package is still in composer.json file. I expected it will be removed from there. Also, debug bar is still seen on top of page. I want to disable it.
We ignore second question. thank you

| Reply |

sadikoff SFCASTS Mahmut-A 4 months ago

Oh, I got it. That is a tricky moment debug is an installation alias, so once you installed debug pack, you should forget about it, and if you want to uninstall it, you should uninstall each package separately.

Cheers!

1 | Reply |

tomoguchi 7 months ago

Could you also please explain how to remove bundles or packs?

| Reply |

Victor SFCASTS tomoguchi 7 months ago edited

Hey @tomoguchi ,

How to remove? It's as easy as execute composer remove command. If you use Symfony Flex - it will also remove config files. If no, you will need to do it manually. But basically, you just need to drop the package from your composer.json file, for this you leverage the command I mentioned above: composer remove ... and then you need to disable the bundle in the config/bundles.php - just literally drop the related namespace from there. Then clean up any related config files in the config/ dir. I think that's all :)

Cheers!

1 | Reply |

tomoguchi Victor 7 months ago edited

hello @Victor does that also removes the generated files, setting and autowirings composer require some-bundle created?

| Reply |

Victor SFCASTS tomoguchi 7 months ago edited

Hey @tomoguchi ,

Yes, it has to remove those files too. Well, not the files you created manually but the files that were created by Symfony Flex recipe. But it will happen only if you have Symfony Flex enabled and allowed in your project.

Cheers!

1 | Reply |

John-S 8 months ago

adding this inside controller method:

 $x = '1';
 $y = '2';
 dump($x);
 dump($y);

each use of dump() is adding 2 seconds to execution time. So this takes 4seconds to load the script.
I intend to use it quite a lot to track things down is there a way to make it quicker ?

| Reply |

kbond SFCASTS John-S 8 months ago edited

Hey @John-S, this is indeed odd. To confirm, removing one dump() reduces the request time to ~2 seconds and adding a dump() increases to ~6 seconds? Do you see the dump output as expected in the profiler?

| Reply |

John-S kbond 8 months ago

1 dump() 2 seconds.
2 dump() 4 seconds.
3 uses of dump() profiler line:
dump 6078.2 ms / 2 MiB
probably something with the settings but just not sure what.

| Reply |

MolloKhan SFCASTS John-S 8 months ago

Does it happen on every request? In particular when you don't change the code
Do you experiment the same behavior with a different Symfony app?
I believe you may have added by mistake a sleep() somewhere in your vendors. Try re-installing them

Cheers!

| Reply |

John-S 8 months ago edited

Is it ok that dump() increases every request time to 2seconds?

I haven't installed the monolog bundle but installed symfony/stopwatch --dev. I have short array on my controller and using dump($simpleArray) on it. It now it takes 2seconds to load every request (dump 2037.7 ms / 2 MiB). Is this ok ?

| Reply |

Victor SFCASTS John-S 8 months ago

Hey John,

It depends on the data you're trying to dump. If you're dumping heavy objects, the serialization may really take long time. Also, sometimes it depends if you're using a virtualization tool like Docker or no. With virtualization tools numbers can be really much more increased.

But in short, that's OK, because you should use dump()/dd() features only in dev mode and never should use it on production.

Cheers!

| Reply |

John-S 9 months ago

hello,

I'm having a hard time following which packages require "--dev" addon.
For example I see both the symfony/debug-bundle on docs and on packagist website recommended installation as "composer require symfony/debug-bundle" but here(composer.json) is under require-dev. My installation settled it under "require".

how to do it right ?

p.s. I know this is introductory tutorial but i really try to install all features individually and not packs so I can keep the track on and know what's what.

| Reply |

MolloKhan SFCASTS John-S 9 months ago edited

Hey @John-S

To make composer install things under the require-dev key, you need to pass the --dev flag. You can also manually move the dependencies from one key to another in case you forgot to add the flag.

Cheers!

| Reply |

Mahmut-A 10 months ago

Hello,

Could you please show how to remove debug from the bar? I did composer remove debug. but still I see the debug bar.
thank you

| Reply |

MolloKhan SFCASTS Mahmut-A 10 months ago edited

Hey @Mahmut-A

Can I ask why? You're the first one I know who doesn't like it - lol
Seriously, that debug toolbar is only loaded on the "dev" environment. You can remove it by deleting the bundle's entry in config/bundles.php

Cheers!

| Reply |

Mahmut-A MolloKhan 10 months ago

Hi,

the first reason is actually I wanted to test to remove a package from composer. so when I used composer remove command, composer.json did not delete this package. so I did not want to wrong thing to affect all symfony environment.
the second reason, I am building my project in web service apache. so I do not want show the debug to clients.

then, I understand that if any package is need to remove, I need to remove from config/bundle.php right?
thank you for your help

| Reply |

MolloKhan SFCASTS Mahmut-A 10 months ago

Ok, the bundle you want to remove is this one symfony/debug-bundle - I recommend not removing it because it only works on the "dev" environment, so your clients won't see it, also, it should be in the require-dev composer key and those dependencies should not be installed in your production server. You can do that by adding the flag composer install --no-dev

then, I understand that if any package is need to remove, I need to remove from config/bundle.php right?

That's true only for bundles

Cheers!

1 | Reply |

Mahmut-A MolloKhan 10 months ago

Hi MolloKhan,

Thank you.
I applied this command: composer install --no-dev but page gives below error:

Attempted to load class "DebugBundle" from namespace "Symfony\Bundle\DebugBundle".<br />Did you forget a "use" statement for another namespace?

because of that, ı added debug again by command composer require debug

| Reply |

MolloKhan SFCASTS Mahmut-A 10 months ago

When installing composer deps using the --no-dev flag your must run your application on the "prod" environment, otherwise it will try to load dev dependencies but those were not installed, hence, your error

| Reply |

Mahmut-A MolloKhan 10 months ago

Actually, how can we describe prod? Because my project under /var/www/html and it is working as a apache web.
I dont do in localhost.
Because of that, my expectation is when I do this —no-dev command, it should be disabled.

Thank you so much again for your kindly help

| Reply |

MolloKhan SFCASTS Mahmut-A 10 months ago

I mean the APP_ENV environment variable. That should be set to "prod" - I recommend you to watch this video, it will give you a better idea of Symfony environments https://symfonycasts.com/screencast/symfony-fundamentals/environments

Cheers!

1 | Reply |

Symfony 7

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.2",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "php-cs-fixer/shim": "^3.46", // v3.46.0
        "phpdocumentor/reflection-docblock": "^5.3", // 5.3.0
        "phpstan/phpdoc-parser": "^1.25", // 1.25.0
        "symfony/asset": "7.0.*", // v7.0.3
        "symfony/asset-mapper": "7.0.*", // v7.0.2
        "symfony/console": "7.0.*", // v7.0.2
        "symfony/dotenv": "7.0.*", // v7.0.2
        "symfony/flex": "^2", // v2.4.3
        "symfony/framework-bundle": "7.0.*", // v7.0.2
        "symfony/monolog-bundle": "^3.0", // v3.10.0
        "symfony/property-access": "7.0.*", // v7.0.0
        "symfony/property-info": "7.0.*", // v7.0.0
        "symfony/runtime": "7.0.*", // v7.0.0
        "symfony/serializer": "7.0.*", // v7.0.2
        "symfony/stimulus-bundle": "^2.13", // v2.13.3
        "symfony/twig-bundle": "7.0.*", // v7.0.0
        "symfony/ux-turbo": "^2.13", // v2.13.2
        "symfony/yaml": "7.0.*", // v7.0.0
        "symfonycasts/tailwind-bundle": "^0.7.1", // v0.7.1
        "twig/extra-bundle": "^2.12|^3.0", // v3.8.0
        "twig/twig": "^2.12|^3.0" // v3.8.0
    },
    "require-dev": {
        "symfony/debug-bundle": "7.0.*", // v7.0.0
        "symfony/maker-bundle": "^1.52", // v1.53.0
        "symfony/stopwatch": "7.0.*", // v7.0.0
        "symfony/web-profiler-bundle": "7.0.*" // v7.0.2
    }
}

Previous Challenge

Next Challenge

Debugging with the Amazing Profiler

Share this awesome video!

Installing the Debugging Tools

Hello bin/console!

26 Comments

Delete comment?

What PHP libraries does this tutorial use?

	{
Show Lines	// ... lines 2 - 5
	"require": {
Show Lines	// ... lines 7 - 14
	"symfony/monolog-bundle": "^3.0",
Show Lines	// ... lines 16 - 20
	},
Show Lines	// ... lines 22 - 78
	}

	{
Show Lines	// ... lines 2 - 73
	"require-dev": {
	"symfony/debug-bundle": "7.0.*",
	"symfony/stopwatch": "7.0.*",
	"symfony/web-profiler-bundle": "7.0.*"
	}
	}

Debugging with the Amazing Profiler

Installing the Debugging Tools

Hello Web Debug Toolbar & Profiler

Hello bin/console!

26 Comments

What PHP libraries does this tutorial use?