Ecranul alb al morții WordPress: un ghid pentru recuperare

WordPress, precum MacOS și chiar și Windows acum, are un infam „Ecran alb al morții” sau „WSOD” pe scurt. WSOD apare atunci când ceva nu merge prost. Te confrunți cu un ecran alb gol sau în mare parte gol din motive necunoscute. Acum ce?

Ce este WordPress White Screen of Death (WSOD)?

Este puțin probabil să întâlniți „Ecranul alb al morții” (WSOD) pe un site WordPress în condiții normale. Este pur și simplu un ecran alb gol care apare în loc de interfața publică front-end sau back-end a unui site WordPress. Înseamnă că WordPress s-a prăbușit și nu se va încărca corect.

De ce? Ce a mers prost?

De când WordPress 5.2 a fost lansat în mai 2019, WordPress a avut un mod de recuperare pentru a vă proteja de WSOD. Fără modul de recuperare, problemele de compatibilitate ar genera o mulțime de WSOD și utilizatorii WordPress frustrați. Dacă serverul dvs. utilizează o versiune de PHP sau MySQL care nu este acceptată de un plugin, o temă sau o extensie pe care o instalați, în loc să vă distrugeți site-ul, veți obține Modul de recuperare. Astăzi, o eroare PHP Out-of-Memory (OOM) este probabil cel mai comun scenariu rămas care va ocoli protecția WSOD, lăsându-vă cu un ecran complet gol.

Am verificat cu colaboratorul principal WordPress, Marius Jensen, pentru a afla ce altceva ar putea provoca un adevărat WSOD în zilele noastre. Marius este autorul pluginului Site Health (acum Health Check and Troubleshooting) al cărui concept și caracteristici au intrat în cele din urmă în nucleul WordPress. (Așa am obținut modul de recuperare și alte protecții.) Marius a confirmat că singura modalitate de a face ca WordPress să se blocheze cu un ecran complet gol este întreruperea fluxului de execuție al PHP, astfel încât gestionarea erorilor fatale să nu poată funcționa așa cum ar trebui. Întreruperea conexiunii dintre PHP și serverul dvs. HTTP va realiza acest lucru. Nu veți primi feedback de depanare pe ecran. Ar fi frustrant, dar dacă pur și simplu lucrați în WordPress, instalând și configurați pluginuri, este puțin probabil să se întâmple acest lucru.

Ecranul alb al morții înseamnă că WordPress a fost piratat?

Nu, un WSOD nu înseamnă că băieții răi te-au prins. Cu toate acestea, în cazuri rare, ar putea fi un efect secundar al unei breșe de securitate. Dacă credeți că hackerii v-au compromis site-ul, accesați ghidul Kathy Zant, Cum să curățați un site WordPress piratat.

O eroare de codare PHP, un conflict între două sau mai multe plugin-uri sau o problemă în mediul serverului dvs. sunt cele mai probabile cauze ale unui WSOD. Din fericire, acestea nu sunt catastrofe! Site-ul dvs. și conținutul său nu s-au pierdut. Dacă doriți, puteți repara singur un WSOD.

În acest articol, vom coborî lista cu posibilele diagnostice și remedii pentru WSOD. Veți învăța cum să readuceți la viață site-ul dvs. WordPress. De asemenea, veți afla cum funcționează WordPress la un nivel mai profund.

Vizualizare previzualizare

Ecranul alb al morții WordPress: Am făcut asta?

Da. Ecranul alb al morții este probabil rezultatul a ceva ȚI-ai făcut site-ului tău WordPress.

Cauza unui WSOD se găsește de obicei într-un plugin WordPress pe care tocmai l-ați instalat și activat. Sau, ar putea fi rezultatul unei actualizări recente. Un plugin nou adăugat sau actualizat poate intra în conflict cu un alt plugin. În acest scenariu, un plugin încearcă să facă același lucru ca altul sau acționează în scopuri contradictorii.

Dacă un plugin, o temă sau un fragment de cod PHP care funcționează defectuos cauzează o eroare fatală, este posibil să obțineți un WSOD. Acestea pot conține o eroare de sintaxă, o eroare sau un cod care nu este compatibil cu versiunea PHP pe care o utilizați. Dacă dvs. sau gazda dvs. tocmai v-ați actualizat versiunea PHP - ceea ce este un lucru bun! — pluginurile incompatibile vor începe să arunce erori și ar putea să vă distrugă site-ul cu un WSOD. Dacă utilizați WordPress 5.2 sau o versiune ulterioară așa cum ar trebui, problemele de incompatibilitate vor activa Modul de recuperare, care este mult mai util decât un WSOD adevărat.

De obicei, vinovatul este orice tocmai a fost schimbat cu un plugin, o temă sau un cod personalizat.

Deoarece WSOD este adesea un răspuns la orice a fost schimbat ultima dată (sau foarte recent) care afectează funcționalitatea site-ului dvs. Examinați toate modificările recente. Concentrați-vă pe schimbările care par cel mai probabil să provoace o problemă. Dacă tocmai ați instalat un plugin nou sau ați modificat un cod de temă, acestea sunt primele locuri în care să vă uitați pentru a vedea ce ar fi putut merge prost.

Când WordPress este doar în mare parte mort

Toate WSOD-urile nu sunt egale, iar unele nici măcar nu sunt adevărate WSOD.

Este posibil să primiți un fel de mesaj de eroare în loc de un ecran complet alb. Poate fi un mesaj de eroare de server despre o eroare HTTP 500 sau o conexiune la baza de date pierdută. Poate fi un mesaj de eroare critic de la WordPress. Sau, site-ul dvs. se poate încărca în mod normal pentru vizitatori, dar când încercați să vă autentificați, obțineți ecranul alb al morții. Opusul poate fi adevărat în alte cazuri: vă puteți conecta la tabloul de bord WordPress, dar front-end-ul public al site-ului dvs. oferă tuturor un ecran gol.

Dacă experiența dvs. WSOD se potrivește cu oricare dintre aceste descrieri, vești bune! Site-ul tău este în mare parte mort. Nu va fi greu să-l reînvie.

Dacă vă aflați în fața unui ecran alb complet gol atunci când vizitați site-ul dvs. WordPress sau încercați să vă conectați, acesta este adevăratul WSOD. Va trebui să săpați puțin mai adânc pentru a determina ce o cauzează.

Modul de recuperare WordPress și ecranul alb al morții

Din fericire pentru oricine se confruntă cu un WSOD, modul de recuperare a fost introdus în WordPress 5.2 pentru a-l elimina. Modul de recuperare prinde o mulțime de erori fatale și vă ajută să le remediați. Dacă nu utilizați cea mai recentă versiune majoră a WordPress core, începeți de acolo. Fii la curent!

Datorită modului de recuperare al WordPress, este rar să vezi un ecran alb complet gol când ceva nu merge bine. Veți vedea mai des o fereastră albă peste un ecran gri cu următorul mesaj începând cu WordPress 6.1:

Versiunile mai vechi de WordPress vor afișa mesaje similare, cum ar fi „Site-ul întâmpină dificultăți tehnice”.

Dacă navigați la o adresă URL de backend /wp-admin , va apărea și o notificare care vă va spune să verificați contul de e-mail de administrator pentru mai multe informații:

În alte cazuri, este posibil să vedeți un ecran alb cu text aldine care descrie o „Eroare internă a serverului” cu un fel de explicație și îndrumări pentru repararea site-ului dvs.

Bun venit la Recovery

Acesta este modul de recuperare. WordPress încearcă să vă ajute să-l ajutați să se ridice pe picioare.

Primul lucru de făcut este să verificați adresa de e-mail asociată contului dvs. de administrator WordPress. WordPress încearcă să identifice erori fatale PHP în tot codul pe care îl execută.

Dacă este posibil, WordPress va „întrerupe” un plugin sau alt cod care funcționează defectuos. WordPress va împiedica executarea codului prost. Apoi va raporta detaliile administratorilor prin e-mail.

În e-mailul pentru modul de recuperare, veți găsi instrucțiuni și un link temporar pentru a vă conecta la WordPress în modul de recuperare. (Acest link este valabil timp de 24 de ore. După aceea, va fi trimis unul nou dacă site-ul încă se confruntă cu o eroare critică.)

SFAT PRO: Dacă nu primiți e-mailul pentru modul de recuperare, este posibil să vă puteți conecta oricum la WordPress în modul de recuperare, adăugând următoarea adresă la adresa URL a site-ului dvs. de bază când sunteți conectat ca administrator: /wp-login.php?action=entered_recovery_mode .

Iată oportunitatea ta de a investiga în continuare. Dacă Modul de recuperare a identificat un anumit plugin ca fiind cauza WSOD, dezactivați-l. Acest lucru vă va aduce site-ul înapoi pentru toată lumea. Apoi puteți investiga orice probleme cunoscute pentru acest plugin. Verificați dacă există o actualizare pentru el. Adresați-vă persoanelor responsabile cu întreținerea acestuia.

Nu toate ecranele albe ale morții sunt la fel în WordPress

În câteva cazuri excepționale, ceva a mers prost în altă parte în WordPress sau în mediul serverului tău. Este posibil ca un proces de actualizare sau de instalare să se fi blocat, lăsând site-ul blocat în modul de întreținere. Este posibil ca dvs., furnizorul dvs. de găzduire sau un plugin pe care l-ați instalat, să fi modificat fișierele php.ini sau .htaccess cu rezultate neașteptate. Este posibil ca mediul dvs. existent să nu accepte cerințele unui plugin nou instalat.

Modul de recuperare WordPress nu poate face față acestor situații, dar va produce mesaje de eroare vizibile pe un ecran alb. Este posibil ca partea frontală a site-ului dvs. să fie inaccesibilă, dar ecranul de conectare al administratorului și interfața de back-end pot funcționa normal.

Acestea nu sunt situații adevărate WSOD, dar sunt la fel de enervante. De obicei, una dintre următoarele condiții le provoacă:

1. Ești blocat în modul de întreținere

În timp ce actualizează nucleul, pluginurile sau temele WordPress, WordPress intră în „Modul de întreținere”. Navigarea către orice parte a site-ului va afișa un ecran gri cu o fereastră de mesaj albă care spune:

Uneori, acest lucru nu se clarifică într-un minut, dar găzduirea WordPress gestionată de calitate va observa și va rezolva acest lucru printr-un proces automat. Dacă ați așteptat câteva minute fără nicio modificare, puteți ieși din modul de întreținere ștergând fișierul .maintenance din folderul rădăcină web/aplicație unde este instalat WordPress. (Pentru a-l vedea, poate fi necesar să activați vizualizarea fișierelor „invizibile” încadrate de un punct în numele fișierului.)

Când nu există niciun fișier .maintenance prezent, site-ul dvs. se va încărca conform așteptărilor.

2. Ați atins o limită de dimensiune a încărcării fișierului sau a postării

Este posibil ca site-ul dvs. să expire la un ecran alb într-un proces de încărcare, postpublicare sau de trimitere a formularelor, deoarece trimiteți prea multe date.

Soluție: creșteți limita de conținut postare în wp-config.php :

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

Soluție: creșteți limita de încărcare a fișierului și dimensiunea postării în php.ini :

 upload_max_filesize = 256M
dimensiune_max_post = 256M

Prelungirea timpului (în secunde) înainte de expirarea unei postări sau a oricărui formular poate fi de asemenea utilă. De asemenea, este posibil să măriți timpul pe care PHP îl are pentru a executa scripturi și a analiza intrarea. În plus, putem crește numărul de variabile care sunt permise într-un formular. În cele din urmă, putem specifica limita de timp după care PHP va trata datele trimise ca gunoi:

 max_execution_time = 300
max_input_time = 300
max_input_vars = 1000
session.gc_maxlifetime = 1000

Sau în .htaccess , httpd.conf sau virtualhost :

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value session.gc_maxlifetime 1000

Sau într-un fragment de cod personalizat pentru WordPress sau într-un fișier temă functions.php :

 @ini_set('upload_max_filesize', '256M');
@ini_set( 'post_max_size', '256M');
@ini_set('max_execution_time', '300');
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000');

Valorile de memorie și timp din acești parametri sunt doar recomandări. Pentru a vă asigura că funcționează și pentru a verifica valorile lor curente, utilizați instrumentul Site Health din interfața dvs. de administrare WordPress.

Împreună cu modul de recuperare, WordPress 5.2 a introdus instrumentul Site Health. Este foarte util pentru diagnosticarea problemelor și obținerea de informații tehnice despre setările site-ului și mediul serverului. Găsiți-l în meniul dvs. Administrator sub Instrumente > Sănătatea site-ului. De asemenea, puteți beneficia de funcțiile extinse din pluginul Health Check and Troubleshooting pentru WordPress.

3. PHP nu are memorie

PHP este limbajul de scripting pe partea serverului pe care se bazează nucleul WordPress. Apare un WSOD dacă nu există suficientă memorie pentru ca PHP să ruleze WordPress și pluginurile dvs. active. Este posibil să vedeți acest lucru indicat într-un mesaj de eroare sau într-un jurnal.

În funcție de planul dvs. de găzduire, este posibil să puteți crește limita de memorie PHP pentru toate aplicațiile de pe serverul dvs. sau pentru o anumită instanță a WordPress. Solicitați ajutor echipei de asistență tehnică a gazdei dvs. dacă nu sunteți sigur ce să faceți.

wp-config.php

În mod normal, adăugarea următoarei setări la fișierul wp-config.php din folderul WordPress va seta limita de memorie front-end pentru WordPress la 256 MB în acest exemplu:

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

128 până la 256 MB ar trebui să fie mai mult decât adecvate. De asemenea, puteți defini memoria maximă sau back-end alocată PHP (256 MB și în exemplul următor) adăugând următoarea linie și la wp-config.php :

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

Al doilea număr este limita maximă de memorie care definește memoria totală pe care PHP o are disponibilă pentru sine. Primul număr este memoria pentru WordPress care rulează în limita mai mare PHP. Limita maximă de memorie PHP ar trebui să fie egală sau mai mare decât limita de memorie a aplicației WordPress.

php.ini

O altă modalitate de a defini limita maximă de memorie PHP este cu o setare într-un fișier php.ini aflat în folderul WordPress:

 limita_memorie = 256M

Asigurați-vă că nu există punct și virgulă la începutul liniei! Și rețineți că php.ini va afecta doar instanța WordPress (sau orice altă aplicație PHP) care rulează în sau sub folderul în care se află fișierul php.ini . Dacă aveți acces la serverul sau rădăcina web, un php.ini aflat acolo va guverna setările de mediu pentru toate aplicațiile PHP, cu excepția cazului în care au propriul fișier php.ini care specifică condiții diferite.

.htaccess

O a treia modalitate de a defini limita de memorie PHP este prin fișierul .htaccess din folderul WordPress dacă utilizați Apache sau Litespeed ca server HTTP. La fel ca în exemplele de mai sus, .htaccess trebuie să aibă o linie necomentată ca aceasta pentru a seta o limită PHP maximă de 256 MB:

 php_value memory_limit 256M

Erorile în sintaxa setărilor aplicației și serverului în wp-config.php , php.ini și .htaccess pot provoca, de asemenea, un WSOD. Este posibil să fie necesar să le corectați manual sau să le înlocuiți cu valorile implicite inițiale dacă vă distrug site-ul. Dacă utilizați un server web Apache sau Litespeed, fișierul .htaccess care guvernează modul în care funcționează poate fi modificat de multe plugin-uri WordPress. Erorile introduse în oricare dintre aceste fișiere pot arăta un WSOD și vă pot distruge site-ul.

4. Serverul dvs. HTTP se blochează

HTTP (sau forma sa criptată, securizată HTTPS) este protocolul de transfer de hipertext care face dintr-un server web un server web. Acesta este modul în care serverele servesc paginile web (documente HTTP) clienților (cum ar fi browserele) la cerere.

Serverele HTTP utilizate în mod obișnuit pentru site-urile WordPress sunt Apache, Litespeed și NGINX. Ecranele lor de eroare arată ușor diferit și pot varia în modul în care browserele le afișează, dar toate raportează aceleași coduri de eroare HTTP.

O eroare HTTP 500, cunoscută și ca o eroare internă a serverului, indică faptul că există o problemă neașteptată cu serverul dvs. HTTP care îl împiedică să îndeplinească cererile HTTP. Alte coduri de eroare ale serverului 5xx, în special 502 (Bad Gateway), 503 (Service Unavailable) și 504 (Gateway Timeout), indică serverul dvs. supraîncărcat sau inaccesibil. Eroarea internă 500 este o soluție generală pentru defecțiunile de pe server care îl împiedică să returneze pagina/documentul solicitat.

Browserul dvs. poate oferi propria interpretare unică a ecranelor de eroare HTTP și poate afișa coduri de eroare speciale. Google Chrome (și alte browsere bazate pe Chromium) listează și explică în mod intern toate propriile coduri de eroare dacă navigați la chrome://network-errors/ în bara de adrese în timp ce utilizați Chrome.

Probleme la nivelul serverului

Software-ul de server HTTP folosit în mod obișnuit pentru site-urile WordPress include Apache, Litespeed și NGINX. Multe gazde WordPress le folosesc cu memorarea în cache pentru a maximiza performanța.

Dacă o reîmprospătare tare a browserului sau ștergerea cookie-urilor și a memoriei cache a browserului nu elimină ecranul de eroare 500, este posibil să primiți niște fișiere cache proaste pe partea serverului. Memorarea în cache pe server poate provoca multă confuzie atunci când nu funcționează bine, așa că ar trebui să încercați și să o ștergeți. Panoul de control al găzduirii sau interfața de administrare WordPress pot avea controale de ștergere a memoriei cache.

Cauzele obișnuite ale unei erori HTTP 500 pot include următoarele condiții la nivelul serverului:

1. Limita de memorie PHP a fost depășită.
2. Alte erori PHP când PHP nu este setat să afișeze erori.
3. Permisiune insuficientă pentru a accesa fișierele și folderele serverului.
4. Erori de sintaxă în fișierul de configurare .htaccess.

Am abordat deja limitele de memorie PHP și cum să le creștem. Vom cerceta depanarea PHP în următoarea secțiune de mai jos.

Permisiunile incorecte nu ar trebui să apară pe găzduirea WordPress modernă, gestionată, dar sunt comune pe găzduirea partajată tradițională. Fișierele ar trebui să fie setate la 664 sau 644, folderele ar trebui să fie setate la 775 sau 755, iar wp-config.php ar trebui să fie setat la 660, 600 sau 644. Aflați mai multe despre modificarea permisiunilor pentru fișiere la WordPress.org.

Dacă ați făcut modificări fișierului dvs. .htaccess sau utilizați un plugin (deseori sau cache) care îl modifică, poate fi necesar să îl examinați pentru erori, să îl restaurați sau să recreați un fișier .htaccess nou, funcțional. Aflați mai multe despre .htaccess la WordPress.org.

Probleme la nivelul clientului

Erorile HTTP 500 pot fi cauzate și pe partea client (în browser) de alte condiții:

5. Setări incorecte ale browserului.
6. Un cache corupt.
7. Fișiere JavaScript corupte care rulează în browserul dvs.
8. Probleme de conectare la internet.

Încercați să vă încărcați site-ul într-un browser diferit pentru a elimina browserul actual ca problemă. Dacă aveți o problemă cu browserul, încercați să îl resetați la setările implicite. Dezactivează orice extensii de browser sau pluginuri pe care le-ai instalat pentru a vedea dacă interacționează prost cu site-ul tău.

Dacă problema dvs. este legată de fișiere cache proaste, zona de administrare WordPress necachetă poate fi în continuare accesibilă pentru dvs. Dacă vă puteți conecta în continuare la interfața de administrare WordPress, este posibil să puteți utiliza comutatoarele de ștergere a memoriei cache acolo sau să încercați pașii suplimentari de depanare discutați mai jos.

De asemenea, este posibil ca o eroare HTTP 500 să fie cauzată de o problemă cu baza de date, o problemă cu un plugin sau o temă dintr-un site WordPress sau o problemă cu WordPress în sine.

Pentru a depana o eroare HTTP 500, ar trebui să activați înregistrarea erorilor pentru serverul dvs. HTTP și PHP. Apoi verificați ce erori apar în ambele. De asemenea, puteți verifica și crește limita de memorie PHP, dezactivați pluginurile și comutați la o temă implicită pentru a vedea dacă vreuna dintre aceste acțiuni aduce site-ul dvs. de rezervă.

Vom intra în acești pași mai detaliat mai jos. Dacă urmărirea acestora nu elimină eroarea 500, contactați echipa de asistență a gazdei dvs. web pentru asistență suplimentară.

Când WordPress este cu adevărat mort

Dacă primiți un ecran complet alb pe fiecare pagină din față și din spate a site-ului dvs. WordPress, fără feedback de eroare vizibil, aceasta este experiența completă WSOD. Puteți obține câteva mesaje de eroare și informații de diagnosticare dacă știți cum să accesați jurnalele de erori PHP și jurnalele serverului HTTP. Activarea depanării PHP pentru WordPress este o altă opțiune. Gazda dvs. poate avea unele instrumente pentru a vă face depanarea mai accesibilă. Dar dacă nu este cazul, puteți pur și simplu să mergeți în jos în această listă de remedii pentru WSOD obișnuit până când veți găsi soluția.

O listă de verificare principală pentru depanarea și remedierea ecranului alb al morții WordPress

Pentru a repara Ecranul alb al morții WordPress, parcurgerea următorilor pași vă va conduce la o soluție. Sunt organizate în ordinea celor mai frecvente cauze WSOD așa cum le-am experimentat, dar le puteți încerca în orice ordine.

Este cel mai logic să prioritizați soluțiile care par a fi cele mai relevante pentru situația dvs. particulară.

Pasul de înregistrare și depanare a erorilor (nr. 2) este cel mai tehnic, dar este complet și vă va spune întotdeauna ce anume determină întreruperea WordPress.

Am furnizat link-uri către câteva plugin-uri gratuite care pot fi instrumente utile de diagnosticare și reparare. De asemenea, puteți găsi iThemes Security deosebit de util pentru funcția de scanare și reparare a bazei de date, precum și pentru detectarea modificării fișierelor. Are chiar și instrumente de server pentru o privire mai profundă asupra setărilor și capacităților serverului dvs.

În ultimă instanță, o copie de rezervă bună și recentă va aduce site-ul dvs. din nou online în ultima stare bună cunoscută. Backup Buddy este cel mai bun plugin pentru acest rol.

Goliți memoria cache și cookie-urile din browser

Paginile stocate în cache ale site-ului dvs. în browser și pe server vă pot arăta ceva diferit de ceea ce se întâmplă de fapt. Să ne asigurăm că vezi ce arată WordPress vizitatorilor noi pe site-ul tău.

Mai întâi, ștergeți memoria cache și cookie-urile browserului. Acest lucru va încheia sesiunea dvs. de utilizator dacă sunteți conectat la WordPress sau la orice alt site, astfel încât să îl priviți ca orice alt vizitator.

Apoi, utilizați panoul de găzduire și administratorul WordPress (dacă este disponibil) pentru a șterge orice cache pe partea serverului pe care o creează gazda și pluginurile cache WordPress. Încercați să dezactivați toate stocarea în cache a site-ului și a serverului. Efectuați o reîmprospătare hard în browser. Dacă acest lucru rezolvă problema, problema poate fi că aveți setări de cache activate care nu funcționează pe sistemul dvs. Printr-un proces de eliminare, puteți identifica care funcționează și care nu.

2. Căutați erori PHP

Codul PHP din nucleul, temele sau pluginurile WordPress poate genera o eroare fatală care va face WordPress să renunțe la fantoma cu un ecran alb al morții.

Pentru a obține mai multe informații despre erorile PHP fatale și despre ce le provoacă, puteți activa raportarea erorilor PHP și o trimiteți pe ecran, un fișier jurnal sau ambele. Erorile fatale vor indica probabil sursa WSOD.

Fiind o aplicație web bazată pe PHP, WordPress are propriul sistem de raportare de diagnosticare pentru depanare, care vă ajută să profitați de funcțiile PHP de înregistrare a erorilor. Pentru a-l porni și a-l controla, asigurați-vă că există o linie în wp-config.php care spune:

 define('WP_DEBUG', true);

Poate fi necesar să îl adăugați sau să schimbați valoarea de la false la adevărat. Aceasta îi spune WordPress să activeze depanarea PHP.

De asemenea, puteți lua o comandă rapidă instalând și activând pluginul WP Debugging. Acesta va activa depanarea PHP pentru WordPress fără ca tu să fii nevoit să modificați direct wp-config.php .

Parametrii suplimentari wp-config.php arătați mai jos vor imprima rezultatul de depanare pe ecran ca HTML și un fișier numit „error_log” în mod implicit:

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

De asemenea, poate fi util să forțați WordPress să folosească versiunile neoptimizate ale dependențelor sale CSS și JavaScript, în cazul în care acestea cauzează o problemă:

 define('SCRIPT_DEBUG', true);

Plugin-ul Debug Bar este un instrument util suplimentar și complementar. Vă va arăta datele de depanare într-o interfață plăcută.

Pentru ca acest lucru să se întâmple, în php.ini trebuie să existe o linie care să ofere constantei error_reporting o altă valoare decât NONE , cum ar fi error_reporting = E_ALL . Nu ar trebui să existe un punct și virgulă la această linie; asta îl face mai degrabă un comentariu decât o setare activă. Rețineți că veți primi fiecare eroare PHP, avertisment și observație dacă utilizați E_ALL . Utilizați o valoare diferită, cum ar fi E_ERROR pentru a înregistra numai erorile de rulare fatale care cauzează blocarea WordPress.

3. Verificați dacă există conflicte de teme și pluginuri

Depanarea erorilor PHP, așa cum este descris în pasul anterior, ar trebui să vă îndrume către o temă clară sau un fișier plugin ca sursă a WSOD. De asemenea, vă puteți apropia de el cu o abordare mai puțin tehnică a procesului de eliminare.

Teme de depanare

Ecranul alb al morții este adesea cauzat de conflicte între temele WordPress și/sau pluginuri. Pentru a identifica sursele de conflict, puteți încerca să dezactivați toate pluginurile și să treceți la pachetele de teme implicite curente, nemodificate, cu nucleul WordPress, cum ar fi Twenty Twenty-Three.

Începeți cu tema - este cel mai simplu de testat. Dacă comutarea temei dvs. active la o temă implicită cunoscută bună, nemodificată, vă aduce site-ul din nou online, știți că problema dvs. se află în tema pe care ați folosit-o.

Aruncă o privire la fișierul functions.php al temei tale dacă are unul. Dacă ai schimbat-o recent, aceasta este o sursă probabilă a nenorocirii tale. Fișierul functions.php este locul în care se adaugă codul funcțional personalizat pentru a fi utilizat cu o temă atunci când este activată. Erorile de cod și de sintaxă greșite de aici vă vor oferi un WSOD.

Depanarea pluginurilor

Puteți dezactiva pluginurile fără acces la administratorul WordPress prin linia de comandă/SSH sau SFTP, pur și simplu mutând folderele cu pluginuri din folderul /wp-content/plugins/ temporar. Practica mea este să creez un subfolder de plugin numit „A”, astfel încât să apară primul în directorul /plugins sortat alfabetic. Apoi mut toate celelalte foldere cu pluginuri în „A”.

După ce ați făcut acest lucru, reîncărcați site-ul. WordPress se va comporta ca și cum toate pluginurile ar fi dispărut. Sunt încă instalate, dar dezactivate. Dacă ecranul alb al morții dispare, puteți încerca să vă reactivați pluginurile și tema unul câte unul, reîmprospătând pagina de pornire de fiecare dată pentru a vedea care dintre ele provoacă blocarea site-ului dvs.

Meks Quick Plugin Disabler este un instrument la îndemână care dezactivează rapid toate pluginurile active și apoi le reactivează din interiorul administratorului WordPress la comanda dumneavoastră.

4. Reparați fișierele de bază corupte

WSOD-ul dvs. poate fi consecința unor fișiere WordPress de bază corupte. Deși acest lucru este puțin probabil, este simplu să reinstalați rapid cea mai recentă versiune de WordPress cu un singur clic în zona Actualizări de tablou de bord WordPress. Acest lucru nu va dăuna niciunui plugin, teme sau conținut existent, așa că este o modalitate bună și ușoară de a confirma că fișierele de bază sunt bune.

Dacă niciunul dintre pașii de mai sus nu vă ajută, WSOD poate fi cauzat de o problemă cu mediul serverului dvs., care este dincolo de accesul dumneavoastră. În acest caz, poate fi necesar să contactați furnizorul dvs. de găzduire pentru asistență. Ca ultimă soluție, puteți, de asemenea, să vă derulați site-ul înapoi la o stare „ultim bun cunoscut”, restabilind o copie de rezervă.

Cum să preveniți un WSOD — Sfaturi pentru proprietarii și constructorii de site-uri WordPress

WordPress funcționa foarte bine – și apoi dintr-o dată ai primit Ecranul alb al morții!

Acest lucru se datorează probabil că TU ai schimbat ceva esențial pentru funcționarea WordPress.

Dacă utilizați un cont de găzduire WordPress solid gestionat cu Liquid Web sau Nexcess care este configurat corespunzător cu resurse suficiente pentru lucrurile pe care le faceți cu acesta, 99% dintre modalitățile prin care puteți sparge WordPress cu un WSOD pot fi evitate.

Problema este că proprietarii de site-uri nu evită aceste practici!

Ce sa nu faci

1. Codarea cowboy. Adăugarea sau editarea codului funcțional pe un site live prin SFTP, linia de comandă sau editori de cod și insertori de scripturi în cadrul administratorului WordPress. O mică greșeală va distruge site-ul. Schimbarea fișierelor de configurare precum .htaccess și wp-config.php poate, de asemenea, să distrugă un site. În schimb, lucrați la un site de testare local sau în direct (dar nu public).
2. Instalarea temelor, pluginurilor și extensiilor dubioase. Instalarea de software de calitate scăzută sau chiar anulată pe un site live este o invitație la probleme. Pur și simplu adăugarea de prea multe lucruri deodată poate face dificilă determinarea care este în cele din urmă o schimbare radicală. Similar cu codarea cowboy, instalarea de noi produse de cod într-un site live este riscantă. Testați bine mai întâi pe un loc privat sau pe un site de pregătire.
3. Cache complicată. Există mai multe tipuri de cache pe partea serverului pe care gazda dvs. le poate oferi, care ar putea să nu se joace bine cu toate pluginurile de cache și optimizare a performanței. Când implementați noi metode de stocare în cache sau setări, testați cu atenție mediile locale și de staging înainte de a implementa modificări pe un site live.
4. Actualizează totul dintr-o dată. Puteți actualiza în loturi multe teme și pluginuri simultan. În mod normal, acest lucru funcționează, dar dacă serverul dvs. expiră, este posibil să rămâneți blocat în modul de întreținere. De asemenea, codul recent actualizat poate introduce noi erori, conflicte sau probleme de compatibilitate. Dacă se întâmplă acest lucru și site-ul tău se defectează, va fi mai greu să identifici sursa problemei. Ar putea fi orice număr de articole dacă ați actualizat mai multe teme, pluginuri și extensii simultan. Codul actualizat poate fi testat local și pe site-uri de punere în scenă în direct înainte de a-l lansa pe site-ul dvs. public principal.

Sfaturi pentru o viață fără WSOD

WSOD se poate întâmpla oricărui site WordPress, dar nu ar trebui să fie un motiv de alarmă. Urmând sfaturile din acest ghid vă puteți ajuta să identificați problema și să o remediați rapid înainte ca vizitatorii site-ului dvs. să observe vreodată.

Problemele cu un site WordPress subliniază importanța întreținerii și îngrijirii adecvate. Mai bine decât să reacționezi la WSOD, poți învăța să lucrezi pe WordPress într-un mod care nu-ți va expune niciodată vizitatorii la mesaje de eroare și ecrane goale.

Faceți modificările cu atenție și în mod deliberat. Tratează cu potențialele tale WSOD într-un mediu local de testare sau de organizare. Acestea sunt instrumente și funcții standard pentru majoritatea gazdelor WordPress gestionate astăzi. Dacă urmați aceste bune practici de bază, nu va trebui să vă faceți griji cu privire la Ecranul alb al morții WordPress.

Cel mai bun plugin de securitate WordPress pentru a securiza și proteja WordPress

WordPress alimentează în prezent peste 40% din toate site-urile web, așa că a devenit o țintă ușoară pentru hackerii cu intenții rău intenționate. Pluginul iThemes Security Pro elimină presupunerile din securitatea WordPress pentru a facilita securizarea și protejarea site-ului dvs. WordPress. Este ca și cum ai avea în personal un expert în securitate cu normă întreagă care monitorizează și protejează constant site-ul tău WordPress pentru tine.

Obțineți iThemes Security Pro

Dan Knauss

Dan Knauss este generalist de conținut tehnic al StellarWP. El a fost scriitor, profesor și freelancer care lucrează în sursă deschisă de la sfârșitul anilor 1990 și cu WordPress din 2004.