Unde se află debug.log în WordPress și cum îl muți în alt loc

WordPress își scrie implicit jurnalul de depanare în wp-content/debug.log — pe disc, o cale absolută de forma /path/to/your/site/wp-content/debug.log. Fișierul nu există până când nu se înregistrează efectiv ceva, iar scrierea are loc doar când WP_DEBUG este true și WP_DEBUG_LOG este activat în wp-config.php. Locația implicită este și o problemă reală de securitate, pentru că pe majoritatea găzduirilor oricine o poate deschide direct în browser.

Cele trei constante și ce face fiecare

Toate trei se pun în wp-config.php, deasupra liniei care spune /* That's all, stop editing! Happy blogging. */. Orice adaugi sub acea linie rulează după ce WordPress a pornit deja și este ignorat.

Constantă	Implicit	Ce face
WP_DEBUG	false	Comutatorul principal. Ridică nivelul de raportare a erorilor PHP ca să arate notificări, avertismente și funcții învechite. Nimic altceva din listă nu funcționează fără el.
WP_DEBUG_LOG	false	Trimite erorile într-un fișier. true înseamnă wp-content/debug.log. Un șir de caractere este tratat drept calea fișierului în care se scrie.
WP_DEBUG_DISPLAY	true	Tipărește erorile în codul HTML al paginii, vizibile pentru orice vizitator.

Dependența este partea pe care oamenii o greșesc. WP_DEBUG_LOG este citit în interiorul ramurii WP_DEBUG din codul de pornire al WordPress. Dacă WP_DEBUG este false, setarea lui WP_DEBUG_LOG pe true nu face absolut nimic — niciun fișier, nicio eroare, niciun avertisment. Dacă ai adăugat WP_DEBUG_LOG și nu a apărut niciun jurnal, verifică întâi WP_DEBUG.

O configurație funcțională pentru un sit live:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Dacă WP_DEBUG este deja definit mai sus în fișier — de obicei este, setat pe false — modifică acea linie existentă în loc să adaugi un al doilea define(). Definirea aceleiași constante de două ori aruncă un avertisment PHP care, pe un sit cu afișarea pornită, ajunge chiar în capul paginii.

De ce WP_DEBUG_DISPLAY trebuie să fie false în producție

Cu afișarea pornită, erorile PHP sunt scrise în răspunsul HTML. O singură notificare despre o funcție învechită dintr-o temă îi arată fiecărui vizitator calea absolută din sistemul de fișiere al serverului. O eroare de bază de date afișează nume de tabele și fragmente de interogări. Mai rău, orice text emis înainte de trimiterea antetelor strică redirecționările, strică răspunsurile REST și AJAX care așteaptă JSON curat și poate produce ecranul alb pe care oamenii îl pun apoi pe seama unui modul.

O subtilitate care merită știută: setarea lui WP_DEBUG_DISPLAY pe null nu este același lucru cu false. null îi spune WordPress să lase în pace setarea display_errors din PHP și să moștenească ce are configurat serverul. false o dezactivează activ. Pe un sit de producție, folosește false și adaugă linia ini_set de mai sus ca măsură suplimentară, pentru că un modul poate reactiva display_errors mai târziu în cadrul cererii.

Locația implicită poate fi descărcată public

wp-content/debug.log se află în rădăcina web. Nimic dintr-o instalare standard de WordPress nu blochează cererile directe către el. Pe o configurație tipică Apache sau nginx, https://situltau.ro/wp-content/debug.log returnează fișierul ca text simplu. Jurnalele de depanare conțin căi absolute de pe server, detalii interne din module și teme, erori de bază de date cu textul real al interogărilor și uneori valori transmise prin funcții care au eșuat. Este informație gratuită pentru oricine ghicește URL-ul — și este unul dintre primele URL-uri pe care le încearcă scanerele automate.

Sunt două moduri de a rezolva asta. Cel mai bun este să muți jurnalul.

Mută jurnalul folosind o cale

Începând cu WordPress 5.1, WP_DEBUG_LOG acceptă o cale de fișier sub formă de șir de caractere în loc de o valoare booleană. Îndreapt-o undeva în afara rădăcinii documentelor:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Trei reguli pentru acea cale. Folosește o cale absolută — una relativă este rezolvată față de dosarul de lucru al PHP, care variază de la o cerere la alta și de la un server la altul, așa că vei pierde urma fișierului. Dosarul trebuie să existe deja; PHP nu îl creează, iar dacă nu poate deschide fișierul eșuează în tăcere. Și dosarul trebuie să fie inscriptibil de utilizatorul PHP, care pe găzduire partajată nu este același cont cu care te conectezi prin SFTP.

Dacă găzduirea te ține închis în rădăcina web și nu ai unde scrie deasupra ei, păstrează calea implicită și blochează accesul la nivel de server. Pentru Apache:

<Files "debug.log">
  Require all denied
</Files>

Asta merge într-un fișier .htaccess din interiorul wp-content, nu în cel din rădăcină — WordPress rescrie fișierul .htaccess din rădăcină când salvezi legăturile permanente și îți poate șterge adăugarea. Pe nginx, .htaccess nu face absolut nimic; ai nevoie de un bloc location în configurația serverului, ceea ce pe găzduire administrată înseamnă de obicei să ceri ajutorul suportului.

Fii sincer în privința a ceea ce obții prin blocare: fișierul este în continuare pe disc, într-un dosar servit de serverul web. O vulnerabilitate de traversare a căilor din orice modul îl poate citi în continuare. Mutarea lui în afara rădăcinii web este soluția mai solidă.

Cum citești și urmărești fișierul

Prin SSH, urmărește-l în timp real cât reproduci problema:

tail -f wp-content/debug.log

Reproduce eroarea în altă filă, iar liniile noi apar pe măsură ce sunt scrise. Ca să vezi doar ce s-a întâmplat recent sau ca să filtrezi după un singur modul:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP adaugă la sfârșitul fișierului, deci citește de jos în sus. Fiecare intrare are marcaj de timp în UTC, care nu se va potrivi cu fusul orar setat în WordPress — nu te lăsa păcălit să crezi că te uiți la intrări vechi.

Cu WP-CLI poți comuta constantele fără să editezi fișierul manual:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Opțiunea --raw contează — fără ea, valoarea este scrisă ca șirul "true", nu ca valoare booleană. Pentru varianta cu cale, renunță la --raw, ca valoarea să fie scrisă ca șir între ghilimele.

Nu ai SSH? Descarcă fișierul prin SFTP sau deschide-l în managerul de fișiere al găzduirii. Evită modulele care afișează jurnalul în wp-admin, dacă nu ai încredere deplină în ele; îi dai practic unui modul acces de citire la un fișier plin de detalii interne despre server.

Dacă vrei blocul exact de wp-config pentru configurația ta, inclusiv o cale sigură în afara rădăcinii și regula de server potrivită, generatorul de jurnal de depanare WordPress ți-l construiește.

Oprește-l când ai terminat

Nimic din nucleul WordPress nu rotește și nu golește debug.log. Pe un sit care aruncă o notificare la fiecare încărcare de pagină, fișierul crește fără limită și poate umple discul — ceea ce pune situl la pământ mai rău decât eroarea pe care o urmăreai. Pornește jurnalizarea, reproduce problema, citește jurnalul, apoi pune WP_DEBUG înapoi pe false.

Ca să golești fișierul fără să îl ștergi:

: > wp-content/debug.log

Când jurnalul rămâne gol

Verifică următoarele, în ordine. WP_DEBUG este false — cea mai frecventă cauză și cea care dezactivează în tăcere tot restul. Constanta este sub linia „stop editing” din wp-config.php. Permisiunile fișierelor — PHP nu poate scrie în wp-content sau în dosarul personalizat pe care l-ai indicat. O eroare fatală apărută înainte ca wp-config să se încarce complet, cum ar fi o greșeală de sintaxă chiar în fișierul de configurare, se produce prea devreme ca jurnalizarea WordPress să o prindă; astfel de erori ajung în jurnalul propriu de erori PHP al serverului. Găzduirea o suprascrie — unele platforme administrate fixează setarea error_log din PHP sau direcționează jurnalizarea către panoul lor propriu, caz în care constantele tale sunt corecte, iar rezultatul este pur și simplu în altă parte. Verifică vizualizatorul de jurnale al găzduirii înainte să presupui că ai configurația stricată.