Cum să Creați și să Accesați Jurnalele de Erori pentru WordPress (3 Metode)

Jurnalele de erori WordPress sunt înregistrări de diagnosticare care captează erori PHP, excepții fatale, defecțiuni ale bazei de date, conflicte de plugin-uri și incompatibilități de teme pe măsură ce apar pe serverul dvs. Accesarea și interpretarea acestor jurnale este cel mai rapid mod de a identifica cauza principală a unei pagini defecte, a unui ecran alb al morții sau a unei regresii silențioase de performanță — fără a ghici sau a dezactiva plugin-urile unul câte unul.

Acest ghid acoperă trei metode testate în producție pentru activarea, localizarea și citirea jurnalelor de erori WordPress: stiva nativă WP_DEBUG, jurnalele la nivel de server prin panoul de control al găzduirii și vizualizatoare de jurnale bazate pe plugin-uri. Fiecare metodă se potrivește unui nivel de acces și unui caz de utilizare diferit, iar toate trei sunt explicate cu căi exacte de fișiere, sintaxă de configurare și considerații de securitate.

De ce contează jurnalele de erori WordPress

WordPress rulează pe PHP, care generează mai multe clase de mesaje de execuție: erori fatale (execuția se oprește), avertismente (execuția continuă, dar ceva nu este în regulă), notificări (informaționale, indicând adesea cod depreciat) și mesaje depreciate (funcții programate pentru eliminare). În mod implicit, niciunul dintre acestea nu este scris într-un jurnal persistent în majoritatea configurațiilor de producție — fie sunt suprimate, fie sunt afișate în browser, ceea ce reprezintă un risc de securitate.

Fără un jurnal, o actualizare de plugin care introduce o eroare fatală produce doar un ecran gol. O bibliotecă SMTP configurată greșit elimină silențios e-mailurile. O depășire a limitei de memorie oprește încărcarea unei pagini fără nicio urmă vizibilă. Jurnalele de erori convertesc aceste eșecuri invizibile în intrări cu marcaj temporal, referință de fișier și număr de linie pe care le puteți rezolva imediat.

Metoda 1: Activarea modului de depanare WordPress prin wp-config.php

WordPress vine cu un subsistem de depanare integrat controlat de un set de constante PHP definite în wp-config.php. Aceasta este cea mai precisă metodă deoarece captează erori specifice WordPress, inclusiv cele aruncate de API-ul de plugin-uri, încărcătorul de teme și stratul de abstractizare a bazei de date (wpdb).

Pasul 1: Localizați și deschideți wp-config.php

Conectați-vă la serverul dvs. prin SFTP (preferat față de FTP simplu pentru securitate) folosind un client precum FileZilla sau Cyberduck, sau deschideți Managerul de fișiere al furnizorului dvs. de găzduire. Navigați la directorul rădăcină WordPress, de obicei /public_html/ sau /var/www/html/. Fișierul wp-config.php se află la rădăcina acestui director.

Dacă aveți acces SSH, îl puteți edita direct:

nano /var/www/html/wp-config.php

Pasul 2: Configurați constantele de depanare

Localizați linia existentă:

define( 'WP_DEBUG', false );

Înlocuiți întregul bloc cu următoarea configurație, care activează jurnalizarea fără a expune erorile vizitatorilor site-ului:

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

Ce face fiecare constantă:

• WP_DEBUG — activează motorul de depanare WordPress și activează raportarea erorilor PHP la nivelul E_ALL.
• WP_DEBUG_LOG — scrie toate erorile capturate într-un fișier jurnal în loc de (sau în plus față de) ecran.
• WP_DEBUG_DISPLAY — când este setat la false, suprimă afișarea pe ecran. Acest lucru este critic pe site-urile de producție; fără aceasta, notificările PHP scurg căi interne de fișiere și nume de variabile vizitatorilor.
• display_errors — directiva PHP de bază; setarea sa la 0 prin ini_set oferă un al doilea nivel de suprimare în cazul în care un plugin sau temă suprascrie WP_DEBUG_DISPLAY.

Pasul 3: Localizați fișierul jurnal de depanare

Cu WP_DEBUG_LOG setat la true, WordPress scrie erorile în:

/wp-content/debug.log

Acest fișier este creat automat la prima eroare jurnalizată. Îl puteți vizualiza prin SFTP sau SSH:

tail -f /var/www/html/wp-content/debug.log

Flag-ul tail -f transmite în timp real noile intrări, ceea ce este de neprețuit atunci când reproduceți interactiv o eroare specifică.

Pasul 4: Utilizați o cale personalizată pentru jurnal (recomandat pentru securitate)

Calea implicită debug.log este accesibilă public dacă serverul dvs. web nu o blochează explicit. Un server configurat greșit va servi https://yourdomain.com/wp-content/debug.log oricărui vizitator, expunând căi interne, prefixe de tabele ale bazei de date și nume de clase.

Opțiunea A — Mutați fișierul jurnal în afara rădăcinii web:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Creați directorul țintă și setați permisiunile:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Opțiunea B — Blocați calea implicită prin .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Opțiunea C — Echivalentul Nginx în blocul dvs. de server:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Pasul 5: Dezactivați modul de depanare după depanare

Nu lăsați niciodată WP_DEBUG setat la true pe un site activ mai mult decât este necesar. Odată ce problema este rezolvată:

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

Lăsarea modului de depanare activ pe un site de producție degradează performanța (PHP procesează fiecare notificare E_ALL) și poate expune trasee de stivă sensibile dacă WP_DEBUG_DISPLAY este setat accidental la true.

Metoda 2: Accesarea jurnalelor de erori la nivel de server prin panoul de control al găzduirii

Erorile WordPress care apar înainte ca bootstrap-ul WordPress să se finalizeze — cum ar fi un wp-config.php corupt, o incompatibilitate de versiune PHP sau o conexiune eșuată la baza de date — nu vor apărea niciodată în debug.log deoarece WordPress însuși nu se încarcă niciodată. Pentru acestea, aveți nevoie de jurnalul de erori PHP al serverului sau de jurnalul de erori Apache/Nginx.

Găzduire bazată pe cPanel

Dacă mediul dvs. de găzduire utilizează VPS cu cPanel, jurnalul de erori este accesibil prin interfața panoului de control:

1. Conectați-vă la cPanel.
2. Navigați la Metrics > Errors.
3. Panoul afișează ultimele 300 de linii din jurnalul de erori Apache pentru contul dvs.

Pentru fișierul jurnal complet, utilizați File Manager din cPanel sau conectați-vă prin SFTP și navigați la:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Numele exacte ale fișierelor variază în funcție de configurația serverului, dar modelul este consistent în majoritatea instalațiilor cPanel.

Găzduire bazată pe Plesk

În Plesk, navigați la Websites & Domains > selectați domeniul dvs. > Logs. Puteți filtra după tipul de jurnal (acces, eroare, PHP) și descărca fișierul jurnal complet.

Acces direct la server (VPS sau dedicat)

Pe un mediu de VPS Hosting sau Server Dedicat unde aveți acces root, locațiile jurnalelor depind de stiva dvs.:

Pentru a monitoriza jurnalul PHP-FPM în timp real:

tail -f /var/log/php8.2-fpm.log

Pentru a căuta erori fatale specifice WordPress în jurnalul Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Configurarea jurnalizării erorilor PHP la nivel de server

Dacă erorile PHP nu sunt scrise într-un jurnal, verificați configurația dvs. php.ini:

php --ini | grep "Loaded Configuration"

Deschideți fișierul php.ini identificat și verificați sau setați:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Reporniți PHP-FPM după modificări:

systemctl restart php8.2-fpm

Alternativ, suprascrieți setările PHP per site folosind un fișier .htaccess (doar Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Metoda 3: Utilizarea unui plugin de jurnalizare a erorilor WordPress

Pentru mediile în care accesul direct la server este restricționat — cum ar fi Găzduirea Web Partajată — sau pentru echipele în care administratorii non-tehnici trebuie să revizuiască erorile fără acces SSH, un plugin WordPress oferă o alternativă viabilă.

Plugin-uri recomandate

• WP Log Viewer — citește fișierul existent debug.log și îl afișează în administrarea WordPress cu filtrare și căutare.
• Error Log Monitor — adaugă un widget de tablou de bord care afișează erorile recente și poate trimite alerte prin e-mail când sunt jurnalizate erori noi.
• Query Monitor — depășește jurnalizarea erorilor pentru a profila interogările bazei de date, apelurile HTTP API, hook-urile și etichetele condiționale. Esențial pentru depanarea performanței.
• Health Check & Troubleshooting — plugin-ul oficial WordPress.org; activează un mod de depanare care activează o temă implicită și dezactivează toate plugin-urile doar pentru sesiunea dvs., fără a afecta alți vizitatori.

Instalarea și configurarea Error Log Monitor

1. În administrarea WordPress, mergeți la Plugins > Add New.
2. Căutați Error Log Monitor și faceți clic pe Install Now, apoi pe Activate.
3. Navigați la Settings > Error Log Monitor.
4. Setați calea fișierului jurnal. Dacă ați mutat debug.log în afara rădăcinii web, introduceți calea absolută a serverului aici.
5. Configurați frecvența alertelor prin e-mail dacă doriți notificări pentru noi tipuri de erori.

Plugin-ul citește același fișier debug.log în care scrie WP_DEBUG_LOG. Nu creează un mecanism de jurnalizare separat — este un vizualizator. Aceasta înseamnă că WP_DEBUG și WP_DEBUG_LOG trebuie să fie în continuare activate în wp-config.php pentru ca plugin-ul să afișeze ceva.

Limitare critică: Plugin-urile se încarcă după ce WordPress pornește. Orice eroare care împiedică încărcarea WordPress (eșec de conexiune la baza de date, fișier de bază corupt, versiune PHP incompatibilă) nu va fi vizibilă în niciun vizualizator de jurnal bazat pe plugin-uri. Pentru aceste scenarii, Metoda 2 este singura opțiune.

Comparație: Trei metode de jurnalizare a erorilor WordPress

Citirea și interpretarea intrărilor din jurnalul de erori WordPress

O intrare brută debug.log arată astfel:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Cum să citiți aceasta:

• Marcajul temporal este în UTC — convertiți la fusul orar local al serverului dvs. dacă este necesar.
• PHP Fatal error înseamnă că execuția s-a oprit. Pagina care a declanșat aceasta a returnat o eroare 500 sau un ecran gol.
• Call to undefined function get_field() înseamnă că plugin-ul Advanced Custom Fields este fie dezactivat, fie încărcat după ce functions.php temei a încercat să îl apeleze.
• Trasarea stivei arată fișierul exact și numărul de linie. Începeți depanarea la linia 47 din functions.php.

Tipare comune de erori și cauzele lor:

• PHP Warning: require(): Failed opening required — o cale de fișier este greșită sau un fișier lipsește. Cauzat adesea de un plugin care face referire la un fișier care a fost șters.
• PHP Deprecated: Function _register_controls is deprecated — un plugin sau temă folosește un API învechit. Nu este fatal, dar indică un plugin care nu a fost actualizat pentru versiunea curentă WordPress/Elementor.
• WordPress database error ... for query — o interogare wpdb a eșuat. Verificați pentru nepotriviri de prefix de tabel sau tabele corupte.
• Maximum execution time of 30 seconds exceeded — un script a rulat prea mult timp. Comun cu importuri mari, interogări neoptimizate sau apeluri API externe care expiră.
• Allowed memory size of X bytes exhausted — PHP a atins limita de memorie. Creșteți memory_limit în php.ini sau identificați plugin-ul cu scurgere de memorie.

Cele mai bune practici pentru gestionarea jurnalelor de erori WordPress

Rotiți jurnalele pentru a preveni epuizarea discului. Un site WordPress aglomerat aflat sub atac sau cu o eroare recurentă poate genera sute de megaocteți de date de jurnal pe zi. Pe serverele Linux, configurați logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Nu trimiteți niciodată debug.log în controlul versiunilor. Adăugați-l în .gitignore:

wp-content/debug.log

Auditați wp-config.php după fiecare migrare de server. Migrările de găzduire resetează frecvent WP_DEBUG la false sau introduc un nou șablon wp-config.php care suprascrie constantele dvs.

Utilizați SAVEQUERIES pentru depanarea la nivel de bază de date. Adăugați această constantă alături de WP_DEBUG pentru a jurnaliza fiecare interogare SQL pe care o execută WordPress:

define( 'SAVEQUERIES', true );

Apoi inspectați $wpdb->queries într-un șablon personalizat sau prin Query Monitor. Dezactivați-l imediat după utilizare — stochează fiecare interogare în memorie și crește semnificativ consumul de RAM.

Corelați marcajele temporale ale jurnalelor cu evenimentele de implementare. Dacă apare un nou tip de eroare, verificați dacă coincide cu o actualizare de plugin, o actualizare a nucleului WordPress sau o schimbare de versiune PHP pe server. Majoritatea panourilor de control ale găzduirii jurnalizează modificările versiunii PHP într-un jurnal de audit separat.

Matrice de decizie: Ce metodă să utilizați

Listă de verificare tehnică a concluziilor cheie

• Setați WP_DEBUG_DISPLAY la false înainte de a activa WP_DEBUG_LOG pe orice site cu trafic activ.
• Mutați debug.log în afara rădăcinii web sau blocați-l prin regulile serverului — calea implicită este accesibilă public.
• Utilizați tail -f pe fișierul jurnal când reproduceți erori interactiv; elimină necesitatea de a reîmprospăta manual fișierul.
• Jurnalele PHP și Apache/Nginx la nivel de server sunt singura sursă de adevăr pentru erorile care apar înainte ca WordPress să se încarce.
• Vizualizatoarele de jurnale bazate pe plugin-uri necesită ca WP_DEBUG_LOG să fie activ — sunt cititori, nu scriitori.
• Implementați rotația jurnalelor pe orice server unde WP_DEBUG_LOG este activat mai mult de câteva ore.
• Nu lăsați niciodată SAVEQUERIES activat în producție; este o responsabilitate de memorie și performanță.
• După rezolvarea unei probleme, setați toate constantele de depanare înapoi la false și verificați cu o cerere de browser că nu apar notificări PHP în sursa paginii.

—

Întrebări frecvente

Unde se află implicit fișierul jurnal de depanare WordPress?

WordPress scrie jurnalul de depanare în /wp-content/debug.log relativ la directorul rădăcină WordPress. Această cale este creată doar după ce prima eroare este jurnalizată și doar când atât WP_DEBUG cât și WP_DEBUG_LOG sunt setate la true în wp-config.php. Puteți suprascrie calea transmițând un șir de cale absolută a fișierului ca valoare a WP_DEBUG_LOG în loc de true.

Este sigur să activați WP_DEBUG pe un site de producție activ?

Este sigur doar dacă WP_DEBUG_DISPLAY este setat explicit la false și display_errors este setat la 0. Fără aceste două setări, erorile PHP — inclusiv căile interne de fișiere și numele tabelelor bazei de date — sunt redate direct în sursa HTML a fiecărei pagini. Asociați întotdeauna WP_DEBUG true cu WP_DEBUG_DISPLAY false pe orice site cu trafic public.

De ce fișierul meu debug.log este gol chiar dacă WP_DEBUG este activat?

Cele mai comune cauze sunt: procesul serverului web nu are permisiune de scriere în directorul /wp-content/; WP_DEBUG_LOG este setat la false sau lipsește din wp-config.php; sau eroarea apare la nivel de server înainte ca WordPress să se încarce, ceea ce înseamnă că va apărea în jurnalul Apache sau PHP-FPM mai degrabă decât în debug.log. Verificați permisiunile directorului cu ls -la wp-content/ și verificați că constantele sunt definite în ordinea corectă în wp-config.php.

Care este diferența dintre WP_DEBUG_LOG și jurnalul de erori PHP al serverului?

WP_DEBUG_LOG este o constantă la nivel WordPress care direcționează erorile capturate de gestionarul de erori personalizat al WordPress către debug.log. Jurnalul de erori PHP al serverului (configurat prin error_log în php.ini) captează toate erorile PHP la nivel de interpret, inclusiv cele care apar înainte ca WordPress să se inițializeze. Pe un server configurat corespunzător, ambele jurnale sunt active simultan și se completează reciproc.

Pot activa jurnalizarea erorilor pe găzduirea partajată fără acces SSH?

Da. Puteți edita wp-config.php prin File Manager al furnizorului dvs. de găzduire în cPanel sau Plesk, activa WP_DEBUG și WP_DEBUG_LOG, și apoi citi debug.log prin aceeași interfață File Manager. Pentru jurnalele la nivel de server pe Găzduirea Web Partajată, utilizați secțiunea Errors din Metrics în cPanel. Dacă aveți nevoie de un control mai granular asupra configurației PHP și a căilor de jurnal, actualizarea la un plan de VPS Hosting vă oferă acces direct la php.ini și acces SSH complet la toate fișierele jurnal.