Pagină albă sau eroare critică în WordPress: citiți mai întâi eroarea

„Eroare critică” sau pagină albă: aceeași defecțiune

O pagină albă este de cele mai multe ori o eroare fatală PHP: un fișier al site-ului a cerut ceva imposibil, iar execuția s-a oprit înainte de a afișa ceva. Începând cu WordPress 5.2, WordPress interceptează aceste erori: în locul unei pagini goale, afișează „A fost o eroare critică pe acest site web.” și trimite un e-mail la adresa de administrare a site-ului.

Pagina rămâne complet albă în câteva cazuri: o versiune mai veche a WordPress, o eroare apărută înainte de încărcarea acestui mecanism, constanta WP_DISABLE_FATAL_ERROR_HANDLER setată la true sau un modul de cache care servește o pagină goală salvată în timpul defecțiunii. Metoda de mai jos se aplică tuturor acestor cazuri.

Trei gesturi pot aștepta până după citirea erorii: reinstalarea WordPress, ștergerea modulelor, restaurarea unei copii de rezervă vechi. Fiecare poate șterge setări sau date recente, în timp ce mesajul de eroare spune de obicei ce componentă trebuie dezactivată, fără nicio pierdere.

Scurtătura: modul recuperare

Când WordPress interceptează eroarea, trimite la adresa de e-mail de administrare a site-ului un mesaj cu subiectul „[Numele site-ului] Site-ul tău se confruntă cu o problemă tehnică”. Mesajul numește modulul sau tema în cauză și conține un link care deschide administrarea în modul recuperare.

• În acest mod, componenta defectă este pusă pe pauză numai pentru dumneavoastră: vizitatorii văd în continuare eroarea.
• Din Module sau din Aspect > Teme, dezactivați componenta semnalată, apoi dați clic pe „Ieși din modul recuperare” în bara de administrare.
• Linkul rămâne valabil 24 de ore, iar WordPress trimite cel mult un e-mail de acest tip pe zi. Dacă e-mailul nu sosește, uitați-vă în dosarul de spam, apoi treceți la metoda următoare.

Citiți eroarea: jurnalul de depanare

Conectați-vă la site prin SFTP sau prin managerul de fișiere al furnizorului de găzduire, deschideți wp-config.php la rădăcină și înlocuiți rândul define( 'WP_DEBUG', false ); cu aceste patru rânduri:

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

Ele se pun deasupra comentariului care încheie zona modificabilă a fișierului (/* That's all, stop editing! Happy publishing. */, în engleză și într-un WordPress instalat în limba română). Reîncărcați pagina cu eroare, apoi deschideți wp-content/debug.log. WP_DEBUG_DISPLAY setat la false păstrează mesajele în fișier, în afara paginii pe care o văd vizitatorii.

Dacă debug.log rămâne gol sau nu apare, eroarea a fost înregistrată direct de PHP: căutați un fișier error_log la rădăcina site-ului sau în wp-admin, ori secțiunea de jurnale de erori din panoul furnizorului de găzduire.

Ce spune mesajul și gestul potrivit

O eroare fatală încape într-un rând: tipul erorii, descrierea ei, apoi in urmat de calea completă a fișierului și de numărul rândului. Calea este informația cea mai utilă: wp-content/plugins/nume/ desemnează un modul, wp-content/themes/nume/ o temă.

define( 'WP_MEMORY_LIMIT', '256M' );

Dezactivați componenta în cauză fără administrare

Prin SFTP sau prin managerul de fișiere

Redenumiți dosarul modulului numit în mesaj, de exemplu wp-content/plugins/nume-modul în nume-modul.off. WordPress nu mai găsește modulul și nu îl mai încarcă; setările lui rămân salvate în baza de date, iar WordPress îl dezactivează la următoarea deschidere a ecranului de module.

Pentru o temă, redenumirea dosarului ei din wp-content/themes face din nou accesibilă administrarea, însă vizitatorii văd o pagină goală până când o temă devine activă. Deschideți imediat Aspect > Teme: WordPress constată că tema activă este stricată și revine la o temă implicită instalată.

Cu WP-CLI

wp plugin list --status=active
wp plugin deactivate nume-modul
wp theme list
wp theme activate twentytwentyfive

Prima comandă păstrează lista modulelor active, utilă înaintea oricărei dezactivări în grup. Dacă WP-CLI se oprește el însuși din cauza erorii, adăugați --skip-plugins --skip-themes la comandă: pornește atunci fără să încarce modulele și tema. Modulele din dosarul wp-content/mu-plugins se încarcă totuși; dacă eroarea vine de la unul dintre ele, redenumiți-i fișierul.

Când mesajul nu desemnează nicio componentă, wp plugin deactivate --all dezactivează toate modulele. Dacă site-ul revine, reactivați-le unul câte unul, reîncărcând site-ul după fiecare: ultimul reactivat înainte de revenirea erorii este cel căutat.

După ce site-ul a revenit

1. Puneți la loc define( 'WP_DEBUG', false ); și eliminați WP_DEBUG_LOG din wp-config.php.
2. Ștergeți wp-content/debug.log: aflat într-un dosar accesibil de pe web, poate fi citit de oricine și conține căi ale serverului.
3. Actualizați sau înlocuiți componenta în cauză, citindu-i jurnalul de modificări.
4. Goliți memoria cache a modulului de cache și pe cea a furnizorului de găzduire, dacă oferă una.
5. Pentru data viitoare: testați actualizările pe o copie a site-ului înainte de a le aplica pe site-ul public.