Lỗi trắng trang trong WordPress, giải thích cặn kẽ
Lỗi trắng trang là một lỗi PHP nghiêm trọng mà bạn không nhìn thấy được. WordPress gặp lỗi không thể phục hồi ngay giữa lúc render, PHP dừng lại, và vì phần hiển thị lỗi
Đã đăng
Lỗi trắng trang là một lỗi PHP nghiêm trọng mà bạn không nhìn thấy được. WordPress gặp lỗi không thể phục hồi ngay giữa lúc render, PHP dừng lại, và vì phần hiển thị lỗi bị tắt trên các server production nên trang trả về trắng trơn thay vì in ra nguyên nhân. Cách khắc phục gần như không bao giờ cần đoán mò: bật debug log lên, mở wp-content/debug.log, rồi đọc dòng lỗi nghiêm trọng cuối cùng. Nó chỉ đích danh file gây lỗi — gần như luôn là một plugin hoặc theme — và chỉ một dòng đó là toàn bộ cách sửa.
Vì sao trang lại trắng trơn
PHP có một thiết lập tên là display_errors. Trên máy dev thì nó thường bật, nên khi có lỗi nghiêm trọng, PHP sẽ in một stack trace ra màn hình. Trên hosting thật thì nó mặc định tắt, bởi vì để lộ đường dẫn file và lỗi cho khách truy cập là một vấn đề bảo mật. Vậy nên khi có gì đó ném ra lỗi nghiêm trọng — gọi một hàm không còn tồn tại, một class chưa được load, một lỗi cú pháp trong bản cập nhật plugin — PHP chết và không gửi gì cả. Trình duyệt của bạn render ra một tài liệu rỗng. Đó chính là “trắng trang”.
Từ WordPress 5.2 trở đi có một bộ xử lý lỗi nghiêm trọng (WP_Fatal_Error_Handler) cố gắng bắt các lỗi này. Khi nó hoạt động, bạn không bị trang trắng — mà thấy dòng “Đã có một lỗi nghiêm trọng trên trang web của bạn”, kèm một email gửi tới địa chỉ admin thường chứa lỗi thực tế và một link vào Recovery Mode. Một trang thật sự trắng trơn thường có nghĩa là lỗi đã xảy ra trước khi bộ xử lý đó kịp chạy: một lỗi parse/cú pháp (bị bắt ở thời điểm biên dịch), một must-use plugin bị hỏng, hoặc một lỗi nghiêm trọng trong functions.php của theme đang kích hoạt. Dù là trường hợp nào, nguyên nhân đều được ghi lại ở đâu đó. Bạn chỉ cần bật phần ghi lại đó lên.
Khắc phục, theo thứ tự
1. Bật log lên. Sửa wp-config.php qua SFTP và thêm đoạn này vào phía trên dòng /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_DISPLAY để false giữ cho lỗi không hiện ra trên trang công khai, trong khi WP_DEBUG_LOG ghi chúng vào wp-content/debug.log. Tải lại trang bị lỗi một lần để tạo ra một bản ghi mới.
2. Đọc dòng lỗi nghiêm trọng cuối cùng. Mở wp-content/debug.log và nhìn xuống dưới cùng:
tail -n 30 wp-content/debug.logBạn đang tìm một dòng kiểu như thế này:
[14-Jul-2026 09:12:44 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88Đường dẫn chỉ đích danh thủ phạm: plugins/some-addon. Đó là câu trả lời của bạn. Nếu trace quá dài hoặc thông báo khó hiểu (Allowed memory size exhausted, Cannot redeclare, một tên class bạn không nhận ra), hãy dán nó vào công cụ giải mã error log của chúng tôi — nó lược bỏ phần nhiễu, cho bạn biết đường dẫn đang chỉ tới plugin hay theme nào, và giải thích loại lỗi cụ thể đó nghĩa là gì.
3. Vô hiệu hóa thành phần được nêu tên. Bạn không vào được /wp-admin, nên hãy làm qua SFTP. Đổi tên thư mục của plugin gây lỗi, ví dụ some-addon → some-addon.off. WordPress không thể load một thư mục mà nó không tìm thấy, nên nó sẽ vô hiệu hóa plugin đó và trang hoạt động trở lại. Nếu log chỉ vào theme của bạn, hãy chuyển sang một theme mặc định bằng cách đổi tên thư mục theme đang kích hoạt — WordPress sẽ tự động chuyển về một theme twentytwentysomething đi kèm sẵn.
4. Nếu log không chịu ghi, thì wp-content không có quyền ghi, hoặc lỗi nằm ở tầng server. Hãy kiểm tra PHP error log của hosting thay vào đó:
find . -name "error_log" -newermt "-1 hour"Cùng thông tin, chỉ khác file. Các stack cPanel/Apache thường để một file error_log ở thư mục gốc của site hoặc trong thư mục đang bị lỗi.
Những điều không nên làm
Đừng chỉ tăng memory limit. Lời khuyên được lặp lại nhiều nhất trên mạng là nâng WP_MEMORY_LIMIT lên 256M hoặc 512M. Việc đó chỉ khắc phục được lỗi trắng trang nếu log thực sự ghi Allowed memory size of N bytes exhausted. Nếu lỗi là Call to undefined function, thêm bộ nhớ chẳng giải quyết gì cả — bạn vừa thay đổi một thiết lập một cách ngẫu nhiên và màn hình vẫn trắng. Hãy đọc log trước, rồi mới tăng bộ nhớ nếu bộ nhớ đúng là vấn đề được nêu ra.
Đừng xóa cache rồi coi đó là chẩn đoán. Trang trắng là do PHP chết trên server trước khi có bất kỳ HTML nào tồn tại. Một tài nguyên cache cũ không thể gây ra một tài liệu trắng trơn. (Một plugin cache bị hỏng thì có thể — nhưng log sẽ nêu tên nó, và đó mới là điểm mấu chốt.)
Đừng sửa hay cài lại core WordPress. Lỗi nghiêm trọng gần như không bao giờ nằm trong wp-includes hay wp-admin; nó nằm trong plugin hoặc theme mà log chỉ tới. Cài lại core thì chậm, rủi ro, và chỉ xử lý một triệu chứng mà bạn chưa xác nhận.
Đừng tắt tất cả plugin rồi bật lại từng cái một cách mù quáng. Chia đôi để dò thì có hiệu quả, nhưng đó là con đường chậm. Log cho bạn biết chính xác thư mục nào chỉ trong một bước. Chỉ dùng cách “tắt hết mọi thứ” khi hoàn toàn không có lỗi nào đọc được.
Đừng để display_errors bật trên production. Khi site đã hoạt động trở lại, hãy gỡ các define debug đi (hoặc đặt WP_DEBUG về lại false). Lỗi in ra cho khách truy cập sẽ để lộ đường dẫn của bạn.
Vẫn bí?
Nếu log nêu tên một plugin nhưng vô hiệu hóa nó vẫn không hết trắng trang, thì có một lỗi nghiêm trọng thứ hai nằm dưới lỗi đầu tiên — hãy bật log lại lên và đọc dòng cuối mới; các lỗi nghiêm trọng xếp chồng lên nhau. Nếu chính thông báo đó mới là bức tường chắn, hãy đưa nó vào công cụ giải mã error log để nó dịch loại lỗi và đường dẫn file giúp bạn. Trang trắng chỉ còn là một điều bí ẩn chừng nào log còn tắt.