WP_DEBUG nie jest ustawiony, ale wciąż otrzymuję ostrzeżenia

Jeśli WP_DEBUG nie jest ustawiony, jak rozumiem, nigdy nie powinieneś widzieć ostrzeżeń. Ale w niektórych witrynach na niektórych serwerach wciąż widzę kilka. Nie wszystkie ostrzeżenia, które byłyby wyświetlane, gdyby ustawiono WP_DEBUG, ale kilka wybranych.

Próbowałem zmienić poziom błędu w php.ini, ale wydaje się, że nie ma to wpływu na to, czy pojawiają się ostrzeżenia, czy też nie, ale pojawiają się w różnych ilościach na różnych serwerach (tj. Brak ostrzeżeń podczas programowania, jedno ostrzeżenie o przemieszczaniu i jeszcze kilka ostrzeżeń dotyczących produkcji).

WP_DEBUG nie ma wpływu na wyjście błędu PHP. Oprócz ustawienia raportowania błędów ustaw display_errors = 0 w pliku php.ini. Jest domyślnie włączony do programowania. Ale będziesz tego chciał na serwerach produkcyjnych.

Zastąpić

define('WP_DEBUG', false);

z tym:

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);

Możliwe jest również, że ta linia jest już ustawiona na false. W takim przypadku zobaczysz następujący kod:

define('WP_DEBUG', false);

W obu przypadkach należy zastąpić ten wiersz następującym kodem:

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

Nie zapomnij zapisać zmian i przesłać plik wp-config.php z powrotem na serwer.

Spróbuj wyłączyć / ukryć wszystkie ostrzeżenia / powiadomienia o błędach w swoim wp-config.php(na górze). W każdym razie: Błędy nie są niczym złym. Dają ci szansę na poprawienie twojego kodu.

W środowiskach WordPress zwykle nie ma powodu, aby z tego korzystać, ini_setponieważ właśnie to osiągają zdefiniowane stałe dostarczone przez WordPress Core. Sposób działania PHP polega na tym, że niektóre ustawienia można zastąpić w systemie CMS (WordPress), w poszczególnych skryptach, a nawet dla poszczególnych użytkowników lub katalogów (ku wielkiej frustracji hostów i agencji).

Aby wyłączyć wyświetlanie błędów na stronie w WordPress, jedynym ustawieniem, którego naprawdę potrzebujesz, jest:

define('WP_DEBUG', false);

... ponieważ kiedy WP_DEBUGjest wyłączone, opcje podrzędne są wtedy nieaktywne:

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

Należy pamiętać, że myląca WP_DEBUG_LOGopcja odnosi się tylko do tworzenia debug.logw katalogu wp-contenti nie wpływa na inne ustawienia rejestrowania itp.

Ponownie, ustawienia w WordPress mogą zastąpić domyślne ustawienia PHP, więc ustawienia PHP nie mają tak dużego znaczenia, jak prawidłowe ustawienia wp-config.phppliku, które ładują się przed innymi komponentami WP.

To powiedziawszy, dobrym pomysłem jest wdrożenie domyślnych ustawień, takich jak poniżej w produkcji:

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

Aby uzyskać pełny przykład, zapoznaj się z naszym plikiem php.ini SlickStack zoptymalizowanym dla Nginx i PHP-FPM.

W jednym przypadku, po godzinach badań, zdaliśmy sobie sprawę, że wtyczka (lub motyw) zastępuje różne ustawienia obsługi błędów wcześniej ustawione w php.inii wp-config.php. Jedynym sposobem, aby temu zapobiec, jest usunięcie wtyczki lub motywu WordPress, który próbuje „zhakować” ustawienia PHP lub nakazać im usunięcie, ponieważ jest to bardzo zła praktyka, aby rozszerzenia zastępowały opcje debugowania twojego CMS.

W SlickStack stworzyliśmy skrypt Bash, który „ zaznacza ” dowolne wiersze ini_seti error_reportingpliki PHP w katalogach /themes/i /plugins/, zaznaczając takie przypadki za pomocą wtyczki MU (skrypt PHP), która wyświetla listę takich „włamań” na pulpicie administracyjnym WP.