Comment déboguez-vous les scripts PHP? [fermé]

Comment déboguez-vous les scripts PHP ?

Je connais le débogage de base, comme l'utilisation du rapport d'erreurs. Le débogage de point d'arrêt dans PHPEclipse est également très utile.

Quelle est la meilleure façon (rapide et facile) de déboguer dans phpStorm ou tout autre IDE?

Essayez Eclipse PDT pour configurer un environnement Eclipse qui possède des fonctionnalités de débogage comme vous l'avez mentionné. La possibilité d'entrer dans le code est une bien meilleure façon de déboguer que l'ancienne méthode de var_dump et d'imprimer à différents points pour voir où votre flux se passe mal. Quand tout le reste échoue et que je n'ai que SSH et vim, je trouve var_dump()/ die()pour trouver où le code va vers le sud.

Vous pouvez utiliser Firephp un add-on pour firebug pour déboguer php dans le même environnement que javascript.

J'utilise également Xdebug mentionné plus haut pour le profilage de php.

Voici mon petit environnement de débogage:

error_reporting(-1);
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 0);
assert_options(ASSERT_QUIET_EVAL, 0);
assert_options(ASSERT_CALLBACK, 'assert_callcack');
set_error_handler('error_handler');
set_exception_handler('exception_handler');
register_shutdown_function('shutdown_handler');

function assert_callcack($file, $line, $message) {
    throw new Customizable_Exception($message, null, $file, $line);
}

function error_handler($errno, $error, $file, $line, $vars) {
    if ($errno === 0 || ($errno & error_reporting()) === 0) {
        return;
    }

    throw new Customizable_Exception($error, $errno, $file, $line);
}

function exception_handler(Exception $e) {
    // Do what ever!
    echo '<pre>', print_r($e, true), '</pre>';
    exit;
}

function shutdown_handler() {
    try {
        if (null !== $error = error_get_last()) {
            throw new Customizable_Exception($error['message'], $error['type'], $error['file'], $error['line']);
        }
    } catch (Exception $e) {
        exception_handler($e);
    }
}

class Customizable_Exception extends Exception {
    public function __construct($message = null, $code = null, $file = null, $line = null) {
        if ($code === null) {
            parent::__construct($message);
        } else {
            parent::__construct($message, $code);
        }
        if ($file !== null) {
            $this->file = $file;
        }
        if ($line !== null) {
            $this->line = $line;
        }
    }
}

Xdebug et le plugin DBGp pour Notepad ++ pour la chasse aux bogues lourds, FirePHP pour les trucs légers. Rapide et sale? Rien ne vaut dBug .

XDebug est essentiel pour le développement. Je l'installe avant toute autre extension. Il vous donne des traces de pile sur toute erreur et vous pouvez activer facilement le profilage.

Pour un aperçu rapide de l'utilisation d'une structure de données var_dump(). Ne l'utilisez pas print_r()car vous devrez l'entourer <pre>et il n'imprimera qu'une seule var à la fois.

<?php var_dump(__FILE__, __LINE__, $_REQUEST); ?>

Pour un véritable environnement de débogage, le meilleur que j'ai trouvé est Komodo IDE mais cela coûte $$.

PhpEd est vraiment bon. Vous pouvez entrer / sortir / sortir des fonctions. Vous pouvez exécuter du code ad hoc, inspecter des variables, modifier des variables. C'est étonnant.

1) J'utilise print_r (). Dans TextMate, j'ai un extrait de «pré» qui se développe comme suit:

echo "<pre>";
print_r();
echo "</pre>";

2) J'utilise Xdebug, mais je n'ai pas réussi à faire fonctionner l'interface graphique sur mon Mac. Il imprime au moins une version lisible de la trace de pile.

J'ai utilisé le Zend Studio (5.5) avec Zend Platform . Cela donne un débogage correct, des points d'arrêt / un dépassement du code, etc., bien qu'à un prix.

En toute honnêteté, une combinaison de print et print_r () pour imprimer les variables. Je sais que beaucoup préfèrent utiliser d'autres méthodes plus avancées mais je trouve que c'est la plus simple à utiliser.

Je dirai que je n'ai pas vraiment apprécié cela jusqu'à ce que je fasse de la programmation sur microprocesseur chez Uni et que je n'ai pas pu l'utiliser même.

Xdebug , de Derick Rethans, est très bon. Je l'ai utilisé il y a quelque temps et j'ai trouvé que ce n'était pas si facile à installer. Une fois que vous avez terminé, vous ne comprendrez pas comment vous vous en sortez sans :-)

Il y a un bon article sur Zend Developer Zone (l'installation sur Linux ne semble pas plus facile) et même un plugin Firefox , que je n'ai jamais utilisé.

J'utilise Netbeans avec XDebug. Consultez-le sur son site Web pour obtenir des documents sur la façon de le configurer. http://php.netbeans.org/

J'utilise Netbeans avec XDebug et le module complémentaire Easy XDebug FireFox

Le module complémentaire est essentiel lorsque vous déboguez des projets MVC, car la façon normale dont XDebug s'exécute dans Netbeans consiste à enregistrer la session dbug via l'URL. Avec le module complémentaire installé dans FireFox, vous devez définir les propriétés de votre projet Netbeans -> Exécuter la configuration -> Avancé et sélectionner "Ne pas ouvrir le navigateur Web". Vous pouvez maintenant définir vos points d'arrêt et démarrer la session de débogage avec Ctrl-F5 comme d'habitude. . Ouvrez FireFox et cliquez avec le bouton droit sur l'icône du module complémentaire dans le coin inférieur droit pour démarrer la surveillance des points d'arrêt. Lorsque le code atteint le point d'arrêt, il s'arrête et vous pouvez inspecter vos états de variable et votre pile d'appels.

La mise en mémoire tampon de sortie est très utile si vous ne voulez pas gâcher votre sortie. Je le fais dans un one-liner que je peux commenter / décommenter à volonté

 ob_start();var_dump(); user_error(ob_get_contents()); ob_get_clean();

PhpEdit a un débogueur intégré, mais je finis généralement par utiliser echo (); et print_r (); à l'ancienne !!

Pour les problèmes vraiment graves qui prendraient trop de temps à utiliser print_r / echo pour comprendre que j'utilise la fonction de débogage de mon IDE (PhpEd). Contrairement aux autres IDE que j'ai utilisés, PhpEd ne nécessite pratiquement aucune configuration. la seule raison pour laquelle je ne l'utilise pas pour les problèmes que je rencontre, c'est qu'il est douloureusement lent. Je ne suis pas sûr que la lenteur soit spécifique à PhpEd ou à n'importe quel débogueur php. PhpEd n'est pas gratuit mais je pense qu'il utilise de toute façon l'un des débogueurs open source (comme XDebug mentionné précédemment). L'avantage avec PhpEd, encore une fois, est qu'il ne nécessite aucune configuration que j'ai trouvée très fastidieuse dans le passé.

Le débogage manuel est généralement plus rapide pour moi - var_dump()et debug_print_backtrace()sont tous les outils dont vous avez besoin pour armer votre logique.

Eh bien, dans une certaine mesure, cela dépend de l’orientation vers le sud. C'est la première chose que j'essaie d'isoler, puis j'utiliserai echo / print_r () si nécessaire.

NB: Vous savez que vous pouvez passer true comme deuxième argument à print_r () et cela retournera la sortie au lieu de l'imprimer? Par exemple:

echo "<pre>".print_r($var, true)."</pre>";

J'utilise souvent CakePHP lorsque Rails n'est pas possible. Pour déboguer les erreurs, je trouve généralement leerror.log dans le dossier tmp et le queue dans le terminal avec la commande ...

tail -f app/tmp/logs/error.log

Cela vous donne une boîte de dialogue en cours d'exécution à partir de ce qui se passe, ce qui est assez pratique, si vous voulez lui envoyer quelque chose en milieu de code, vous pouvez l'utiliser.

$this->log('xxxx');

Cela peut généralement vous donner une bonne idée de ce qui se passe / mal.

print_r (debug_backtrace ());

ou quelque chose comme ça :-)

Komodo IDE fonctionne bien avec xdebug, même pour le débogage de remore. Il nécessite un minimum de configuration. Tout ce dont vous avez besoin est une version de php que Komodo peut utiliser localement pour parcourir le code sur un point d'arrêt. Si vous avez le script importé dans le projet komodo, vous pouvez définir des points d'arrêt avec un clic de souris exactement comme vous le définiriez dans eclipse pour déboguer un programme java. Le débogage à distance est évidemment plus difficile à faire fonctionner correctement (vous devrez peut-être mapper l'URL à distance avec un script php dans votre espace de travail) qu'une configuration de débogage locale qui est assez facile à configurer si vous êtes sur un MAC ou un bureau Linux .

Nusphere est aussi un bon débogueur pour php nusphere

Il existe de nombreuses techniques de débogage PHP qui peuvent vous faire économiser d'innombrables heures lors du codage. Une technique de débogage efficace mais basique consiste simplement à activer le rapport d'erreurs. Une autre technique légèrement plus avancée consiste à utiliser des instructions d'impression, ce qui peut aider à identifier des bogues plus insaisissables en affichant ce qui se passe réellement à l'écran. PHPeclipse est un plug-in Eclipse qui peut mettre en évidence des erreurs de syntaxe courantes et peut être utilisé en conjonction avec un débogueur pour définir des points d'arrêt.

display_errors = Off
error_reporting = E_ALL 
display_errors = On

et aussi utilisé

error_log();
console_log();

Dans un environnement de production, j'enregistre les données pertinentes dans le journal des erreurs du serveur avec error_log ().

j'utilise zend studio pour eclipse avec le débogueur intégré. C'est toujours lent comparé au débogage avec eclipse pdt avec xdebug. Espérons qu'ils résoudront ces problèmes, la vitesse s'est améliorée par rapport aux versions récentes, mais le dépassement prend encore 2-3 secondes. La barre d'outils zend firefox facilite vraiment les choses (débogage page suivante, page actuelle, etc.). Il fournit également un profileur qui évaluera votre code et fournira des graphiques circulaires, le temps d'exécution, etc.

La plupart des bogues peuvent être trouvés facilement par simple var_dump ajoutant certaines des variables clés, mais cela dépend évidemment du type d'application que vous développez.

Pour des algorithmes plus complexes, les fonctions step / breakpoint / watch sont très utiles (si ce n'est pas nécessaire)

PHP DBG

Le débogueur interactif PHP étape par étape implémenté comme un module SAPI qui peut vous donner un contrôle complet sur l'environnement sans impact sur la fonctionnalité ou les performances de votre code. Il vise à être une plate-forme de débogage légère, puissante et facile à utiliser pour PHP 5.4+ et il est livré avec PHP 5.6.

Les fonctionnalités incluent:

• Débogage pas à pas
• Points d'arrêt flexibles (méthode de classe, fonction, fichier: ligne, adresse, code d'opération)
• Accès facile à PHP avec eval intégré ()
• Accès facile au code en cours d'exécution
• API Userland
• SAPI Agnostic - Facilement intégré
• Prise en charge des fichiers de configuration PHP
• JIT Super Globals - Définissez le vôtre !!
• Prise en charge de la ligne de lecture en option - Fonctionnement confortable du terminal
• Prise en charge du débogage à distance - Interface graphique Java intégrée
• Opération facile

Voir les captures d'écran:

Page d'accueil: http://phpdbg.com/

Erreur PHP - Meilleur rapport d'erreurs pour PHP

C'est une bibliothèque très facile à utiliser (en fait un fichier) pour déboguer vos scripts PHP.

La seule chose que vous devez faire est d'inclure un fichier comme ci-dessous (au début sur votre code):

require('php_error.php');
\php_error\reportErrors();

Ensuite, toutes les erreurs vous donneront des informations telles que la trace, le contexte du code, les arguments de fonction, les variables de serveur, etc. Par exemple:

Les fonctionnalités incluent:

• trivial à utiliser, c'est juste un fichier
• erreurs affichées dans le navigateur pour les requêtes normales et ajaxy
• Les requêtes AJAX sont suspendues, vous permettant de les réexécuter automatiquement
• rend les erreurs aussi strictes que possible (encourage la qualité du code et tend à améliorer les performances)
• extraits de code sur toute la trace de la pile
• fournit plus d'informations (telles que les signatures de fonctions complètes)
• corrige certains messages d'erreur qui sont tout simplement faux
• coloration syntaxique
• semble joli!
• personnalisation
• allumer et éteindre manuellement
• exécuter des sections spécifiques sans rapport d'erreur
• ignorer les fichiers vous permettant d'éviter de mettre en évidence le code dans votre trace de pile
• fichiers d'application; ceux-ci sont prioritaires en cas d'erreur!

Page d'accueil: http://phperror.net/

GitHub: https://github.com/JosephLenton/PHP-Error

Ma fourchette (avec correctifs supplémentaires): https://github.com/kenorb-contrib/PHP-Error

DTrace

Si votre système prend en charge le traçage dynamique DTrace (installé par défaut sur OS X) et que votre PHP est compilé avec les sondes DTrace activées ( --enable-dtrace) qui devraient être par défaut, cette commande peut vous aider à déboguer le script PHP sans délai:

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

Donc, étant donné que l'alias suivant a été ajouté à vos fichiers rc (par exemple ~/.bashrc, ~/.bash_aliases):

alias trace-php='sudo dtrace -qn "php*:::function-entry { printf(\"%Y: PHP function-entry:\t%s%s%s() in %s:%d\n\", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }"'

vous pouvez tracer votre script avec facile à retenir alias: trace-php.

Voici un script dtrace plus avancé, il suffit de l'enregistrer dtruss-php.d, de le rendre exécutable ( chmod +x dtruss-php.d) et de l'exécuter:

#!/usr/sbin/dtrace -Zs
# See: https://github.com/kenorb/dtruss-lamp/blob/master/dtruss-php.d

#pragma D option quiet

php*:::compile-file-entry
{
    printf("%Y: PHP compile-file-entry:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1));
}

php*:::compile-file-return
{
    printf("%Y: PHP compile-file-return:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), basename(copyinstr(arg1)));
}

php*:::error
{
    printf("%Y: PHP error message:\t%s in %s:%d\n", walltimestamp, copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::exception-caught
{
    printf("%Y: PHP exception-caught:\t%s\n", walltimestamp, copyinstr(arg0));
}

php*:::exception-thrown
{
    printf("%Y: PHP exception-thrown:\t%s\n", walltimestamp, copyinstr(arg0));
}

php*:::execute-entry
{
    printf("%Y: PHP execute-entry:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);
}

php*:::execute-return
{
    printf("%Y: PHP execute-return:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);
}

php*:::function-entry
{
    printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::function-return
{
    printf("%Y: PHP function-return:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);
}

php*:::request-shutdown
{
    printf("%Y: PHP request-shutdown:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));
}

php*:::request-startup
{
    printf("%Y, PHP request-startup:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));
}

^{Page d'accueil: dtruss-lamp chez GitHub}

Voici une utilisation simple:

1. Run: sudo dtruss-php.d.
2. Sur une autre course terminal: php -r "phpinfo();".

Pour tester cela, vous pouvez aller dans n'importe quel docroot avec index.phpet exécuter le serveur PHP intégré en:

php -S localhost:8080

Après cela, vous pouvez accéder au site à http: // localhost: 8080 / (ou choisir le port qui vous convient). De là, accédez à certaines pages pour voir la sortie de trace.

Remarque: Dtrace est disponible sur OS X par défaut, sous Linux, vous avez probablement besoin de dtrace4linux ou recherchez d'autres alternatives .

Voir: Utiliser PHP et DTrace sur php.net

SystemTap

Vous pouvez également vérifier le suivi SystemTap en installant le package de développement SystemTap SDT (par exemple yum install systemtap-sdt-devel).

Voici un exemple de script ( all_probes.stp) pour tracer tous les points de sonde statiques PHP principaux pendant toute la durée d'un script PHP en cours d'exécution avec SystemTap:

probe process("sapi/cli/php").provider("php").mark("compile__file__entry") {
    printf("Probe compile__file__entry\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
}
probe process("sapi/cli/php").provider("php").mark("compile__file__return") {
    printf("Probe compile__file__return\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
}
probe process("sapi/cli/php").provider("php").mark("error") {
    printf("Probe error\n");
    printf("  errormsg %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
}
probe process("sapi/cli/php").provider("php").mark("exception__caught") {
    printf("Probe exception__caught\n");
    printf("  classname %s\n", user_string($arg1));
}
probe process("sapi/cli/php").provider("php").mark("exception__thrown") {
    printf("Probe exception__thrown\n");
    printf("  classname %s\n", user_string($arg1));
}
probe process("sapi/cli/php").provider("php").mark("execute__entry") {
    printf("Probe execute__entry\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
}
probe process("sapi/cli/php").provider("php").mark("execute__return") {
    printf("Probe execute__return\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
}
probe process("sapi/cli/php").provider("php").mark("function__entry") {
    printf("Probe function__entry\n");
    printf("  function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
}
probe process("sapi/cli/php").provider("php").mark("function__return") {
    printf("Probe function__return: %s\n", user_string($arg1));
    printf(" function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
}
probe process("sapi/cli/php").provider("php").mark("request__shutdown") {
    printf("Probe request__shutdown\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));
}
probe process("sapi/cli/php").provider("php").mark("request__startup") {
    printf("Probe request__startup\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));
}

Usage:

stap -c 'sapi/cli/php test.php' all_probes.stp

Voir: Utiliser SystemTap avec PHP DTrace Static Probes sur php.net

+1 pour print_r (). Utilisez-le pour vider le contenu d'un objet ou d'une variable. Pour le rendre plus lisible, faites-le avec une balise pre afin que vous n'ayez pas besoin d'afficher la source.

echo '<pre>';
print_r($arrayOrObject);

Aussi var_dump ($ thing) - c'est très utile pour voir le type de sous-éléments

En fonction du problème, j'aime une combinaison de error_reporting (E_ALL) mélangée à des tests d'écho (pour trouver la ligne / le fichier incriminé, l'erreur s'est produite au départ; vous SAVEZ que ce n'est pas toujours la ligne / le fichier php qui vous le dit?), La correspondance des accolades IDE (pour résoudre les problèmes "Erreur d'analyse: erreur de syntaxe, $ end inattendu") et print_r (); sortie; dumps (les vrais programmeurs voient la source; p).

Vous ne pouvez pas non plus battre phpdebug (vérifier sourceforge) avec "memory_get_usage ();" et "memory_get_peak_usage ();" pour trouver les zones problématiques.

Les débogueurs intégrés où vous pouvez regarder les valeurs de changement de variable pendant que vous parcourez le code sont vraiment cool. Ils nécessitent cependant une configuration logicielle sur le serveur et une certaine quantité de configuration sur le client. Les deux nécessitent un entretien périodique pour rester en bon état de fonctionnement.

Un print_r est facile à écrire et est garanti pour fonctionner dans n'importe quelle configuration.

Habituellement, je trouve créer une fonction de journal personnalisé capable d'enregistrer sur un fichier, de stocker des informations de débogage et finalement de réimprimer sur un pied de page commun.

Vous pouvez également remplacer la classe d'exception commune, afin que ce type de débogage soit semi-automatisé.