Come esegui il debug dei plugin?

Sono abbastanza nuovo per la creazione di plug-in e ho avuto difficoltà a eseguire il debug.

Ho usato un sacco di eco ed è sciatto e brutto.

Sono sicuro che esiste un modo migliore per farlo, forse un IDE con un debugger in cui posso eseguire l'intero sito includendo il plugin?

Vai in wp-config.php e cambia define('WP_DEBUG', false);in define('WP_DEBUG', true);. Inoltre, installa il plug-in Avvisi obsoleti di Andrew Nacin .

Se stai stampando errori, allora x-debug è una brillante estensione PHP che aggiunge backtrace moderni a PHP.

Se stai cercando di capire cosa sta succedendo dove non ci sono errori, il mio approccio preferito è definire una funzione che registra il suo output in un file. Quindi faccio plog ($ variabile) e questo appare nel file di registro che posso quindi esaminare. Ciò è particolarmente utile quando stai cercando di capire cosa è successo prima che venga chiamata header () o altre situazioni in cui non puoi stampare su STDOUT.

Usa xdebug + NetBeans IDE. Quando è completamente configurato - il che è facile da fare - è possibile impostare i punti di interruzione nel plug-in e guardare le variabili nei punti di interruzione. Penso che sia il modo migliore per eseguire il debug di plugin o applicazioni php.

Eseguo il debug alla vecchia maniera, error_log()ing e var_dumping. Trovo che sia il modo più efficiente per me, ho un paio di funzioni wrapper per gestire diversi tipi di dati, poiché error_loggli array e gli oggetti possono essere una seccatura. Inoltre, usare print_r()in può essere difficile da leggere quando non è in a <pre>. Ho tj_log()per la registrazione degli errori e tj()per mostrare l'output (che mostra fondamentalmente qualsiasi tipo di dati in un modo presentabile:

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 );

}

Quindi faccio semplicemente: tj( $current_user );o qualunque cosa.

Dopo aver armeggiato con un numero di IDE, ho optato per il semplice vecchio Notepad ++ con una combinazione di colori di evidenziazione della sintassi ultra-personalizzata.

Ho una macro impostata in modo tale che quando premo Shift-Ctrl-X, il seguente codice viene emesso dove si trova il mio cursore:

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

È semplice, ma in genere posso dare la caccia al 90% dei miei bug con questa macro più WP_DEBUG abilitato.

Ho scritto una piccola classe per creare un file di registro, è molto utile quando si esegue il debug delle chiamate Ajax.

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

Devi solo fare qualcosa del tipo:

Debug :: log ("Questo è un messaggio di debug");

Quando viene eseguita quella riga, il messaggio verrà aggiunto nel file di registro e successivamente sarà possibile utilizzare il comando tail (se si utilizza un sistema operativo in stile unix)

tail -f mylogfile.log

Se riesci a passare a questa funzione anche un array o un oggetto.

si noti che è necessario modificare la riga 20 per un percorso in cui si desidera salvare il file di registro

Uso Aptane IDE su Linux e UltraEdit su Windows, e anche questo ha un PHP-parser. Inoltre, visualizzo tutti i suggerimenti di xDebug con la costante WP_DEBUGdefinita in wp-config.php.

Vedi anche il mio post su questo argomento e sentiti libero di commentare e dare feedback sui tuoi strumenti di sviluppo.

Consiglio di dare un'occhiata a FirePHP . È possibile inviare informazioni di debug alle intestazioni Firebug su HTTP di Firefox, il che di solito rende l'output di debug più pulito.

Non è poi così male: Eclipse È vicino a PhpStorm + gratuito.

Ci sono due IDE che posso consigliare e che ho usato entrambi ampiamente: PhpED (solo Windows) e PhpStorm + XDEBUG (Mac, Windows e Linux.) Sono su Mac ora, quindi posso usare solo quest'ultimo.

Entrambi ROCK! La buona notizia che PhpStorm costa $ 49 prima di settembre 2010 e solo $ 99 dopo. Se fossi su Windows e dovessi scegliere di nuovo, non sono sicuro di quale sceglierei.

Francamente non posso fare a meno di pensare che qualsiasi sviluppatore di plug-in che non utilizza uno di questi due strumenti sia gravemente handicappato, soprattutto se è relativamente nuovo nello sviluppo di plugin WordPress.

Krumo - la classe debug in stile php

Un'altra cosa davvero bella è la classe php "krumo". È implementato in ½ minuto e offre un modo semplice per eseguire il debug di tutti i tipi di variabili:

• oggetti,
• array,
• stringhe / float / intero / etc.

Inoltre aiuta con il backtracing, mostra le classi caricate o i file inclusi e tutto ciò che è richiesto.

Inoltre è GRATUITO!

Scaricare

Krumo @sourceforge

Uso un plugin da $ 13 chiamato LogPress che puoi acquistare su ThemeForest ed è un vero Dio-invia. Puoi eseguire il debug di tutto ciò che riguarda i loro plugin e il loro sito. Supporta la registrazione della console Firebug e molto altro ancora. Non posso vivere senza di essa, questo è quanto uso questo plugin.

Questo plugin è probabilmente il miglior denaro che abbia mai speso e ha risparmiato innumerevoli ore nello sviluppo del mio plugin Wordpress.

Sto usando phpED e xdebug ma per me (e sembra per qualcun altro) è impossibile eseguire il debug dei plugin o del file del tema! Il debugger si ferma solo sui punti di interruzione che si trovano nei file "core" principali o originali! qualcuno mi può aiutare?

In primo luogo aggiungo define('WP_DEBUG', false);al file wp-config.php (come molti hanno già detto) alla mia installazione locale che è una copia recente di un sito di produzione rilevante (sia file che dati). Questo rende le cose veloci, sicure, separate ma riflette bene almeno un posto dove verrà effettivamente utilizzato il plugin.

Aggiungo anche il plug-in della barra di debug insieme ad alcuni dei componenti aggiuntivi della barra di debug (ad esempio i transitori), a seconda dei plug-in.

Uso anche il componente aggiuntivo Firebug per Firefox, che è eccellente per aiutare a rintracciare i problemi html, css e JavaScript e per esaminare le stranezze del layout.

Codifico usando UltraEdit che ho usato per oltre 15 anni per un sacco di codice (da php a SQL) sia a lavoro che a casa e quindi questo funziona bene per me, ma forse non ho abbastanza per classificarlo come IDE per molte persone. Ha funzionalità di evidenziazione della sintassi, completamento automatico e funzioni di layout del codice e una serie di strumenti di scelta rapida html e css che possono aiutare a evitare errori di battitura e simili. Principalmente questo mi porta familiarità, che è un aspetto importante spesso trascurato nella corsa verso il nuovo. La memoria muscolare aiuta la ripetibilità anche nella codifica.

E ovviamente di solito ho una pagina appropriata del codice aperta in un'altra scheda su un esempio adatto.

Tutto ciò aiuta in diversi modi a evidenziare errori di codifica, analisi, funzionali e di layout e non interferisce molto nel modo in cui codifico o se nulla è sbagliato. La maggior parte può essere ignorata o disattivata per un po 'se stai sperimentando o stai lavorando a qualcosa che rivedrai in seguito.

Oh, e non c'è niente di sbagliato in un'eco ben posizionata o print_r per controllare qualcosa su un tasto (purché li rimuova quando hai finito).

Dai un'occhiata a Query Monitor combinato con Query Monitor Extend per il debug completo di WordPress (errori / avvisi / restrizioni / avvisi PHP, query su database, percorsi, costanti, richieste HTTP, transitori, variabili di sessione, dump var).

Dai un'occhiata anche a Tutti i plug-in Meta e al salvataggio dei plug-in per informazioni specifiche sui post.

PHPStorm e Xdebug è un gioco che cambia per me per lo sviluppo di WordPress. Lo consiglio vivamente ora. Specialmente con i loro strumenti di debug in linea.