Qu'est ce qui se passe dans mon app ?

C'est une question que vous allez vous poser souvent lorsque vous dévlopper un site, un comportement bizzare, un cas particulier, etc.

Et parfois, sans connaitre le code ou l'avoir écrit il y a longtemps, il est difficile de vraiment savoir ce qu'il se passe !

Heureusement, Symfony a un paquet pour nous aider 😎

Installer le profiler

Bon, nous allons devoir installer un autre paquet, mais ça tombe bien ça fait un peu de pratique !

Par contre, nous allons faire une installation un peu spéciale, car ce paquet va nous servir seulement en développement. (On ne veut pas que les utiliseurs puisse voir ce qui se passe à l'intérieur du site, ce serait dangereux.)

composer require profiler --dev

Hop, on a installé le paquet pour profiler notre installation, le petit flag --dev nous permet de dire à composer attention ce paquet sert seulement au développement. Composer va ensuite le mettre dans une section spéciale du fichier composer.json, sous cette forme là :

// Exemple ci dessous, vous auez quelque chose de différent mais sous la même forme

"require-dev": {
    "sensiolabs/security-checker": "^6.0",
    "symfony/debug-pack": "^1.0"
},

Maintenant que c'est fait, rechargez votre page et hop une nouvelle toolbar avec pas mal d'informations interessantes !

À quoi ça sert ?

Cette toolbar de début est intéressante, elle nous donne quelques informations sur la page que nous avons chargé :

1. Le code de retour
2. Le controller utilisé avec la méthode sous la forme @app_[controller]_[methode]
3. Le temps d'éxécution
4. La mémoire utilisée
5. Le cache
6. temps de rendu de twig
7. La version de symfony

Vous pouvez passer votre curseur sur les sections pour avoir un peu plus d'informations

Cette petite barre nous donne déjà pas mal d'information, mais si vous avez besoin d'encore plus d'informations, le profiler au format complet vous attends 😏

Profiler god

Sur la toolbar, vous pouvez cliquer sur n'importe quel boutton et ça vous mènera au profiler.

Ici vous avez plusieurs section :

Request / Response

Cette section contient tout ce qu'il y a à savoir contenant la requête et la réponse du serveur qui a affiché cette page.

Très intéressant pour voir les paramètre GET, POST, les fichiers uploadés, ou encore le controller, la route, et les paramètres de route.

Pleins d'information intéressantes si vous avez des problèmes avec une page, afin de voir si c'est ce que vous attendez !

Performance

Cette section contient les résultat de performance de la page.

Si jamais vous avec une page / route qui met du temps à s'exécuter, vous avez tous les outils ici pour découvrir où se situe la lenteur.

La chose la plus intéressante de cette page est l'Execution timeline, elle vous permet de voir le temps de chaque composant qui est appelé par la route, la catégorie du composant, ainsi que la mémoire utilisée.

Très pratique pour savoir exactement par quels services / template votre route passe et où se situe la lenteur !

Exception

Cette section contient toutes les informations concernant les erreurs survenues durant l'exécution de votre requête.

Cette section vous sera utile seule lors des erreurs que vous rencontrez en developpement.

Logs

Cette section va contenir tous les logs générés par symfony (et potientiellement par vous si vous utilisez le système de log).

Cette section est intéressante en cas d'erreur, car elle permet de retracer exactement les errerus php que vous avez.

De plus, on peut voir dans les autres sections des informations imporantes, nottament les dépréciations, indiquant que vous utilisez des composants ou méthodes qui seront enlevés dans les prochaines versions de symfony.

N'hésitez pas à aller fouiller dans les différentes onglets pour voir quelles informations y sont affichées, vous en aurez peut être besoin un jour, qui sait 😏

Events

Cette section contient tous les évènement qui ont été lancés durant la requête.

Vous allez me dire que sont les évènement ?

Les évènement sont utilisés dans le framework pour permettre d'avoir le principe d'action / réactions.

Prenons le cas d'une situation simple :

Des utilisateurs s'incrivent sur le site, nous avons besoin d'effectuer plusieurs actions dans différentes parties de l'application afin de les initialiser correctement

Dans une méthode classique, on aurait un appel à chaque méthode permettant de faire une action spéciale. Ça marche très bien, mais lorsque l'on doit faire plus d'une dizaine d'appel ça commence à devenir lourd.

Avec une méthode action / réactions (programmation évènementielle), on peut simplement créer un évènement de type User Create avec les informations intéressante par rapport à cet utilisateur.

Ensuite, nous allons définir des écouteurs de cet évènement, ceux ci seront lancés avec les informations lorsque l'évènement User Create est créé. De cette manière, nous n'avons pas besoin de modifier notre code à d'autres endroit, juste à définir un écouteur pour réagir à un évènement.

Symfony en utilise déjà en interne, c'est pour cela que vous les voyez directement dans l'interface.

À savoir que vous pouvez aussi écouter les évènement Symfony, c'est parfois très utile.

Pour le moment nous en auront pas besoin, c'est du Symfony plus avancé, mais c'est toujours intéressant de savoir comment ça marche !

Pour ceux qui serait intéressés, c'est par ici que ça se passe

Routing

Dans cette section, vous retrouverez les information par rapport au routing :

• Les paramètres passés à la route
• Quelle route a matché l'url demandé
• Quelles routes ont été vérifiées avant de trouver la bonne

Pas beaucoup plus d'informations à ce niveau là, cette section sera surtout utile si vous ne matchez par la route que vous souhaitez.

Cache

Pas très intéressant pour le moment, il vous sera plus utile pour résoudre des problème de performances.

La gestion et l'utilisation du cache est en dehors du périmètre de ce cours.

Twig

Ici, c'est tout à propos de TWIG.

Vous allez pouvoir voir combien de templates on été appelés, quels blocs sont utilisés, le temps de rendu, et même un graphique de rendu, pour voir quels fichier hérite de qui et écrit quels blocs.

Debug

Cette section vous sera utile pour voir ce qui se trouve dans la fonction dump() dans les templates twig ou dans votre code PHP.

N'hésitez pas à y faire un tour lorsque vous utiliserez dump()

Configuration

Partie intéressante, puisqu'elle affiche la configuration de votre serveur !

Votre site n'affiche pas la bonne heure ? Venez voir ici la timezone configurée sur votre serveur php !

Quelle version de php vous avez d'installer ? Le profiler vous le dit aussi !

Les bundle installés dans votre projet symfony ? Pas de soucis non plus !

Un bucket de poulet KFC 🍗 ? Non. Vous allez trop loin, vous avez encore tout ruiné.

En bref, cette page est assez pratique pour en savoir plus sur votre serveur !

Des dumps comme si il en pleuvait

Vous connaissez certainement var_dump, et bien dans notre cher paquet profiler var-dumper a été installé nous donnant accès à dump!

Dump c'est un petit peu var_dump sous stéroide, il fait la même chose que le précédent mais avec de la colorisation sythaxique et support pour rétracter certaines parties de des tableaux ou structures ! Whoou !

Voyons comment l'utiliser :

Côté PHP

N'importe où dans votre script utilisez dump(); avec le ou les variables que vous voulez dumper à l'intérieur.

Si l'on reprends l'exemple de notre controller :

<?php

namespace App\Controller; 

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ExempleController 
{
    /**
    * @Route("/")
    **/
    public function index() {
        dump([
            'hello' => 'world'
        ]);

        return new Response('Hello world !'); 
    }

    /**
    * @Route("/saymyname/{name}")
    **/
    public function random($name) {
        return new Response('Hello ' . $name . ' !'); 
    }
}

Rechargez la page et... rien ne s'affiche !

C'est normal, allez dans le profiler et la partie debug, et surprise, il est là ! Vous retrouvez votre tableau, ainsi que l'ensemble de ses arguments. Tout ce que vous venez dumper se retrouvera là par défaut.

Si vous le voulez directement sur la page, tels des bourrins, ajoutez simplement un petit die; derrière pour arrêter le script.

<?php

namespace App\Controller; 

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ExempleController 
{
    /**
    * @Route("/")
    **/
    public function index() {
        dump([
            'hello' => 'world'
        ]);
        die;

        return new Response('Hello world !'); 
    }

    /**
    * @Route("/saymyname/{name}")
    **/
    public function random($name) {
        return new Response('Hello ' . $name . ' !'); 
    }
}

Côté Twig

Vous pouvez faire la même chose côté twig, enfin... pas tout à fait.

Avec twig, vous pouvez appeller dump n'importe où, à la manière d'une variable. (i.e. : {{ debug(title) }}).

Ici nous allons afficher title dans le debug, ce qui n'est pas très utile en soi.

Mais la vraie force de debug sur twig se trouve dans le fait que l'on peut l'appeler sans arguments et afficher toutes les variables disponibles dans le template ! Nice !

Un petit exemple pour la route :

{% extends 'base.html.twig' %}

{% block title %}Homepage !{% endblock %}

{% block body %}
    {{ dump() }}
    <h1>{{ title }}</h1>
{% endblock %}

Conclustion

Vous avez désormais toutes les clefs pour savoir ce qu'il ne vas pas dans votre app, que ce soit performance, logs ou encore erreurs ce profiler vous donnes toutes les armes pour comprendre et travailler avec votre Symfony !