Thông báo đã có lỗi nghiêm trọng trên trang web này nghĩa là gì?

Nghĩa là PHP gặp lỗi nghiêm trọng khi đang dựng trang, và WordPress đã chặn lại trước khi màn hình trắng xuất hiện. Dòng thông báo được viết mơ hồ có chủ đích để khách truy cập không nhìn thấy đường dẫn tệp và mã nguồn. Lỗi thật, kèm tên tệp và số dòng, được ghi vào một tệp log trên máy chủ.

Log lỗi nghiêm trọng của WordPress nằm ở đâu?

Nếu bạn đặt WP_DEBUG và WP_DEBUG_LOG thành true trong wp-config.php, WordPress sẽ ghi vào wp-content/debug.log. Nếu hai hằng đó đang tắt, lỗi vẫn được ghi vào log lỗi PHP của nhà cung cấp hosting, thường xem được trong bảng điều khiển hosting ở mục logs hoặc error logs. Hãy kiểm tra cả hai nơi trước khi kết luận là không có gì được ghi lại.

Vì sao tôi không nhận được email chế độ khôi phục của WordPress?

Email được gửi tới địa chỉ quản trị viên khai báo trong Cài đặt, không phải địa chỉ bạn dùng để đăng nhập, và nó được gửi bởi chính tiến trình PHP vừa sập nên thường gửi không thành công. Nhiều hosting chia sẻ cũng chặn mail đi nếu chưa cấu hình SMTP. Hãy kiểm tra hộp thư rác, sau đó bỏ qua email và tắt plugin qua SFTP.

Làm sao sửa lỗi nghiêm trọng khi không đăng nhập được vào wp-admin?

Kết nối bằng SFTP hoặc trình quản lý tệp của hosting rồi đổi tên thư mục wp-content/plugins thành plugins-off. Thao tác này vô hiệu hóa toàn bộ plugin cùng lúc và hầu như luôn khôi phục được quyền vào trang quản trị. Đổi tên lại như cũ, rồi kích hoạt từng plugin một cho tới khi lỗi quay lại, đó chính là thủ phạm.

Việc nâng cấp phiên bản PHP có thể gây lỗi nghiêm trọng trong WordPress không?

Có, và đây là một trong những nguyên nhân phổ biến nhất. Nhà cung cấp hosting tự động nâng cấp PHP, còn mã plugin hoặc theme cũ dùng cú pháp đã bị loại bỏ sẽ chết ngay lập tức. Dòng log thường chỉ đích danh một tệp trong wp-content. Hạ PHP về phiên bản cũ trong bảng điều khiển hosting giúp xác nhận chẩn đoán, nhưng chỉ là giải pháp tạm thời.

Thông báo lỗi nghiêm trọng có nghĩa là trang web của tôi bị hack không?

Thường là không. Phần lớn trường hợp là do bản cập nhật plugin hoặc theme không tương thích với phiên bản PHP, hoặc do hết bộ nhớ. Mã độc cũng có thể gây lỗi nghiêm trọng, nhưng khi đó dòng log sẽ trỏ tới một tệp lạ hoặc mã bị làm rối. Hãy đọc log trước khi kết luận là bị xâm nhập.

Đã có lỗi nghiêm trọng trên trang web này: Thông báo đó nghĩa là gì và cách xử lý

Dòng thông báo đó nghĩa là PHP gặp lỗi nghiêm trọng khi đang dựng trang, và WordPress đã chặn lại trước khi nó biến thành một màn hình trắng trơn. Lỗi là có thật, rất cụ thể và đã được ghi lại — WordPress chỉ từ chối in nó ra trình duyệt, vì một stack trace nằm trên trang công khai sẽ để lộ đường dẫn tệp và mã nguồn cho bất kỳ ai ghé qua.

Nên cách xử lý không bao giờ là đoán mò. Cách xử lý là: đọc đúng lỗi thật, rồi làm theo những gì nó chỉ ra.

Thực chất chuyện gì đang xảy ra

Từ WordPress 5.2, phần lõi đã có sẵn một bộ xử lý lỗi nghiêm trọng. Khi PHP chết giữa chừng một request, bộ xử lý này nhảy vào, thay phần thông tin sập bằng một câu chung chung lịch sự, và — nếu đoán được plugin hay theme nào gây ra — nó cố gửi email cho quản trị viên kèm đường dẫn vào chế độ khôi phục.

Đó là lý do bạn nhìn thấy thông báo này thay vì màn hình trắng chết chóc ngày xưa. Đây là một cải tiến, nhưng cũng có nghĩa là thông tin chẩn đoán bị giấu đi theo mặc định. Thông báo có ba biến thể:

Bạn nhìn thấy gì	Ở đâu	Nó cho bạn biết điều gì
”Đã có lỗi nghiêm trọng trên trang web này.”	Giao diện ngoài, khi đã đăng xuất	Có lỗi nghiêm trọng, không lộ thêm chi tiết nào
Cùng câu trên kèm “Tìm hiểu thêm về khắc phục sự cố WordPress”	Giao diện ngoài hoặc wp-admin	Vẫn lỗi đó, WordPress đang mời bạn đọc trang tài liệu
”…Vui lòng kiểm tra hộp thư của email quản trị viên để xem hướng dẫn.”	Giao diện ngoài	Bộ xử lý tin rằng nó đã gửi được email khôi phục

Biến thể thứ ba là biến thể hữu ích nhất. Nó có nghĩa là WordPress đã quy trách nhiệm sự cố cho một plugin hoặc theme cụ thể và đã cố mở cho bạn một lối vào.

Bước 1: kiểm tra email chế độ khôi phục

WordPress gửi liên kết khôi phục tới địa chỉ email quản trị của trang — địa chỉ khai báo trong Cài đặt, Tổng quan — thường không phải địa chỉ bạn dùng để đăng nhập. Hãy mở hộp thư đó, và nhớ xem cả thư rác.

Email chứa một liên kết dài kết thúc bằng đại loại ?action=enter_recovery_mode. Mở nó ra là bạn vào thẳng wp-admin ở chế độ khôi phục, nơi plugin hoặc theme gây lỗi đã bị tạm dừng và được đánh dấu bằng một thông báo đỏ ở phía trên. Từ đó bạn vô hiệu hóa nó như bình thường.

Hai điều cần nói thẳng. Thứ nhất, email được tạo ra bởi chính tiến trình PHP vừa sập, trên một máy chủ có thể không có kênh gửi mail nào hoạt động — chuyện thư không tới là rất phổ biến, và việc không nhận được thư chẳng nói lên điều gì về bản chất lỗi. Thứ hai, liên kết khôi phục có hạn sử dụng (mặc định khoảng một ngày), nên một email cũ trong hộp thư có thể đơn giản là đã hết hiệu lực; hãy tải lại trang để kích hoạt lỗi lần nữa và chờ email mới.

Nếu bạn muốn email được gửi tới nơi mình thực sự đọc, hãy khai báo rõ trong wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Bước 2: đọc lỗi thật

Đây là bước biến một trang web hỏng thành việc sửa trong năm phút. Thêm các dòng sau vào wp-config.php, phía trên dòng ghi chú yêu cầu dừng chỉnh sửa:

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

Việc đặt WP_DEBUG_DISPLAY thành false rất quan trọng — nó giữ lỗi không hiện ra trình duyệt nhưng vẫn ghi xuống đĩa, nhờ vậy bạn không để lộ đường dẫn cho khách truy cập trong lúc gỡ lỗi.

Tải lại trang bị lỗi một lần, rồi mở wp-content/debug.log. Dòng cuối cùng sẽ trông đại khái thế này:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Đường dẫn tệp chính là câu trả lời. Nếu nó trỏ vào wp-content/plugins/, plugin đó là nguyên nhân. Nếu nó trỏ vào wp-content/themes/, thủ phạm là theme — rất thường là một đoạn mã vừa được dán vào functions.php.

Nếu debug.log không xuất hiện, có thể thư mục không có quyền ghi, hoặc một plugin bảo mật đã chuyển log đi nơi khác. Khi đó hãy quay sang log lỗi PHP của hosting — hầu hết bảng điều khiển đều có mục “Error Log” hoặc “Logs”, và cùng lỗi nghiêm trọng đó sẽ nằm ở đấy kèm dấu thời gian.

Dán dòng log vào công cụ giải mã log lỗi WordPress để dịch ngôn ngữ của PHP sang ý nghĩa thực tế và biết nên mở tệp nào trước.

Xóa các dòng debug này khi bạn đã xong việc. Để WP_DEBUG bật trên môi trường thật sẽ làm đầy ổ đĩa, và nếu WP_DEBUG_DISPLAY bị bật lại, đường dẫn máy chủ sẽ hiện ra công khai.

Bước 3: vào lại wp-admin

Nếu wp-admin cũng chết và không có email khôi phục nào tới, hãy vô hiệu hóa toàn bộ plugin ở mức hệ thống tệp. Kết nối qua SFTP (hoặc trình quản lý tệp của hosting) rồi đổi tên một thư mục:

mv wp-content/plugins wp-content/plugins-off

WordPress không tìm thấy plugin nữa nên vô hiệu hóa tất cả, và quyền vào trang quản trị hầu như luôn trở lại. Sau đó:

Đổi tên thư mục về lại plugins. Mọi thứ vẫn ở trạng thái tắt — WordPress đã ghi nhận chúng là không hoạt động.
Kích hoạt từng plugin một, sau mỗi lần lại tải giao diện ngoài để kiểm tra.
Plugin nào làm lỗi quay lại chính là thủ phạm.

Nếu tắt hết plugin mà trang vẫn hỏng thì theme là nghi phạm. Đổi tên thư mục của theme đang dùng trong wp-content/themes/, WordPress sẽ tự quay về một theme mặc định nếu có sẵn.

Ba nguyên nhân đáng biết

Bản cập nhật plugin hoặc theme gây lỗi nghiêm trọng. Phổ biến hơn hẳn phần còn lại. Log gọi thẳng tên tệp. Hãy hạ plugin đó về phiên bản trước, hoặc cứ để nó tắt và gửi dòng log cho nhà phát triển.

Không khớp phiên bản PHP. Nhà cung cấp hosting nâng cấp PHP theo lịch, đôi khi báo trước rất ít. Mã viết cho PHP cũ có thể không còn phân tích cú pháp được trên phiên bản mới. Dấu hiệu nhận biết là bạn không đổi gì cả mà mọi thứ hỏng cùng lúc. Hạ PHP xuống một phiên bản phụ trong bảng điều khiển hosting là một cách chẩn đoán hợp lệ — nhưng hãy xem đó là mua thêm thời gian, không phải cách sửa. Các phiên bản PHP cũ không còn nhận bản vá bảo mật.

Hết bộ nhớ. Log sẽ ghi “Allowed memory size of X bytes exhausted”. Nâng giới hạn trong wp-config.php là hợp lý:

define( 'WP_MEMORY_LIMIT', '256M' );

Nhưng hãy sòng phẳng về tác dụng của nó: nó gỡ trần bộ nhớ chứ không sửa được nguyên nhân khiến việc dựng một trang ngốn tới 256MB. Nếu giới hạn cứ phải nâng lên mãi thì có thứ gì đó — thường là một tiến trình nhập dữ liệu, một trình dựng trang, hoặc một truy vấn viết ẩu — mới là vấn đề thật.

Những lời khuyên bạn có thể yên tâm bỏ qua

“Cứ tăng giới hạn bộ nhớ lên.” Chỉ liên quan khi log thật sự nói hết bộ nhớ. Ngoài ra nó chẳng thay đổi gì và chỉ che giấu việc bạn chưa hề đọc lỗi.

“Cài lại lõi WordPress.” Tệp lõi hiếm khi là nguyên nhân, và việc thay chúng chỉ tốn thời gian mà lẽ ra bạn dùng để đọc một dòng log.

“Tắt bộ xử lý lỗi nghiêm trọng đi.” Có một hằng để tắt nó, và kết quả là lỗi thô được in thẳng lên trang công khai thay vì bị chặn lại. Điều đó để lộ đường dẫn tệp cho khách truy cập. Hãy dùng WP_DEBUG_LOG cùng với WP_DEBUG_DISPLAY tắt — cùng lượng thông tin, không hề lộ gì.

“Xóa bộ nhớ đệm đi.” Lỗi nghiêm trọng xảy ra trong PHP trước khi plugin cache kịp phục vụ bất cứ thứ gì. Nếu một bản cache của trang lỗi đang được phục vụ thì việc xóa cache chỉ có ích sau khi bạn đã sửa nguyên nhân — không bao giờ thay cho việc đó.

Vẫn bế tắc?

Nếu log trỏ vào một tệp lõi thay vì thứ gì đó trong wp-content, lời giải thích khả dĩ hơn là một plugin nạp trước đó đã phá vỡ trạng thái mà lõi dựa vào, chứ không phải lõi bị hỏng. Hãy tắt hết bằng cách đổi tên thư mục, xác nhận trang tải sạch sẽ, rồi bật lại từng plugin một — plugin cuối cùng bạn bật trước khi lỗi quay lại chính là thứ cần báo cáo, kèm dòng log.