Definire WP_DEBUG in modo condizionale / solo per amministratori / log errori (aggiungere parametro query per tutti i link?)

17 ott 2012, 16:16:40
Visualizzazioni: 19.7K
Voti: 22

Sto sviluppando un sito su un server a cui ha accesso anche il cliente e vorrei mostrare WP_DEBUG solo per gli amministratori. Facendo riferimento all'articolo di Yoast su una soluzione alternativa:

if ( isset($_GET['debug']) && $_GET['debug'] == 'true')
    define('WP_DEBUG', true);

mostrerebbe WP_DEBUG solo per gli URL che hanno ?debug=true allegato, come http://domain.com/?debug=true

Stavo pensando che la Debug Bar potrebbe contenere alcune di queste informazioni di default (se WP_DEBUG è attivato o meno), ma credo di aver pensato una follia poiché non penso sia questo il caso.

Quindi, stavo pensando che sarebbe utile fare un controllo per l'utente corrente (avente la capability manage_options e poi processare i link attraverso add_query_arg():

function zs_admin_debug() {
    if (!current_user_can('manage_options')) {
        add_query_arg('debug','true');
    }
}

ma quello di cui non sono sicuro è - esiste un hook che posso usare per applicare questo a tutti i link di un sito? In questo modo, gli amministratori vedrebbero sempre il debug che ho pensato sarebbe estremamente utile. Grazie per qualsiasi aiuto come sempre!

1
Commenti

Questa soluzione alternativa (di Yoast) è estremamente utile per il debug immediato. Ho anche abilitato la registrazione dei log che funziona bene. Ho leggermente modificato il mio codice: if ( isset( $_GET['bug'] ) ) così visito link/?bug per vedere il debug :)

Jarod Thornton Jarod Thornton
3 mar 2017 05:13:21
Tutte le risposte alla domanda 6
3
17

Non credo esista un hook universale per gli URL. Ci sono molti hook e potrei averne perso qualcuno, ma non penso esista uno universale. Puoi cercare tra gli hook su adambrown.info. Ci sono molti hook relativi agli URL, ma non uno universale.

Se posso suggerire un'altra soluzione: registra gli errori su un file.

/**
 * Questo registrerà tutti gli errori, avvisi e warning in un file chiamato debug.log
 * nella cartella wp-content (se Apache non ha i permessi di scrittura, potresti dover creare
 * prima il file e impostare i permessi appropriati (es. usare 666)) 
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

Questo codice è preso direttamente dal Codex per il file wp-config.php. Se lo usi, non dovrai preoccuparti di gestire $_GET o capire chi è e chi non è un amministratore.

Modifica:

Ho dimenticato una possibile soluzione. Puoi farlo con Javascript. Un breve script potrebbe aggiungere il tuo parametro a tutti gli URL nella pagina, e puoi facilmente caricare lo script solo per gli amministratori.

Consiglierei comunque la soluzione con il 'log' poiché gli errori di tutti vengono registrati. Se le tue persone sono come le mie e inviano 'segnalazioni' di errori tipo "ehi, il sito si rompe quando fai quel modulo" apprezzerai il log. :)

17 ott 2012 16:33:09
Commenti

Immagino di essere solo viziato dal vederli sullo schermo :) ma un file di log ha più senso in questo caso. Farò ulteriori ricerche da parte mia, ma questa sembra essere la soluzione migliore che ho trovato finora. Grazie!

Zach Zach
17 ott 2012 17:42:08

Nota che il logging nativo è hardcoded per scrivere su un file accessibile dal web, il che non è una buona idea in produzione. È meglio configurare un percorso privato (fuori dalla cartella web) per il file di log tramite strumenti PHP per i siti live.

Rarst Rarst
17 ott 2012 17:51:55

@Rarst +1!!! E dalla versione 5.1 possiamo ora specificare la posizione molto facilmente, define('WP_DEBUG_LOG', '/percorso/del/server/qui/debug.log');

deflime deflime
10 giu 2022 03:16:17
5
10

Anche se il mio primo approccio era da cestinare e la risposta di s_ha_dum è un modo pulito, e probabilmente il migliore, di affrontare la questione, permettimi di offrire un ulteriore scenario funzionante:

Il seguente codice imposta un cookie valido per le prossime 24 ore (86400 secondi) quando un amministratore accede al sistema. In wp-config.php, la costante WP_DEBUG viene definita condizionatamente in base alla presenza e al valore di detto cookie.

Avvertenza: WP_DEBUG sarà quindi impostato a true per tutti coloro che accedono dallo stesso browser sulla stessa macchina nello stesso giorno.

in functions.php (o come plugin):

/** 
 * Attiva il debug per gli amministratori impostando un cookie
 * @param string $user_login Nome utente
 * @param WP_User $user Oggetto utente
 */
function wpse_69549_admin_debug( $user_login, $user )
{
    // Verifica se l'utente è un amministratore
    if ( in_array( 'administrator', $user->roles ) ) {
        // Imposta un cookie 'wp_debug' valido per 24 ore
        setcookie( 'wp_debug', 'on', time() + 86400, '/', get_site_option( 'siteurl' ) );
    }
}
// Aggiunge l'azione all'evento di login
add_action( 'wp_login', 'wpse_69549_admin_debug', 10, 2 );

Vedi: Codex > Riferimento Azioni > wp_login

in wp-config.php:

// Verifica la presenza del cookie di debug
if ( isset( $_COOKIE['wp_debug'] ) && 'on' === $_COOKIE['wp_debug'] ) {
    // Abilita il debug se il cookie è presente e impostato su 'on'
    define( 'WP_DEBUG', true );
} else {
    // Disabilita il debug in caso contrario
    define( 'WP_DEBUG', false );
}
17 ott 2012 17:42:07
Commenti

Andrew Nacin ha commentato quell'articolo, menzionando che init è troppo tardi per avere alcun effetto. Ho anche provato questo approccio e non ha funzionato.

Zach Zach
17 ott 2012 17:45:24

Le costanti non possono essere ridefinite. Si potrebbe modificare il livello di report degli errori senza toccare la costante, ma non è una soluzione perfetta. Inoltre, ci sono molte cose che accadono prima di init che possono essere di interesse.

Rarst Rarst
17 ott 2012 17:46:33

Penso che la risposta accettata rimanga la soluzione più valida, tuttavia, per completezza, questo nuovo approccio dovrebbe funzionare con i notice di debug a schermo.

Johannes Pille Johannes Pille
17 ott 2012 19:33:08

Ah, soluzione molto interessante - ci proverò sicuramente

Zach Zach
17 ott 2012 23:53:39

@s_ha_dum: Non è che uno si ricordi ogni risposta - almeno io no (ho cercato su Google le mie stesse risposte in passato). Questa però me la ricordo. Ero stato il primo a rispondere e avevo scritto una schifezza totale. Non c'entrava nulla. Sego una politica di non rispondere a meno di non essere sicuro al 99,5% di essere qualificato (immagino valga lo stesso per te) - qui ero completamente fuori strada. Mi ha fatto incazzare così tanto che, anche dopo che la risposta era stata accettata, ci ho pensato per ore e ho trovato la soluzione sopra. Anche a me sembra piuttosto elegante - grazie per averlo notato.

Johannes Pille Johannes Pille
25 mar 2013 02:10:58
3

Non risponde esattamente alla tua domanda, ma per esperienza personale ho scoperto che è meglio abilitare la modalità debug abbinando l'indirizzo IP invece dell'URL.

Questo richiede la modifica dei link e risolve il problema di come identificare l'amministratore prima che WordPress carichi le funzionalità utente necessarie.

17 ott 2012 17:50:28
Commenti

Anche a me piace questa idea - quindi se facessi qualcosa come http://pastebin.com/m22KNakh potrebbe... in teoria funzionare, corretto? Eseguire echo $_SERVER['REMOTE_ADDR'] restituisce ::1 che è ciò che ci si aspetta su localhost? Sinceramente sembra un file di log separato e questo metodo (visto che gli IP di casa sembrano cambiare spesso) potrebbe essere una buona idea.

Zach Zach
17 ott 2012 18:05:40

@Zach sì, ::1 è semplicemente la versione IPv6 di 127.0.0.1. L'IP dinamico lo rende meno conveniente, ma comunque lo considero solo come una tecnica temporanea di risoluzione dei problemi per ambienti live. Non sostituisce un corretto setup di debug locale.

Rarst Rarst
17 ott 2012 18:19:33

Ah grazie per l'informazione. Mi piacciono davvero entrambe le opzioni qui, opterò per la risposta di @s_ha_dum (oltre al tuo commento che ho votato positivamente) che è anche ottima. Grazie ancora, lo apprezzo davvero!

Zach Zach
17 ott 2012 18:21:34
0

Se hai un IP statico, puoi fare così:

if ('YOUR_IP_ADDRESS' == $_SERVER['REMOTE_ADDR']) {
    define('WP_DEBUG', true);
} else {
    define('WP_DEBUG', false);   
}

Fonte: DEBUGGING IN WORDPRESS – COME USARE WP_DEBUG SU UN SITO IN PRODUZIONE

27 giu 2018 21:00:00
0

Questo è un altro trucco possibile, ma devi inserirlo nel tuo file wp-config.php poiché WP_DEBUG viene definito lì:

if ( isset( $_GET['debugsecret'] ) && 'debugsecret' == $_GET['debugsecret'] ) {
      define( 'WP_DEBUG', true );         
}

Aggiungi ?debugsecret=debugsecret all'URL della pagina che vuoi debuggare.

24 apr 2016 04:05:07
0

Per aggiungere un'altra opzione, ho creato una combinazione di diverse risposte. Questa permette di cambiare istantaneamente lo stato della modalità debug (abilitata/disabilitata) per un'ora con un parametro URL e anche di restringere chi può effettuare il cambiamento tramite IP.

Sostituisci la tua riga WP_DEBUG in wp-config.php con questo:

//Imposta la modalità debug predefinita. Di solito dovrebbe essere false
$CURRENT_DEBUG_MODE=false;
//togli il commento per impostare una restrizione per IP.
//$DEVEL_IP_ADDRESS = 'IL TUO IP';

//usa il cookie per impostare la modalità debug per 1 ora con il parametro URL ?debugmode = [on,off]
if (!isset($DEVEL_IP_ADDRESS) || $DEVEL_IP_ADDRESS == $_SERVER['REMOTE_ADDR'])
{
    if (isset($_GET['debugmode'])) {
        $CURRENT_DEBUG_MODE = 'on'==$_GET['debugmode']?true:false;
        setcookie("wp_debugmode", $_GET['debugmode'],time()+3600,'/');
    }
    else if (isset($_COOKIE['wp_debugmode'])) {$CURRENT_DEBUG_MODE = 'on'==$_COOKIE['wp_debugmode']?true:false;}
}
define('WP_DEBUG', $CURRENT_DEBUG_MODE);

Aggiungi a qualsiasi URL della pagina ?debugmode=on per abilitare il debug (se è disabilitato) e ?debugmode=off per disabilitarlo

22 feb 2021 12:17:22