Vị trí file debug log của WordPress: debug.log nằm ở đâu và cách chuyển nó đi

WordPress ghi log gỡ lỗi vào wp-content/debug.log theo mặc định — trên đĩa là đường dẫn tuyệt đối kiểu /path/to/your/site/wp-content/debug.log. File này chưa tồn tại cho tới khi thật sự có thứ gì đó được ghi lại, và nó chỉ được ghi khi WP_DEBUG là true và WP_DEBUG_LOG được bật trong wp-config.php. Vị trí mặc định đó cũng là một vấn đề bảo mật có thật, vì trên phần lớn hosting thì ai cũng lấy được nó bằng trình duyệt.

Ba hằng và nhiệm vụ của từng cái

Cả ba đều đặt trong wp-config.php, phía trên dòng ghi /* That's all, stop editing! Happy blogging. */. Bất cứ thứ gì thêm dưới dòng đó sẽ chạy sau khi WordPress đã khởi động xong và bị bỏ qua.

Hằng	Mặc định	Nhiệm vụ
WP_DEBUG	false	Công tắc tổng. Nâng mức báo lỗi của PHP để hiện các notice, warning và cảnh báo lỗi thời. Không có nó thì mọi thứ còn lại trong bảng này đều vô dụng.
WP_DEBUG_LOG	false	Gửi lỗi vào một file. true nghĩa là wp-content/debug.log. Nếu là chuỗi thì được hiểu là đường dẫn file cần ghi.
WP_DEBUG_DISPLAY	true	In lỗi vào HTML của trang, mọi khách truy cập đều thấy.

Phần phụ thuộc mới là chỗ người ta hay nhầm. WP_DEBUG_LOG được đọc bên trong nhánh WP_DEBUG của đoạn mã khởi động WordPress. Nếu WP_DEBUG là false thì đặt WP_DEBUG_LOG thành true chẳng có tác dụng gì cả — không file, không lỗi, không cảnh báo. Nếu bạn đã thêm WP_DEBUG_LOG mà không thấy log nào, hãy kiểm tra WP_DEBUG trước.

Một cấu hình dùng được cho trang đang chạy thật:

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

Nếu WP_DEBUG đã được khai báo ở phía trên trong file — thường là vậy, với giá trị false — hãy sửa đúng dòng đó thay vì thêm một define() thứ hai. Khai báo cùng một hằng hai lần sẽ sinh ra cảnh báo PHP, và trên một trang đang bật hiển thị thì cảnh báo đó nằm chình ình ngay đầu trang.

Vì sao WP_DEBUG_DISPLAY phải là false trên môi trường thật

Khi bật hiển thị, lỗi PHP được in thẳng vào HTML trả về. Chỉ một cảnh báo lỗi thời từ theme cũng đủ in đường dẫn tuyệt đối trên máy chủ cho mọi khách truy cập thấy. Một lỗi cơ sở dữ liệu thì in ra tên bảng và mảnh truy vấn. Tệ hơn nữa, nội dung xuất hiện trước khi header được gửi sẽ phá vỡ chuyển hướng, phá vỡ các phản hồi REST và AJAX vốn cần JSON sạch, và có thể tạo ra màn hình trắng mà sau đó người ta đổ lỗi cho plugin.

Một điểm tinh tế đáng biết: đặt WP_DEBUG_DISPLAY thành null không giống với false. null bảo WordPress để nguyên thiết lập display_errors của PHP và kế thừa những gì máy chủ đã cấu hình. false thì chủ động ép tắt. Trên trang chạy thật, hãy dùng false và thêm dòng ini_set ở trên như một lớp bảo hiểm kép, vì một plugin vẫn có thể bật lại display_errors ở giai đoạn sau của request.

Vị trí mặc định là nơi ai cũng tải về được

wp-content/debug.log nằm bên trong thư mục web. Không có gì trong bản cài WordPress nguyên gốc chặn các request trực tiếp tới nó. Trên một cấu hình Apache hay nginx thông thường, https://yoursite.com/wp-content/debug.log trả về nguyên file dưới dạng văn bản thuần. Log gỡ lỗi chứa đường dẫn tuyệt đối trên máy chủ, nội tình của plugin và theme, lỗi cơ sở dữ liệu kèm truy vấn thật, và đôi khi cả giá trị truyền qua những hàm đang lỗi. Đó là kho thông tin trinh sát miễn phí cho bất kỳ ai đoán ra URL — và nó nằm trong nhóm URL đầu tiên mà các công cụ quét tự động thử tới.

Có hai cách xử lý. Cách tốt hơn là chuyển log đi nơi khác.

Chuyển log bằng một đường dẫn

Từ WordPress 5.1, WP_DEBUG_LOG chấp nhận một chuỗi đường dẫn file thay vì giá trị boolean. Hãy trỏ nó ra ngoài thư mục gốc của tài liệu web:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Ba nguyên tắc cho đường dẫn đó. Dùng đường dẫn tuyệt đối — đường dẫn tương đối được phân giải theo thư mục làm việc của PHP, vốn thay đổi theo từng request và từng máy chủ, nên bạn sẽ lạc mất file. Thư mục phải tồn tại sẵn; PHP sẽ không tạo giúp bạn, và nếu không mở được file thì nó thất bại trong im lặng. Và thư mục phải cho người dùng PHP quyền ghi, mà trên hosting chia sẻ thì đó không phải tài khoản bạn dùng để đăng nhập SFTP.

Nếu hosting nhốt bạn trong thư mục web và không có chỗ nào phía trên để ghi, hãy giữ đường dẫn mặc định và chặn truy cập ở mức máy chủ. Với Apache:

<Files "debug.log">
  Require all denied
</Files>

Đoạn đó đặt trong file .htaccess bên trong wp-content, không phải file ở thư mục gốc — WordPress ghi đè .htaccess gốc mỗi khi bạn lưu đường dẫn tĩnh và có thể xóa mất phần bạn thêm vào. Trên nginx, .htaccess hoàn toàn vô tác dụng; bạn cần một khối location trong cấu hình máy chủ, mà trên hosting quản lý thì thường phải nhờ bộ phận hỗ trợ.

Hãy sòng phẳng về việc chặn truy cập mang lại gì: file vẫn nằm trên đĩa, trong một thư mục do máy chủ web phục vụ. Một lỗi path traversal ở bất kỳ plugin nào vẫn đọc được nó. Chuyển hẳn ra ngoài thư mục web mới là cách chắc chắn hơn.

Đọc và theo dõi file

Qua SSH, xem trực tiếp trong lúc bạn tái hiện lỗi:

tail -f wp-content/debug.log

Tái hiện lỗi ở tab khác và các dòng mới sẽ hiện ra ngay khi được ghi. Nếu chỉ muốn xem những gì vừa xảy ra, hoặc lọc theo một plugin:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP nối thêm vào cuối file, nên hãy đọc từ dưới lên. Mỗi dòng đều có dấu thời gian theo giờ UTC, không khớp với thiết lập múi giờ trong WordPress của bạn — đừng để điều đó khiến bạn tưởng mình đang xem các dòng cũ.

Với WP-CLI, bạn có thể bật tắt các hằng mà không cần sửa file bằng tay:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Cờ --raw rất quan trọng — thiếu nó thì giá trị được ghi thành chuỗi "true" chứ không phải giá trị boolean. Với dạng đường dẫn thì bỏ --raw đi để nó được ghi thành chuỗi trong dấu nháy.

Không có SSH? Tải file về qua SFTP hoặc mở trong trình quản lý file của hosting. Hãy tránh các plugin hiển thị log ngay trong wp-admin trừ khi bạn hoàn toàn tin tưởng chúng; bạn đang trao cho một plugin quyền đọc một file đầy nội tình máy chủ.

Nếu bạn muốn có sẵn đoạn wp-config đúng cho cấu hình của mình, kèm một đường dẫn an toàn nằm ngoài thư mục web và luật máy chủ tương ứng, trình tạo debug log cho WordPress sẽ dựng giúp bạn.

Tắt đi khi đã xong việc

Không có gì trong lõi WordPress xoay vòng hay cắt bớt debug.log. Trên một trang phát sinh notice ở mỗi lượt tải trang, file này phình to vô giới hạn và có thể lấp đầy đĩa — điều đó kéo trang sập còn nặng hơn con lỗi mà bạn đang truy tìm. Hãy bật ghi log, tái hiện sự cố, đọc log, rồi đặt WP_DEBUG về lại false.

Để làm rỗng file mà không xóa nó:

: > wp-content/debug.log

Khi log cứ trống trơn

Hãy lần lượt kiểm tra theo thứ tự sau. WP_DEBUG đang là false — nguyên nhân phổ biến nhất, và nó âm thầm vô hiệu hóa mọi thứ còn lại. Hằng nằm dưới dòng “stop editing” trong wp-config.php. Quyền file — PHP không ghi được vào wp-content, hoặc vào thư mục tùy chỉnh bạn đã chỉ định. Một lỗi nghiêm trọng xảy ra trước khi wp-config nạp xong, chẳng hạn lỗi cú pháp trong chính file cấu hình, xảy ra quá sớm để cơ chế ghi log của WordPress bắt được; những lỗi đó đi vào log lỗi PHP của máy chủ. Nhà cung cấp hosting ghi đè thiết lập của bạn — một số nền tảng quản lý cố định thiết lập error_log của PHP hoặc chuyển hướng log vào bảng điều khiển riêng của họ, khi đó cấu hình của bạn hoàn toàn đúng mà kết quả chỉ đơn giản là nằm ở chỗ khác. Hãy xem trình đọc log của nhà cung cấp hosting trước khi kết luận cấu hình của mình bị sai.