Definește WP_DEBUG condițional / doar pentru administratori / logare erori (adăugare parametru query pentru toate link-urile?)
Dezvolt un site pe un server la care și clientul are acces și aș dori să afișez WP_DEBUG
doar pentru administratori. Referindu-mă la articolul Yoast despre o soluție pentru aceasta:
if ( isset($_GET['debug']) && $_GET['debug'] == 'true')
define('WP_DEBUG', true);
ar afișa WP_DEBUG
doar pentru URL-urile care au atașat ?debug=true
, cum ar fi http://domain.com/?debug=true
Mă gândeam că Debug Bar ar putea conține unele dintre aceste informații în mod implicit (dacă WP_DEBUG
este activat sau nu), dar cred că eram prea optimist deoarece nu cred că este cazul.
Așadar, m-am gândit că ar fi util să verific utilizatorul curent (având capacitatea manage_options
și apoi să procesez link-urile prin add_query_arg()
:
function zs_admin_debug() {
if (!current_user_can('manage_options')) {
add_query_arg('debug','true');
}
}
dar ceea ce nu sunt sigur este - există vreun hook pe care îl pot folosi pentru a afecta toate link-urile de pe un site cu aceasta? În acest fel, administratorii vor vedea întotdeauna debug-ul, ceea ce m-am gândit că ar fi extrem de util. Mulțumesc pentru orice ajutor ca întotdeauna!
Nu cred că există un hook universal pentru URL-uri. Există multe hook-uri și poate mi-a scăpat unul, dar nu cred că există unul universal. Poți să verifici hook-urile la adambrown.info. Există multe hook-uri pentru URL-uri, dar nu unul universal.
Dacă îmi permiți să sugerez o altă soluție: înregistrează erorile într-un fișier.
/**
* Acest cod va înregistra toate erorile, notificările și avertismentele într-un fișier numit debug.log
* în directorul wp-content (dacă Apache nu are permisiuni de scriere, poate fi necesar să creezi
* fișierul manual și să setezi permisiunile corespunzătoare (de exemplu, folosește 666))
*/
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
Acest cod este preluat direct din Codex pentru fișierul wp-config.php. Dacă faci asta, nu va trebui să te mai îngrijorezi de manipularea $_GET
sau de filtrarea utilizatorilor admin.
Edit:
Am uitat o posibilă soluție. Poți face asta cu Javascript. Un scurt script poate atașa parametrul tău la toate URL-urile de pe pagină și poți încărca scriptul doar pentru administratori destul de ușor.
Totuși, aș sugera în continuare soluția cu 'log' deoarece erorile tuturor sunt înregistrate. Dacă oamenii tăi sunt ca ai mei și trimit rapoarte de erori gen "hei, site-ul nu merge când completezi formularul ăla", vei aprecia fișierul de log. :)

Presupun că m-am obișnuit să le văd pe ecran :) dar un fișier log are mai mult sens aici. O să mai cercetez puțin, dar aceasta pare cea mai bună soluție pe care am găsit-o până acum. Mulțumesc!

Rețineți că logarea nativă este hardcodată să scrie într-un fișier accesibil pe web, ceea ce nu este o idee bună în producție. Este mai bine să configurați o locație privată (în afara folderului web) pentru fișierul de log prin mijloace PHP, pentru site-urile live.

Chiar dacă prima mea abordare a fost sortită eșecului și răspunsul lui s_ha_dum este o soluție curată și, probabil, cea mai bună, permiteți-mi să ofer încă un scenariu funcțional:
Următorul cod setează un cookie care este valabil pentru următoarele 24 de ore (86400 de secunde) atunci când un administrator se autentifică în sistem. În wp-config.php, constanta WP_DEBUG
este definită condiționat în funcție de prezența și valoarea acestui cookie.
Atenție: WP_DEBUG
va fi apoi setat la true
pentru toți utilizatorii care se autentifică din același browser pe aceeași mașină în aceeași zi.
în functions.php (sau ca plugin):
function wpse_69549_admin_debug( $user_login, $user )
{
if ( in_array( 'administrator', $user->roles ) ) {
setcookie( 'wp_debug', 'on', time() + 86400, '/', get_site_option( 'siteurl' ) );
}
}
add_action( 'wp_login', 'wpse_69549_admin_debug', 10, 2 );
Vezi: Codex > Action Reference > wp_login
în wp-config.php:
if ( isset( $_COOKIE['wp_debug'] ) && 'on' === $_COOKIE['wp_debug'] ) {
define( 'WP_DEBUG', true );
} else {
define( 'WP_DEBUG', false );
}

Andrew Nacin a comentat acel articol, menționând că init
este prea târziu pentru a avea vreun efect. Am încercat și eu acest lucru și nu a funcționat.

Constantele nu pot fi redefinite. S-ar putea modifica nivelul de raportare a erorilor fără a atinge constanta, dar nu este perfect. De asemenea, se întâmplă multe înainte de init
care sunt de interes.

Cred că răspunsul acceptat rămâne cea mai viabilă soluție, totuși, pentru a fi complet, această nouă abordare ar trebui să facă treaba cu notificările de depanare pe ecran.

@s_ha_dum: Nu e ca și cum îți amintești fiecare răspuns - eu cel puțin nu (am căutat în Google propriul răspuns înainte). Pe acesta îl țiu minte însă. Am fost primul care a răspuns și scrisesem prostii absolute. Nu se aplica deloc. Am o politică să nu răspund decât dacă sunt cel puțin 99.5% sigur că sunt calificat (presupun că la fel e și la tine) - aici greșisem complet. Asta m-a enervat maxim, așa că câteva ore mai târziu, după ce primise deja un răspuns acceptat, tot mă mai gândeam la asta și am venit cu soluția de mai sus. Și eu cred că e destul de elegantă - mersi că ai observat.

Nu răspunde exact la întrebarea ta, dar din experiența personală am aflat că este mai bine să activezi modul de depanare prin potrivirea adresei IP în loc de URL.
Aceasta necesită modificarea link-urilor și rezolvă problema identificării administratorului înainte ca WordPress să încarce funcționalitățile necesare utilizatorului.

De fapt, și mie îmi place această idee - deci dacă aș face ceva de genul http://pastebin.com/m22KNakh ar putea... teoretic să funcționeze, corect? Executând echo $_SERVER['REMOTE_ADDR']
returnează ::1
ceea ce este de așteptat pe localhost? Sincer, sună ca un fișier de log separat și în acest fel (având în vedere că IP-urile de acasă par să se schimbe mereu) ar putea fi o idee bună.

@Zach da, ::1
este doar versiunea IPv6 a lui 127.0.0.1
. IP-ul dinamic face lucrurile mai puțin convenabile, dar oricum consider asta doar ca o tehnică temporară de depanare pentru mediul live. Nu înlocuiește o configurație adecvată de depanare locală.

Dacă ai o adresă IP statică, poți face asta:
if ('ADRESA_TA_IP' == $_SERVER['REMOTE_ADDR']) {
define('WP_DEBUG', true);
} else {
define('WP_DEBUG', false);
}
Sursa: DEBUGGING ÎN WORDPRESS – CUM SĂ FOLOSEȘTI WP_DEBUG PE UN SITE DE PRODUCȚIE

Aceasta este de asemenea o posibilă soluție, dar trebuie să adaugi acest cod în fișierul tău wp-config.php
deoarece WP_DEBUG
este definit acolo:
if ( isset( $_GET['debugsecret'] ) && 'debugsecret' == $_GET['debugsecret'] ) {
define( 'WP_DEBUG', true );
}
Adaugă ?debugsecret=debugsecret
la URL-ul paginii pe care dorești să o depanezi.

Pentru a adăuga încă o opțiune, am creat o combinație din mai multe răspunsuri. Aceasta vă permite să schimbați instantaneu starea modului de depanare (activat/dezactivat) pentru o oră cu un parametru URL și, de asemenea, să restricționați cine poate face modificarea după IP.
Înlocuiți linia WP_DEBUG din wp-config.php cu aceasta:
//Setează modul implicit de depanare. De obicei ar trebui să fie false
$CURRENT_DEBUG_MODE=false;
//decomentează pentru a seta o restricție după IP.
//$DEVEL_IP_ADDRESS = 'ADRESA TA IP';
//folosește cookie pentru a seta modul de depanare pentru 1 oră cu parametrul 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);
Adăugați la orice URL pagină ?debugmode=on
pentru a activa depanarea (dacă este dezactivată) și ?debugmode=off
pentru a o dezactiva
