Une petite remarque avant la prochaine release 3.3.
Dans le code on a ajouter il y a déjà longtemps le filtre |debug qui permet de faire du… debug dans les squelettes.
Dans le plugin dev, on a un autre filtre très utile qui s’appelle |bel_env et qui permet d’afficher un tableau dans un format HTML lisible quelque soit son imbrication. C’est donc un outil de debug au même titre que le filtre |debug.
Je trouve que c’est incohérent d’avoir l’un dans spip et l’autre dans dev qui ne fait plus partie d’ailleurs des plugins-dist.
Je proposerais bien d’intégrer le filtre |bel_env dans spip en le renommant par exemple en |debug_table.
Ça serait plus cohérent oui, mais pourquoi garder les deux ?
Sinon j'ai un truc dans le genre, avec un affichage un peu plus détaillé, et d'autres balises, si tu veux tester : https://github.com/nd-/dd
Faudrait que je le mette sur la zone...
Ça serait plus cohérent oui, mais pourquoi garder les deux ?
Car c'est vraiment un usage différent, debug, comme l'indique sa doc, affiche une valeur dans les squelettes *uniquement pour les webmestres* (comme ton projet perso dd), et ajoute une ligne dans debug.log |debug - SPIP
Alors que bel_env, qui n'est pas documenté affiche de manière sympa les tableaux (l'env par exemple), point sur lequel debug n'est pas très utile car il affiche dans ce cas une valeur serializée du style :
Sinon j'ai un truc dans le genre, avec un affichage un peu plus détaillé, et d'autres balises, si tu veux tester : https://github.com/nd-/dd
Faudrait que je le mette sur la zone...
Oui ça serait bien, mais ça nous fera maintenant trois filtres pour un usage presque similaire :\
Je pense comme toi qu'il est temps de mutualiser, notamment sur le point qui fait que ces filtres n'affichent l'info que pour les webmestres, les visiteurs des sites s'en cognent un peu de l'env et de nos debugs
Par contre, il faudra choisir un nom pour le filtre qui prendra le relai, ou alors garder debug qui a l'avantage d'être connu car documenté, et mettre à jour sa doc.
Sinon j'ai un truc dans le genre, avec un affichage un peu plus détaillé, et d'autres balises, si tu veux tester : https://github.com/nd-/dd
Faudrait que je le mette sur la zone...
Oui ça serait bien, mais ça nous fera maintenant trois filtres pour un usage presque similaire :\
Ma version affiche des infos dans une barre (comme le plugin dev, je m'en suis inspiré), notamment le nombre de requetes Mysql executées.
Ça me permet de vérifier rapidement les mises en cache.
Et l'affichage des infos de débug est limité par une autorisation, qui vérifie soit le statut (webmestre) soit l'IP (pour pouvoir débugger à distance, même non loggé).
La prochaine modif sera de pouvoir afficher la liste de toutes les requêtes passées en un click, comme les barres de débug de Laravel ou Symfony, avec un affichage sympa.
Par contre, il faudra choisir un nom pour le filtre qui prendra le relai, ou alors garder debug qui a l'avantage d'être connu car documenté, et mettre à jour sa doc.
Ben en fait j'ai découvert debug avec le mail de tonton, je ne connaissais pas
Et bel_env je trouve les infos moins lisibles qu'un simple var_dump quand on a xdebug installé (mais ça fait un moment que j'ai pas utilisé).
Perso je colle mon dd partout, et en fait je me rend compte à l'usage que c'est vraiment #ENVDD que j'utilise le plus, pour vérifier ce qu'un squelette reçoit.
C'est juste une balise à écrire, plus courte que [(#ENV|bel_env)].
Quand on débugge, on l'ajoute par ci par là, on la retire, ça m'a saoulé de devoir taper tout ça à chaque fois, d'où mon bricolage maison.
