Cum repari editorul de blocuri WordPress care nu se încarcă

De cele mai multe ori, un editor de blocuri WordPress care nu se încarcă este o eroare JavaScript — un singur script defect de la un plugin sau o temă oprește întreaga aplicație React, iar editorul nu se mai afișează complet. Deschide consola de dezvoltare a browserului (F12 sau Cmd+Option+I pe Mac), reîncarcă ecranul de editare și citește eroarea afișată cu roșu. Aproape întotdeauna indică fișierul care a generat eroarea. Acea singură linie îți arată ce plugin trebuie dezactivat și, de obicei, poți reveni la scris în mai puțin de cinci minute. Reinstalarea WordPress, creșterea limitei de memorie PHP și trecerea la Editorul Clasic sunt cele mai frecvente trei sugestii de pe internet și, de regulă, toate trei sunt soluții greșite.

De ce se strică editorul așa cum se strică

Editorul de blocuri (Gutenberg) este o aplicație React de tip single-page care rulează în interiorul wp-admin/post.php și post-new.php. WordPress încarcă un set de pachete de scripturi — wp-blocks, wp-element, wp-editor, wp-edit-post — iar aplicația pornește prin wp.domReady(). JavaScript se oprește din executare la prima excepție netratată. Așadar, dacă vreunul dintre scripturile încărcate generează o eroare în timp ce editorul se inițializează, tot ce urmează după el moare odată cu el. Zona ta de scriere, redactată cu grijă, se transformă într-un panou alb gol sau în mesajul „Editorul a întâmpinat o eroare neașteptată”.

În mod implicit, WordPress concatenează și scripturile din zona de administrare în mai puține cereri. Asta înseamnă că JavaScript-ul defect al unui singur plugin poate trage în jos scripturi fără legătură, încărcate în același bundle, motiv pentru care vinovatul nu este mereu evident doar din comportament. Consola, în schimb, îl arată.

Al doilea tip de eroare arată diferit: editorul se încarcă, dar la salvare apare „Actualizarea a eșuat. Răspunsul nu este un răspuns JSON valid.” Aceasta nu este o problemă de JavaScript. Editorul comunică cu REST API la /wp-json/wp/v2/ și așteaptă înapoi un JSON curat. Dacă un plugin sau fișierul functions.php al temei tale generează o notificare, un avertisment sau o eroare fatală PHP înainte de JSON — sau dacă un plugin de securitate blochează ruta REST, ori un plugin de redirecționare rescrie URL-ul — răspunsul este alterat, iar editorul nu îl poate interpreta.

Cum îl repari, de la cel mai rapid la cel mai lent

1. Citește consola. Reproduce eroarea cu DevTools deschis. O eroare de tipul Uncaught TypeError ... some-plugin/build/index.js indică direct pluginul problematic. Acest singur pas rezolvă majoritatea cazurilor și te scutește de dezactivări la întâmplare.

2. Exclude browserul. Fă un hard-refresh (Cmd/Ctrl+Shift+R), apoi încearcă o fereastră incognito cu extensiile dezactivate. Ad blockerele și extensiile de confidențialitate elimină ocazional scripturi din administrare. Dacă funcționează în incognito, problema este o extensie de browser sau cache-ul învechit, nu site-ul tău.

3. Verifică direct REST API dacă ai văzut mesajul „nu este un răspuns JSON valid”. Accesează https://yoursite.com/wp-json/ într-un browser. Ar trebui să primești un perete de JSON. Dacă primești HTML, o eroare 500 sau o redirecționare către autentificare, aceea este problema ta — un plugin strică răspunsul REST, nu editorul în sine.

4. Dezactivează pluginurile pe rând. Dezactivează-le pe toate, confirmă că editorul se încarcă, apoi reactivează-le câte unul până când se strică din nou. Dacă ești blocat complet în afara wp-admin, fă asta prin SFTP redenumind folderul:

mv wp-content/plugins wp-content/plugins_off

WordPress dezactivează totul când folderul dispare. Redenumește-l la loc, apoi mută pluginurile înăuntru și în afară individual.

5. Testează tema. Comută la Twenty Twenty-Four. O temă care încarcă JavaScript defect pentru editor sau generează erori PHP în functions.php produce aceleași simptome.

6. Activează jurnalul și citește eroarea reală. Mai ales pentru erorile de tip REST/JSON, activează depanarea în wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Eroarea fatală se scrie în wp-content/debug.log cu fișierul și numărul liniei exacte. Dacă acel stack trace este dens — nume de clase cu namespace, lanțuri de require, o eroare fatală îngropată sub zece linii de urmărire — lipește-l în decodorul nostru pentru jurnalul de erori WordPress ca să vezi, pe înțeles, care plugin și care linie au declanșat-o de fapt. Aceasta este diferența dintre „ceva este stricat” și „linia 214 din acest plugin anume este stricată”.

Dacă bănuiești că concatenarea scripturilor maschează adevăratul vinovat, forțează încărcarea separată a fiecărui script, astfel încât eroarea din consolă să indice exact un singur fișier:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Ce să nu faci

Nu instala pluginul Editor Clasic și să declari problema rezolvată. Nu repară nimic — doar ascunde editorul de blocuri ca să nu mai vezi eroarea. JavaScript-ul defect sau răspunsul REST stricat sunt tot acolo și te vor lovi din nou în editorul de site, în widgeturi sau la următoarea actualizare. Diagnostichează întâi; revino la Editorul Clasic doar dacă ai luat o decizie deliberată de a renunța la blocuri.

Nu crește limita de memorie PHP din reflex. Este soluția preferată de copy-paste de pe internet, dar un editor gol este rareori epuizare de memorie. Epuizarea reală generează o eroare fatală specifică — „Allowed memory size of N bytes exhausted” — pe care o vei vedea în debug.log. Dacă acea linie nu este acolo, mai multă memorie nu schimbă nimic.

Nu reinstala nucleul WordPress. Fișierele de nucleu sunt identice octet cu octet pe fiecare instalare. Dacă nucleul ar fi problema, orice site WordPress de pe planetă ar avea acum un editor stricat. Vina este aproape întotdeauna la pluginuri sau la temă, iar reinstalarea nucleului riscă să suprascrie lucruri fără să repare nimic.

Nu goli și nu dezactiva orbește pluginul de cache ca prim pas. Minificarea și concatenarea agresivă a JS pot strica editorul, așa că merită testat — dar verifică consola înainte să te apuci să golești cache-uri la întâmplare. Ghicitul este modul prin care o reparație de cinci minute se transformă într-o după-amiază pierdută.

Tot blocat?

Dacă consola este curată, REST API returnează JSON valid și un test complet de dezactivare a pluginurilor și temelor lasă totuși editorul mort, răspunsul se află aproape întotdeauna în debug.log. Activează WP_DEBUG_LOG, reproduce eroarea o dată și trece eroarea fatală rezultată prin decodorul pentru jurnalul de erori. Stack trace-ul indică fișierul — pornește de acolo.