WP_DEBUG nu este setat, dar încă primesc avertismente

Înlocuiți

define('WP_DEBUG', false);

cu acest cod:

ini_set('log_errors','On');

ini_set('display_errors','Off');

ini_set('error_reporting', E_ALL );

define('WP_DEBUG', false);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

De asemenea, este posibil ca această linie să fie deja setată pe false. În acest caz, veți vedea următorul cod:

define('WP_DEBUG', false);

În orice caz, trebuie să înlocuiți această linie cu următorul cod:

ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Nu uitați să salvați modificările și să încărcați fișierul wp-config.php înapoi pe server.

Pentru mediile WordPress, de obicei nu există niciun motiv să folosești ini_set deoarece constantele definite de WordPress Core realizează deja acest lucru. Modul în care funcționează PHP este că anumite setări pot fi suprascrise în cadrul CMS-ului tău (WordPress), în scripturi individuale și chiar pe o bază per-utilizator sau per-director (mult spre frustrarea gazdelor web și a agențiilor).

Pentru a dezactiva afișarea erorilor pe pagină în WordPress, singura setare de care ai nevoie este:

define('WP_DEBUG', false);

...deoarece când WP_DEBUG este dezactivat, sub-opțiunile devin inactive:

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

Ține minte că opțiunea confuză WP_DEBUG_LOG se referă doar la crearea fișierului debug.log în directorul wp-content și nu afectează alte setări de logare etc.

Din nou, setările din WordPress pot suprascrie setările implicite PHP, așadar setările tale PHP nu contează atât de mult pe cât contează setările corecte din fișierul tău wp-config.php, care se încarcă înaintea altor componente WordPress.

Totuși, este o idee bună să implementezi setări implicite precum cele de mai jos în mediul de producție:

error_reporting = E_ERROR | E_WARNING | E_PARSE
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/www/logs/error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
report_memleaks = On
xmlrpc_errors = 0
html_errors = Off

Pentru un exemplu complet, consultă fișierul SlickStack php.ini optimizat pentru Nginx și PHP-FPM.

Într-un caz, după ore de cercetare, am realizat că un plugin (sau o temă) suprascria diverse setări de gestionare a erorilor stabilite anterior în php.ini și wp-config.php. Singura modalitate de a preveni acest lucru este eliminarea pluginului sau a temei WordPress care încearcă să "hack-uiască" setările tale PHP sau să le ceri să o înlăture deoarece este o practică foarte proastă ca extensiile să suprascrie opțiunile de depanare ale CMS-ului tău.

În SlickStack, am creat un script Bash care "marchează" orice linii ini_set și error_reporting din fișierele PHP din directoarele /themes/ și /plugins/, evidențiind astfel de instanțe folosind un MU Plugin (script PHP) care afișează o listă cu astfel de "hack-uri" în Panoul de Administrare WordPress.

Încearcă să dezactivezi/suprimi toate avertismentele/notificările de eroare în fișierul tău wp-config.php (în partea de sus). Oricum: Erorile nu sunt ceva rău. Ele îți oferă șansa de a-ți repara codul.

Nici una dintre soluțiile de mai sus nu a funcționat pentru mine.

Pentru mine, soluția a fost să adaug un fișier php în folderul mu-plugins. Pur și simplu creează un fișier php și adaugă următoarea linie.

error_reporting(E_ALL & ~( E_NOTICE ));

După aceea, încarcă-l în folderul mu-plugins (dacă folderul nu există, creează-l în folderul wp-content).

În cazul meu, problema era că WP_DEBUG era setat la 'false' și nu la false, ceea ce cred că este evaluat ca true, deoarece este un șir de caractere.

Deci încercați

define('WP_DEBUG', false);

dacă aveți

define('WP_DEBUG', 'false');