A apărut o eroare critică pe acest site: ce înseamnă și cum o rezolvi

Mesajul acela înseamnă că PHP a întâmpinat o eroare fatală în timp ce îți construia pagina, iar WordPress a prins-o înainte să se transforme într-un ecran alb. Eroarea este reală, specifică și înregistrată — WordPress pur și simplu refuză să o afișeze în browser, pentru că un stack trace pe o pagină publică dezvăluie căi de fișiere și cod oricui intră pe sit.

Așa că rezolvarea nu se face niciodată ghicind. Se face așa: citești eroarea reală, apoi acționezi conform a ceea ce scrie acolo.

Ce se întâmplă de fapt

Începând cu WordPress 5.2 există în nucleu un mecanism care tratează erorile fatale. Când PHP moare în mijlocul cererii, acest mecanism intervine, înlocuiește rezultatul crăpăturii cu propoziția generică și politicoasă și — dacă reușește să identifice modulul sau tema vinovată — încearcă să trimită administratorului sitului un email cu o legătură către modul de recuperare.

De aceea vezi asta în locul vechiului ecran alb al morții. Este o îmbunătățire, dar înseamnă și că informația de diagnostic este ascunsă implicit. Există două variante ale mesajului:

Ce vezi	Unde	Ce îți spune
„A apărut o eroare critică pe acest site.”	Partea publică, nautentificat	S-a produs o eroare fatală, fără alte detalii expuse
Aceeași linie plus „Află mai multe despre depanarea WordPress”	Partea publică sau wp-admin	Aceeași eroare, WordPress îți oferă pagina din manual
„…Verifică inboxul emailului de administrare pentru instrucțiuni.”	Partea publică	Mecanismul a considerat că a trimis un email de recuperare

A treia variantă este cea folositoare. Înseamnă că WordPress a atribuit crăpătura unui anumit modul sau unei anumite teme și a încercat să îți ofere o cale de intrare.

Pasul 1: verifică emailul de mod de recuperare

WordPress trimite legătura de recuperare către adresa de email de administrare a sitului — cea din Setări, General — care adesea nu este adresa cu care te autentifici. Verifică acea căsuță și verifică și spamul.

Emailul conține o legătură lungă care se termină cu ceva de genul ?action=enter_recovery_mode. Deschiderea ei te autentifică în wp-admin în mod de recuperare, unde modulul sau tema problematică este pusă în pauză și semnalată printr-o notificare roșie în partea de sus. De acolo o poți dezactiva normal.

Două precizări sincere. Prima: emailul este generat de același proces PHP care tocmai a crăpat, pe o găzduire care s-ar putea să nu aibă deloc un serviciu de trimitere a emailurilor funcțional — nelivrarea este frecventă, iar absența lui nu îți spune nimic despre eroare. A doua: legătura de recuperare expiră (implicit, cam într-o zi), așa că un email mai vechi din inbox pur și simplu s-ar putea să nu mai funcționeze; provoacă o crăpătură nouă reîncărcând situl și așteaptă un email proaspăt.

Dacă vrei ca emailul să ajungă undeva unde chiar citești, setează adresa explicit în wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Pasul 2: citește eroarea reală

Acesta este pasul care transformă un sit stricat într-o reparație de cinci minute. Adaugă aceste linii în wp-config.php, deasupra liniei care spune să nu mai editezi:

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

Faptul că WP_DEBUG_DISPLAY este pus pe false contează — ține eroarea departe de browser, dar o scrie în continuare pe disc, așa că nu expui căile de pe server vizitatorilor cât timp depanezi.

Reîncarcă o dată pagina stricată, apoi deschide wp-content/debug.log. Ultima înregistrare va arăta cam așa:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Calea fișierului este răspunsul. Dacă indică spre wp-content/plugins/, acel modul este cauza. Dacă indică spre wp-content/themes/, atunci tema este de vină — foarte des ceva lipit recent în functions.php.

Dacă debug.log nu apare, s-ar putea ca dosarul să nu fie inscriptibil sau ca un modul de securitate să fi mutat jurnalizarea în altă parte. Recurge la jurnalul de erori PHP al găzduirii — majoritatea panourilor de control au o secțiune „Error Log” sau „Logs”, iar aceeași eroare fatală va fi acolo, cu marcaj de timp.

Lipește înregistrarea în decodorul de jurnal de erori WordPress, ca să traduci formularea PHP în ce înseamnă ea practic și în ce fișier trebuie să te uiți mai întâi.

Șterge aceste linii de depanare când ai terminat. Dacă lași WP_DEBUG pornit în producție umpli discul și, dacă WP_DEBUG_DISPLAY ajunge cumva înapoi pe true, tipărești public căile de pe server.

Pasul 3: revino în wp-admin

Dacă și wp-admin este mort și nu a sosit niciun email de recuperare, dezactivează toate modulele direct de la nivelul sistemului de fișiere. Conectează-te prin SFTP (sau prin managerul de fișiere al găzduirii) și redenumește un singur dosar:

mv wp-content/plugins wp-content/plugins-off

WordPress nu mai găsește modulele, așa că le dezactivează pe toate, iar accesul la administrare revine aproape întotdeauna. Apoi:

1. Redenumește dosarul înapoi în plugins. Totul rămâne dezactivat — WordPress le-a înregistrat ca inactive.
2. Reactivează modulele unul câte unul, încărcând partea publică după fiecare.
3. Cel care aduce eroarea înapoi este vinovatul.

Dacă situl rămâne stricat cu toate modulele oprite, suspectul este tema. Redenumește dosarul temei active din wp-content/themes/, iar WordPress revine la o temă implicită, dacă există una instalată.

Cele trei cauze care merită știute

O actualizare de modul sau temă care dă eroare fatală. De departe cea mai frecventă. Jurnalul indică fișierul direct. Revino la versiunea anterioară a acelui modul sau lasă-l dezactivat și contactează dezvoltatorul, trimițându-i linia din jurnal.

O nepotrivire de versiune PHP. Găzduirile actualizează PHP după un calendar, uneori fără prea multe avertismente. Cod scris pentru PHP mai vechi poate să nu mai fie interpretat deloc pe o versiune nouă. Semnul este că nu ai schimbat nimic la tine și totul s-a stricat dintr-odată. Revenirea cu o versiune minoră de PHP din panoul de găzduire este un diagnostic valid — dar tratează asta ca pe timp câștigat, nu ca pe o rezolvare. Versiunile vechi de PHP nu mai primesc actualizări de securitate.

Memorie epuizată. Jurnalul spune „Allowed memory size of X bytes exhausted”. Creșterea limitei în wp-config.php este rezonabilă:

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

Fii sincer cu privire la ce face asta: ridică plafonul, dar nu rezolvă ce anume a consumat 256MB pentru randarea unei singure pagini. Dacă limita trebuie mărită mereu, ceva — de obicei un import, un constructor de pagini sau o interogare prost scrisă — este problema reală.

Sfaturi pe care le poți ignora liniștit

„Mărește pur și simplu limita de memorie.” Relevant doar dacă jurnalul chiar spune că memoria s-a epuizat. Altfel nu schimbă nimic și maschează faptul că nu ai citit niciodată eroarea.

„Reinstalează nucleul WordPress.” Fișierele de nucleu sunt rareori cauza, iar înlocuirea lor consumă timp pe care l-ai putea folosi ca să citești o singură linie din jurnal.

„Dezactivează mecanismul pentru erori fatale.” Există o constantă care îl oprește, iar rezultatul este că eroarea brută se tipărește pe situl tău public în loc să fie interceptată. Asta expune căile de fișiere vizitatorilor. Folosește în schimb WP_DEBUG_LOG cu WP_DEBUG_DISPLAY oprit — aceeași informație, fără expunere.

„Golește memoria cache.” O eroare fatală se produce în PHP înainte ca un modul de cache să poată servi ceva. Dacă se servește o copie din cache a paginii de eroare, golirea ajută după ce ai rezolvat cauza — niciodată în locul rezolvării.

Tot blocat?

Dacă jurnalul indică un fișier din nucleu și nu ceva din wp-content, explicația mai probabilă este un modul încărcat mai devreme care a stricat starea pe care se bazează nucleul, nu un nucleu corupt. Oprește totul prin redenumirea dosarului, confirmă că situl se încarcă curat, apoi reintrodu modulele unul câte unul — ultimul pe care îl activezi înainte ca eroarea să revină este cel de raportat, cu linia din jurnal atașată.