WP_DEBUG chưa được đặt, nhưng tôi vẫn nhận được cảnh báo

Nếu WP_DEBUG không được đặt, theo tôi hiểu, bạn sẽ không bao giờ thấy cảnh báo. Nhưng trên một số trang web trên một số máy chủ, tôi vẫn thấy một số. Không phải tất cả các cảnh báo sẽ được hiển thị nếu WP_DEBUG được đặt, nhưng một vài lựa chọn.

Tôi đã thử thay đổi mức độ lỗi trong php.ini, nhưng dường như điều đó không ảnh hưởng đến việc cảnh báo có xuất hiện hay không, nhưng chúng xuất hiện với số lượng khác nhau trên các máy chủ khác nhau (nghĩa là không có cảnh báo nào về phát triển, một cảnh báo về dàn dựng và thêm một vài cảnh báo về sản xuất).

WP_DEBUG không có tác động đến đầu ra lỗi PHP. Ngoài cài đặt error_Vporting, hãy đặt display_errors = 0 trong tệp php.ini của bạn. Nó được bật theo mặc định để phát triển. Nhưng bạn sẽ muốn nó tắt trên các máy chủ sản xuất.

Thay thế

define('WP_DEBUG', false);

Với cái này:

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

Cũng có thể, dòng này đã được đặt thành false. Trong trường hợp đó, bạn sẽ thấy đoạn mã sau:

define('WP_DEBUG', false);

Trong cả hai trường hợp, bạn cần thay thế dòng này bằng mã sau:

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

Đừng quên lưu các thay đổi của bạn và tải tệp wp-config.php của bạn trở lại máy chủ.

Cố gắng vô hiệu hóa / chặn tất cả các cảnh báo / thông báo lỗi trong wp-config.php(trên đầu trang) của bạn. Dù sao: Lỗi không có gì xấu. Họ cung cấp cho bạn một cơ hội để sửa mã của bạn.

Đối với môi trường WordPress, thường không có lý do để sử dụng ini_setvì đó là những gì các hằng số được xác định do WordPress Core cung cấp đã đạt được. Cách mà PHP hoạt động là các cài đặt nhất định có thể được ghi đè trong CMS (WordPress) của bạn, trong các tập lệnh riêng lẻ và thậm chí trên cơ sở mỗi người dùng hoặc mỗi thư mục (gây thất vọng cho các máy chủ và đại lý web).

Để vô hiệu hóa lỗi hiển thị trên trang trong WordPress, cài đặt duy nhất bạn thực sự cần là:

define('WP_DEBUG', false);

... bởi vì khi WP_DEBUGbị vô hiệu hóa, các tùy chọn phụ sẽ không hoạt động:

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

Hãy nhớ rằng WP_DEBUG_LOGtùy chọn khó hiểu chỉ đề cập đến việc tạo debug.logtrong thư mục wp-contentvà không ảnh hưởng đến các cài đặt ghi nhật ký khác, v.v.

Một lần nữa, các cài đặt trong WordPress có thể ghi đè cài đặt PHP mặc định, vì vậy các cài đặt PHP của bạn không quan trọng bằng việc có các cài đặt chính xác trong wp-config.phptệp của bạn , tải trước các thành phần WP khác.

Điều đó nói rằng, đó là một ý tưởng tốt để thực hiện các cài đặt mặc định như dưới đây trong sản xuất:

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

Để biết ví dụ đầy đủ, hãy tham khảo tệp php.ini SlickStack của chúng tôi được tối ưu hóa cho Nginx và PHP-FPM.

Trong một trường hợp, sau nhiều giờ nghiên cứu, chúng tôi nhận ra một plugin (hoặc chủ đề) đã ghi đè các cài đặt xử lý lỗi khác nhau được đặt trước đó php.inivà wp-config.php. Cách duy nhất để ngăn chặn điều này là xóa plugin hoặc chủ đề WordPress đang cố gắng "hack" các cài đặt PHP của bạn hoặc bảo họ xóa nó vì đó là cách thực hành rất tệ đối với các tiện ích mở rộng để ghi đè các tùy chọn gỡ lỗi của CMS.

Trong SlickStack, chúng tôi đã tạo một tập lệnh Bash "gắn cờ" bất kỳ ini_setvà error_reportingdòng nào từ các tệp PHP trong /themes/và /plugins/thư mục bằng cách làm nổi bật các trường hợp đó bằng cách sử dụng Trình cắm MU (tập lệnh PHP) hiển thị danh sách các "hack" như vậy trong Bảng điều khiển quản trị WP.