Come eseguire il debug dei plugin in WordPress?

Vai nel file wp-config.php e cambia define('WP_DEBUG', false); in define('WP_DEBUG', true);. Inoltre, installa il plugin Log Deprecated Notices di Andrew Nacin.

Se stai ricevendo errori stampati, allora x-debug è un'estensione PHP fantastica che aggiunge backtrace moderni a PHP.

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

Utilizza xdebug + NetBeans IDE. Una volta configurato correttamente - operazione piuttosto semplice - potrai impostare punti di interruzione nel tuo plugin e osservare le variabili in corrispondenza di tali punti. Penso sia il metodo migliore per il debug di plugin o, in generale, di qualsiasi applicazione PHP.

Dopo aver sperimentato con diversi IDE, alla fine ho scelto il vecchio caro Notepad++ con uno schema di colori per l'evidenziazione della sintassi ultra personalizzato.

Ho configurato una macro in modo che quando premo Maiusc-Ctrl-X, viene inserito il seguente codice nella posizione del cursore:

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

È semplice, ma con questa macro e WP_DEBUG attivato riesco generalmente a identificare il 90% dei bug.

Debuggo alla vecchia maniera, usando error_log() e var_dump(). Trovo che sia il modo più efficiente per me, ho un paio di funzioni wrapper per gestire diversi tipi di dati, visto che usare error_log() con array e oggetti può essere complicato. Inoltre, usare print_r() può risultare difficile da leggere quando non è racchiuso in un tag <pre>. Ho creato tj_log() per il logging degli errori e tj() per mostrare l'output (che fondamentalmente visualizza qualsiasi tipo di dati in 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 semplicemente faccio: tj( $current_user ); o qualsiasi altra variabile.

Ho scritto una piccola classe per creare un file di log, è molto utile quando stai eseguendo il debug di chiamate ajax.

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

Hai solo bisogno di fare qualcosa come:

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

Quando quella riga viene eseguita, il messaggio verrà aggiunto nel file di log e successivamente puoi usare il comando tail (se stai usando un sistema operativo di tipo Unix)

tail -f mylogfile.log

Puoi passare a questa funzione anche un array o un oggetto.

nota devi modificare la riga 20 con un percorso dove vuoi salvare il tuo file di log

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

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

Ti consiglio di dare un'occhiata a FirePHP. Puoi inviare informazioni di debug al Firebug di Firefox tramite intestazioni HTTP, il che solitamente produce un output di debug più pulito.

Non male anche: Eclipse È vicino a PhpStorm + gratuito.

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

Entrambi sono ECCEZIONALI! La buona notizia è che PhpStorm costa $49 fino a settembre 2010 e solo $99 dopo quella data. Se fossi su Windows e dovessi scegliere di nuovo, non sono sicuro quale opzione prenderei.

Francamente, non posso fare a meno di pensare che qualsiasi sviluppatore di plugin che non utilizzi uno di questi due strumenti sia fortemente svantaggiato, specialmente se relativamente nuovo allo sviluppo di plugin per WordPress.

Krumo - la classe PHP per il debug con stile

Un'altra cosa davvero utile è la classe PHP "krumo". Si implementa in ½ minuto e offre un modo semplice per eseguire il debug di ogni tipo di variabile:

• oggetti,
• array,
• stringhe/float/interi/ecc.

In più aiuta con il backtracing, mostra le classi caricate o i file inclusi e tutto su richiesta.

In più è GRATIS!

Download

Krumo @sourceforge

Utilizzo un plugin da $13 chiamato LogPress che puoi acquistare su ThemeForest ed è assolutamente provvidenziale. Puoi eseguire il debug di tutto ciò che riguarda i loro plugin e il sito. Supporta la registrazione nella console di Firebug e molto altro ancora. Non potrei farne a meno, lo uso così tanto questo plugin.

Probabilmente questo plugin è il miglior investimento che abbia mai fatto e mi ha fatto risparmiare innumerevoli ore nello sviluppo di plugin per Wordpress.

Sto utilizzando phpED e xdebug ma per me (e sembra anche per altri) è impossibile eseguire il debug dei file dei plugin o del tema! Il debugger si ferma solo sui breakpoint che si trovano nei file "core" principali o originali! qualcuno può aiutarmi?

Innanzitutto aggiungo define('WP_DEBUG', false); al file wp-config.php (come hanno detto molti) nella 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 luogo in cui il plugin verrà effettivamente utilizzato.

Aggiungo anche il plugin Debug Bar insieme ad alcune delle estensioni di Debug Bar (ad esempio Transients) - a seconda di ciò che è appropriato per i tuoi plugin.

Utilizzo anche l'estensione Firebug per Firefox che è eccellente per aiutare a identificare problemi di html, css e JavaScript, così come per analizzare stranezze di layout.

Programmo usando UltraEdit che ho utilizzato per oltre 15 anni per un'ampia gamma di codifiche (dal php a SQL) sia al lavoro che a casa, quindi per me funziona bene anche se forse non ha abbastanza funzionalità per essere considerato un IDE da molte persone. Ha evidenziazione della sintassi, completamento automatico e funzionalità di formattazione del codice, oltre a una serie di strumenti rapidi per html e css che possono aiutare a evitare errori di battitura e simili. Soprattutto, mi offre familiarità, un aspetto spesso trascurato nella corsa alla novità. La memoria muscolare aiuta la ripetibilità, anche nella programmazione.

E ovviamente di solito ho qualche pagina appropriata del codex aperta in un'altra scheda come esempio adatto.

Tutti questi elementi aiutano in modi diversi a evidenziare errori di codifica, analisi, funzionalità e layout e non interferiscono molto con il mio modo di programmare o se non c'è nulla di sbagliato. La maggior parte può essere ignorata o disattivata per un po' se stai sperimentando o lavorando su qualcosa che riprenderai più tardi.

Ah, e non c'è nulla di male in un echo o print_r ben posizionati per controllare qualcosa in un punto chiave (purché li rimuovi quando hai finito).

Dai un'occhiata a Query Monitor combinato con Query Monitor Extend per un debug completo di WordPress (errori PHP/notice/strict/warning, query al database, percorsi, costanti, richieste HTTP, transient, variabili di sessione, var dump).

Consulta anche i plugin All Post Meta e Saving What per informazioni specifiche sui post.

PHPStorm e Xdebug sono stati rivoluzionari per il mio sviluppo su WordPress. Lo consiglio vivamente ora. Specialmente con i loro strumenti di debug inline.