Deboguer sous CakePHP

Voici un article qui a été accouché dans la douleur ! un mois entre le début de la rédaction et la publication, record battu ! 🙂

Quels sont les outils à notre disposition pour deboguer sous CakePHP ?

Nous allons traiter de 2 types d’outils disponibles facilement (j’insiste sur le facilement, car nous ne partirons pas sur xDebug) qui se trouvent :

  • Côté serveur
  • Côté client

Les outils de deboguage côté serveur

Il existe 2 façons rapides de consulter / stocker les variables utilisées dans notre application CakePHP : l’utilisation de fonction debug et l’utilisation de la classe Logging (en CakePHP v3).

Debug

debug, peut s’utiliser aussi bien dans le model, le controller ou la vue. son utilisation est très simple :


debug($maVariable);

Va afficher par exemple :

array(
	'Lienscomposition' => array(
		'id' => '2',
		'parent_id' => '1',
		'lft' => '2',
		'rght' => '17',
		'name' => 'TISSUS ANTI-LARSEN',
		'materiel_id' => '181',
		'qte' => '1',
		'created' => '2015-04-16 20:44:49',
		'modified' => '2015-04-16 20:44:49'
	)
)

debug est très pratique et utilisable dans toutes les situations. Même le code Console en mode Shell.

Petite information, si vous avez désactivé le mode debug (en le place à FALSE sous v3 ou 0 sous v2), le contenu du debug ne s’affichera pas (Ca c’est pour vous éviter de chercher « pourquoi rien ne s’affiche ? »).

L’avantage de debug par rapport à var_dump ou print_r, c’est la mise en forme des tableaux par exemple, puisque le format de sortie est facilement lisible.

Logging

Logging est une classe utilisée pour écrire dans les fichiers journaux. Il est possible d’écrire dans un fichier journal dédié à CakePHP ou carrément écrire via le syslog de votre OS (Linux / Mac).

Pour utiliser la classe Logging, je vous encourage à lire la doc officielle à ce sujet, tout y est précisément décrit.

Les outils de deboggage côté client

Personnnellement, mes 2 outils préférés côté client (en plus du xDebug), c’est l’utilisation du navigateur Google Chrome et DebugKit (on parlera du plugin DebugKit plus tard, rien qu’avec Chrome on pourrait presque se passer du plugin DebugKit).

Le navigateur Google Chrome est doté de puissants outils dédiés au développement et au déboguage, l’interface de développement s’affiche au travers du menu Principal -> « Plus d’outils » -> « Outils de développement ».

Voici ce que cela donne :

google-chrome-dev

On y retrouve plusieurs onglets, dans l’ordre :

« Elements » : la liste de l’ensemble de la page consultée, les éléments sont en temps-réel, dans le sens où si vous modifiez dynamiquement votre page (avec javascript par exemple), les éléments seront le reflet exact de ce que vous voyez à l’écran (à la différence de Sources, voir plus bas). A droite de l’onglet « Elements » vous trouverez les styles appliqués à chacun des éléments. En cliquant sur un élément, son style apparait, avec l’ordre d’apparition, ce qui permet d’identifier rapidement les styles qui posent problèmes. Le panneau « Elements » est modifiable, c’est à dire que vous pouvez directement modifier la page dans « Elements » et la mise à jour de la page se fera instantanément ! hyper pratique pour tester des configurations de CSS ou de style. On peut même glisser/déposer des éléments directement dans ce panneau, et voir la page se modifier en temps réel.

Exemple (cliquez pour avoir l’animation) :

debug-css

« Network » : l’onglet le plus important à mes yeux lorsque vous déboguez de l’AJAX ou des formulaires POST / GET. L’onglet network représente le détail des requêtes envoyées au serveur, et surtout le retour « brut » du serveur. On retrouve également des éléments de performance car nous voyons le délai de retour, la taille des paquets, etc. Si vous n’utilisez pas cet onglet, je vous conseille fortement de vous familiariser avec, car il permet facilement et rapidement de prendre connaissance des réponses du serveur (que ce soit AJAX ou autre).

Exemple : je modifie mon article WORDPRESS, et en cliquant sur le bouton « enregistrer brouillon » je peux voir le contenu de la requête POST « post.php »

debug-post

 

dans « preview » j’aurais la prévisualisation de la réponse (au format XML, HTML ou JSON, super pratique).

« Sources » : Cet onglet affiche le contenu brut qui est rapatrié lors d’une requête, cela inclut les pages HTML, les scripts JS, les feuilles CSS, etc. Tout y est classé dans l’arborescence complète des chemins. C’est pratique quelquefois si on perdu dans les fichiers JS que l’on a, et que l’on veut voir les fichiers JS réellement chargés (mais si vous faites cela, c’est que vous êtes mal organisé), ou si vous voulez savoir quels sont les fichiers qui proviennent de domaines différents de votre site.

« Timeline » : Je ne l’ai utilisé qu’une seule fois, pour faire du profiling de script Javascript. Cela permet d’identifier rapidement les goulots d’étranglements et permet de répondre à la question : « mais pourquoi ma page est aussi longue à charger ? » Avec Timeline, vous lancez l’enregistrement, vous rafraichissez votre page, et vous arrêter l’enregistrement. Vous pouvez ainsi aller dans le détail pour voir combien de temps est nécessaire pour récupérer les données, traiter le JS, traiter le CSS, afficher les éléments, etc. Très pratique pour optimiser votre code, et identifier par exemple que vous avez trop de style ou que le traitement JS est trop long :

debug-timeline

« Profiles » : va plus loin que la timeline et est très orientée performances Javascript.  Vous pourrez rapidement identifier les fonctions Javascript qui sont les plus longues à traiter. Très utile quand on manipule des plugins JQuery, cela permet également d’avoir des données factuelles de ressenti utilisateur (on passe du « c’est lent » à « ça à pris 1sec au lieu de 150ms »)

« Resources » : affiche l’intégralité des ressources récupérées ou calculées de votre application WEB, en les classant par type de ressources (Fonts, image, HTML, CSS), ce qui permet de voir en un coup d’oeil tous les « assets » (actifs) d’une page WEB. On peut également voir le contenu des cookies du site (mais sans les modifier, il y’a des plugins pour cela), ou le stockage local (fonctionnalité HTML5).

« Audits » : l’onglet pour les conseils d’optimisations de votre page WEB. A tester au moins une fois, mais de toute façon, à part quelques travers classiques (en rouge), les conseils en orange sont difficilement applicables (genre nettoyer vos feuilles de styles, avec Bootstrap, bon courage…)

« Console » : Bien pratique ce petit onglet, car il permet d’être utiliser en déboguage Javascript. Par exemple dans votre code javascript si vous coder cette ligne dans une fonction :


console.log(maVariable);

C’est dans l’onglet « Console » que le contenu de maVariable sera affichée. Et si vous loguer des objets, la présentation sera en notation objet.

Voilà quelques informations concernant les outils de déboguage à votre disposition. Si vous avez d’autres astuces, n’hésitez pas à les partager sur le forum de la communauté francophone !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *