I log di debug di WordPress sono più importanti di quanto pensi
Quando si tratta di lavorare con WordPress, il Codex fa un buon lavoro nel mostrare come configurare l’applicazione per il debug.
In breve, aggiungi quanto segue al tuo wp-config.php :
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
C’è altro che puoi aggiungere, ma questa è l’idea generale su ciò che trovo utile.
Ma perché preoccuparsi di coprire questo?
Log di debug di WordPress
A volte i vantaggi di avere un registro di debug sembrano ovvi. Altre volte, tuttavia, potrebbe non essere sempre evidente il motivo per cui è utile.
Abbiamo tutti sentito la scusa (al punto che è uno scherzo, in realtà):
Funziona sulla mia macchina.
Ma davvero non dovremmo essere inadempienti a questo. Passa il dollaro, è sprezzante e non è come dovremmo operare.
Un suggerimento rapido per il debug
Detto questo, questo è più o meno un rapido suggerimento su come e perché dovresti averne uno tra il tuo ambiente di sviluppo e quello di staging.
Innanzitutto, ogni volta che hai impostato il debug, verrà generato un file debug.log che puoi rivedere ogni volta che lavori nel tuo ambiente di sviluppo.
I vantaggi di questo sono generalmente evidenti:
- puoi fare riferimento ad avvisi, avvisi ed errori PHP sulla tua macchina,
- vedi il file e la riga su cui si verifica il problema,
- ottieni il timestamp di quando si verifica il problema
E allora, giusto? Voglio dire, questo è qualcosa che dovremmo fare con ogni progetto locale.
Ma nel tuo ambiente di staging, penso che sia anche importante assicurarsi che il debug sia attivato. Puoi avere quasi ogni singola cosa configurata allo stesso modo, ma se anche una cosa è diversa, il software potrebbe non funzionare allo stesso modo.
Ed è qui che e perché avere il debug impostato allo stesso modo per quanto riguarda lo staging. Spesso puoi trovare dove esistono le discrepanze.
Se esistono il tuo codice, allora c’è la responsabilità di risolverli. Altrimenti, rivelerà almeno dove sono i problemi con l’ambiente, che si tratti del server o del software di terze parti.