Ecranul alb al morții în WordPress, explicat

Ecranul alb al morții este o eroare fatală PHP pe care nu o poți vedea. WordPress a întâmpinat o eroare irecuperabilă în timpul randării, PHP s-a oprit, iar pentru că afișarea erorilor este dezactivată pe serverele de producție, pagina s-a întors goală în loc să afișeze motivul. Rezolvarea aproape niciodată nu ține de ghicit: activează jurnalul de depanare, deschide wp-content/debug.log și citește ultima linie fatală. Ea numește exact fișierul — aproape întotdeauna un plugin sau o temă — iar acea singură linie reprezintă întreaga reparație.

De ce este ecranul gol

PHP are o setare numită display_errors. Pe o mașină de dezvoltare este de obicei activată, așa că o eroare fatală afișează pe ecran un stack trace. Pe un server real este dezactivată în mod implicit, pentru că expunerea căilor de fișiere și a erorilor către vizitatori este o problemă de securitate. Așadar, când ceva declanșează o eroare fatală — un apel către o funcție care nu mai există, o clasă care nu este încărcată, o eroare de sintaxă într-o actualizare de plugin — PHP moare și nu trimite nimic. Browserul tău randează un document gol. Acesta este „ecranul alb”.

Începând cu WordPress 5.2 există un handler pentru erori fatale (WP_Fatal_Error_Handler) care încearcă să le prindă. Când funcționează, nu primești o pagină goală — primești „A apărut o eroare critică pe acest site web”, plus un email către adresa administratorului care conține adesea eroarea propriu-zisă și un link către Modul de recuperare. Un ecran cu adevărat gol înseamnă de obicei că eroarea s-a produs înainte ca acel handler să poată rula: o eroare de parsare/sintaxă (prinsă la compilare), un must-use plugin defect sau o eroare fatală în functions.php-ul temei active. În oricare dintre cazuri, cauza este scrisă undeva. Trebuie doar să activezi scrierea.

Rezolvă problema, pas cu pas

1. Activează jurnalul. Editează wp-config.php prin SFTP și adaugă acest cod deasupra liniei /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY setat pe false ține erorile departe de pagina publică, în timp ce WP_DEBUG_LOG le scrie în wp-content/debug.log. Reîncarcă o dată pagina defectă pentru a genera o intrare nouă.

2. Citește ultima eroare fatală. Deschide wp-content/debug.log și uită-te la final:

tail -n 30 wp-content/debug.log

Cauți o linie de felul acesta:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Calea numește vinovatul: plugins/some-addon. Acesta este răspunsul tău. Dacă trace-ul este lung sau mesajul este criptic (Allowed memory size exhausted, Cannot redeclare, un nume de clasă pe care nu îl recunoști), lipește-l în decodorul nostru de jurnale de erori — elimină zgomotul, îți spune către ce plugin sau temă indică calea și explică ce înseamnă tipul specific de eroare.

3. Dezactivează componenta numită. Nu poți accesa /wp-admin, așa că fă-o prin SFTP. Redenumește folderul pluginului problematic, de exemplu some-addon → some-addon.off. WordPress nu poate încărca un folder pe care nu îl găsește, așa că dezactivează pluginul și site-ul revine. Dacă jurnalul indică tema ta, comută la o temă implicită redenumind folderul temei active — WordPress revine la o temă twentytwentysomething inclusă.

4. Dacă jurnalul nu se scrie, înseamnă că wp-content nu poate fi scris sau eroarea este la nivelul serverului. Verifică în schimb jurnalul de erori PHP al serverului:

find . -name "error_log" -newermt "-1 hour"

Aceeași informație, alt fișier. Stivele cPanel/Apache lasă adesea un error_log în rădăcina site-ului sau în directorul care eșuează.

Ce să nu faci

Nu crește pur și simplu limita de memorie. Cel mai repetat sfat online este să ridici WP_MEMORY_LIMIT la 256M sau 512M. Asta rezolvă WSOD-ul doar dacă jurnalul spune efectiv Allowed memory size of N bytes exhausted. Dacă eroarea este Call to undefined function, mai multă memorie nu face nimic — ai schimbat o setare la întâmplare și ecranul e tot alb. Citește jurnalul mai întâi, apoi crește memoria doar dacă memoria este problema declarată.

Nu goli cache-ul și nu numi asta diagnostic. Ecranul alb înseamnă că PHP moare pe server înainte să existe vreun HTML. Un fișier din cache învechit nu poate cauza un document gol. (Un plugin de caching defect poate — dar jurnalul îl va numi, ceea ce este esențial.)

Nu edita și nu reinstala nucleul WordPress. Eroarea fatală aproape niciodată nu este în wp-includes sau wp-admin; este în pluginul sau tema pe care le indică jurnalul. Reinstalarea nucleului este lentă, riscantă și tratează un simptom pe care nu l-ai confirmat.

Nu dezactiva toate pluginurile pentru a le reactiva pe rând, la întâmplare. Bisecția funcționează, dar este calea lentă. Jurnalul îți spune folderul exact dintr-un singur pas. Recurge la metoda „oprește tot” doar când nu există nicio eroare lizibilă.

Nu lăsa display_errors activat în producție. Odată ce site-ul revine, elimină definiile de depanare (sau setează WP_DEBUG înapoi pe false). Erorile afișate vizitatorilor îți expun căile.

Tot blocat?

Dacă jurnalul numește un plugin, dar dezactivarea lui nu curăță ecranul, există o a doua eroare fatală sub prima — reactivează jurnalul și citește noua ultimă linie; erorile fatale se stivuiesc. Dacă mesajul în sine este obstacolul, aruncă-l în decodorul de jurnale de erori și lasă-l să îți traducă tipul erorii și calea fișierului. Ecranul alb rămâne un mister doar cât timp jurnalul este dezactivat.