Comment déboguez-vous les plugins?

Je suis assez nouveau pour créer des plugins et j'avais du mal à déboguer.

J'ai utilisé beaucoup d'écho et c'est moche.

Je suis sûr qu'il existe un meilleur moyen de le faire, peut-être un IDE avec un débogueur sur lequel je peux exécuter le site entier, y compris le plugin.

Allez dans wp-config.php et changez define('WP_DEBUG', false);pour define('WP_DEBUG', true);. Installez également le plug-in Log Deprecated Notices d' Andrew Nacin .

Si vous obtenez des erreurs imprimées, x-debug est une extension PHP brillante qui ajoute des traces modernes à PHP.

Si vous essayez de déterminer ce qui se passe sans erreurs, mon approche préférée consiste à définir une fonction qui enregistre sa sortie dans un fichier. Je fais donc plog ($ variable) et cela apparaît dans le fichier journal que je peux ensuite examiner. Ceci est particulièrement utile lorsque vous essayez de savoir ce qui s'est passé avant l'appel à header () ou dans d'autres situations dans lesquelles vous ne pouvez pas imprimer sur STDOUT.

Utilisez xdebug + NetBeans IDE. Une fois entièrement configuré - ce qui est facile à faire -, vous pouvez définir des points de rupture dans votre plug-in et observer des variables aux points de rupture. Je pense que c'est le meilleur moyen de déboguer des plugins ou des applications php.

Je débogue la manière traditionnelle, error_log()ing et var_dumping. Je trouve que c’est le moyen le plus efficace pour moi. Je dispose de deux fonctions d’emballage qui permettent de traiter différents types de données, car error_logles tableaux et les objets peuvent être pénibles. En outre, l'utilisation de print_r()in peut être difficile à lire quand il ne l'est pas <pre>. J'ai tj_log()pour la journalisation des erreurs et tj()pour l'affichage de la sortie (qui montre essentiellement tout type de données dans un mannor présentable:

function tj( $code ) {

    ?>
    <style>
        .tj_debug { word-wrap: break-word; white-space: pre; text-align: left; position: relative; background-color: rgba(0, 0, 0, 0.8); font-size: 11px; color: #a1a1a1; margin: 10px; padding: 10px; margin: 0 auto; width: 80%; overflow: auto; -moz-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -webkit-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -moz-border-radius: 5px; -webkit-border-radius: 5px; text-shadow: none; }
    </style>
    <br /><pre class="tj_debug">

    <?php
    if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
        var_dump( $code );

    else :
        print_r( $code );

    endif;

    echo '</pre><br />';

}

function tj_log( $code ) {

    if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
        $code = var_export( $code, true );

    else :
        $code = print_r( $code, true );

    endif;

    error_log( $code );

}

Alors je fais juste: tj( $current_user );ou peu importe.

Après avoir bricolé plusieurs IDE, je me suis installé dans le vieux Notepad ++ avec un jeu de couleurs ultra-personnalisé Syntax Highlighting.

J'ai une macro configurée de telle sorte que lorsque je frappe Shift-Ctrl-X, le code suivant est affiché là où se trouve mon curseur:

echo "<pre>";
var_dump($);
echo "</pre>";
exit();

C'est simple, mais je peux généralement traquer 90% de mes bogues avec cette macro plus WP_DEBUG activé.

J'ai écrit une petite classe pour créer un fichier journal, ce qui est très utile lorsque vous déboguez des appels ajax.

http://github.com/hunk/Magic-Fields/blob/master/tools/debug.php

Vous devez seulement faire quelque chose comme:

Debug :: log ("Ceci est un message de débogage");

Lorsque cette ligne est exécutée, le message est ajouté dans le fichier journal et vous pouvez ensuite utiliser la commande tail (si vous utilisez un système d'exploitation de style unix).

tail -f mylogfile.log

Si vous pouvez transmettre à cette fonction un tableau ou un objet également.

notez que vous devez modifier la ligne 20 pour un chemin où vous souhaitez enregistrer votre fichier journal

J'utilise Aptane IDE sous Linux et UltraEdit sous Windows, et celui-ci dispose également d'un analyseur PHP. En outre, je visualise tous les conseils de xDebug avec la constante WP_DEBUGdéfinie dans wp-config.php.

Consultez également mon article sur ce sujet et n'hésitez pas à commenter et à commenter vos outils de développement.

Je recommande de vérifier FirePHP . Vous pouvez envoyer des informations de débogage aux en-têtes Firebug over HTTP de Firefox, ce qui permet généralement une sortie de débogage plus propre.

Pas si mal aussi: Eclipse C'est proche de PhpStorm + gratuit.

Je peux recommander deux types d’ EDI que j’ai beaucoup utilisés: PhpED (Windows uniquement) et PhpStorm + XDEBUG (Mac, Windows et Linux). Je suis maintenant sur Mac, je ne peux donc utiliser que ce dernier.

Les deux ROCK! La bonne nouvelle que PhpStorm coûte 49 $ avant septembre 2010 et seulement 99 $ après cela. Si j'étais sous Windows et que je devais choisir à nouveau, je ne savais pas lequel je choisirais.

Franchement, je ne peux pas m'empêcher de penser que tout développeur de plug-in n'utilisant pas l'un de ces deux outils est gravement handicapé, en particulier s'il est relativement nouveau dans le développement de plugins WordPress.

Krumo - la classe de débogage php stylisée

Une autre très bonne chose est la classe php "krumo". Implémenté en ½ min, il offre un moyen simple de déboguer toutes sortes de variables:

• objets,
• tableaux,
• chaînes / float / integer / etc.

De plus, il aide avec le traçage, montre les classes chargées ou les fichiers inclus et tout à la demande.

De plus, c'est GRATUIT!

Télécharger

Krumo @sourceforge

J'utilise un plugin de 13 $ appelé LogPress que vous pouvez acheter sur ThemeForest et qui est un don absolu. Vous pouvez déboguer tout ce qui concerne leurs plugins et leur site. Prend en charge la journalisation de la console Firebug et bien plus encore. Je ne peux pas m'en passer, c'est comme ça que j'utilise ce plugin.

Ce plugin est probablement le meilleur argent que j'ai jamais dépensé et il a économisé d'innombrables heures dans le développement de mon plugin Wordpress.

J'utilise phpED et xdebug mais pour moi (et semble pour quelqu'un d'autre), il est impossible de déboguer le fichier de plugins ou le thème! Le débogueur ne s'arrête que sur les points d'arrêt contenus dans les fichiers "principaux" principaux ou d'origine! Quelqu'un peut m'aider?

Tout d'abord, j'ajoute define('WP_DEBUG', false);au fichier wp-config.php (comme l'ont dit la plupart des gens) une installation récente, qui est une copie récente d'un site de production pertinent (fichiers et données). Cela rend les choses rapides, sûres, séparées mais reflète bien au moins un endroit où le plugin sera réellement utilisé.

J'ajoute également le plug-in de la barre de débogage avec certains des add-ons de la barre de débogage (transitoires par exemple) - en fonction de vos plug-ins.

J'utilise également l'add-on Firebug pour Firefox, qui est excellent pour aider à repérer les problèmes liés au html, au css et au JavaScript, ainsi que pour se familiariser avec l'étrangeté de la présentation.

Je code en utilisant UltraEdit que j'ai utilisé pendant plus de 15 ans pour tout un tas de codes (de PHP à SQL) au travail et à la maison et cela fonctionne donc bien pour moi beaucoup de gens. Il présente des fonctionnalités de coloration syntaxique, de complétion automatique et de présentation du code, ainsi que de nombreux outils de raccourci HTML et CSS permettant d'éviter les fautes de frappe et autres. Généralement, cela m’apporte une familiarité qui est un aspect important souvent négligé dans la course au nouveau. La mémoire musculaire facilite la répétabilité, même lors du codage.

Et bien sûr, une page appropriée du codex est généralement ouverte dans un autre onglet d'un exemple approprié.

Celles-ci aident toutes de différentes manières à mettre en évidence les erreurs de codage, d’analyse, de fonctionnalité et d’agencement et n’interfèrent pas beaucoup dans la façon dont je code ou si rien ne va. La plupart peuvent être ignorés ou désactivés un peu si vous expérimentez ou travaillez sur quelque chose que vous revisiterez plus tard.

Oh, et il n'y a rien de mal avec un écho ou une print_r bien positionné pour vérifier quelque chose d'une clé (tant que vous les enlevez quand vous avez terminé).

Découvrez Query Monitor associé à Query Monitor Extend pour un débogage complet de WordPress (erreurs / remarques / restrictions / avertissements PHP, requêtes de base de données, chemins, constantes, requêtes HTTP, transitoires, variables de session, vidages de variables).

Consultez également tous les plug-ins Meta et Saving What pour obtenir des informations spécifiques sur les posts.

PHPStorm et Xdebug est un jeu qui change pour moi pour le développement WordPress. Je le recommande vivement maintenant. Spécialement avec leurs outils de débogage en ligne.