Sửa lỗi WordPress bằng mã HTTP để khoanh vùng 4 lỗi hay gặp

Sửa lỗi WordPress nhanh nhất khi bạn biết lỗi nằm ở tầng nào: cơ sở dữ liệu, máy chủ web, hay một plugin. Mã HTTP mà trang trả về cho biết điều đó trước cả khi bạn mở tệp nào.

Mình dựng một bản sao WordPress 7.1 tiếng Việt trên máy (Apache, MySQL 8.4), tự gây ra bốn lỗi hay gặp, đo mã HTTP ở từng trang, chụp đúng trang lỗi, rồi sửa và đo lại. Mọi mã HTTP và thông báo trong bài là thứ máy trả về thật.

Sửa lỗi WordPress, bước đầu tiên: đo mã HTTP ở ba chỗ

Chạy lệnh này, thay bằng địa chỉ site của bạn và một bài bất kỳ:

for u in https://ten-mien-cua-ban/ https://ten-mien-cua-ban/wp-admin/ https://ten-mien-cua-ban/duong-dan-mot-bai/; do curl -s -o /dev/null -w "%{http_code} $u\n" "$u"; done

Kết quả đo được với bốn lỗi mình gây ra:

1. 1Trang chủ 500, wp-admin 500, trang bài 500, trang ghi "Lỗi kết nối tới cơ sở dữ liệu": xem lỗi 1.
2. 2Trang chủ 503, wp-admin 503, trang ghi "đang được bảo dưỡng": xem lỗi 2.
3. 3Trang chủ 200 nhưng trang bài 404, trang 404 là trang trơn của máy chủ, không có giao diện theme: xem lỗi 3.
4. 4Trang chủ 500, trang ghi "Đã có một lỗi nghiêm trọng": xem lỗi 4.

Lỗi 1: lỗi kết nối cơ sở dữ liệu WordPress

Mình đổi mật khẩu cơ sở dữ liệu trong wp-config.php thành một mật khẩu sai. Cả site sập: trang chủ, wp-admin, trang bài đều 500.

Bản WordPress tiếng Anh ghi "Error establishing a database connection". Site không đọc được cơ sở dữ liệu nên không trang nào mình đo chạy được, kể cả wp-admin.

Cách sửa: mở wp-config.php ở thư mục gốc, kiểm bốn dòng này có khớp với thông tin cơ sở dữ liệu hosting cấp cho bạn không:

define( 'DB_NAME', '...' );
define( 'DB_USER', '...' );
define( 'DB_PASSWORD', '...' );
define( 'DB_HOST', '...' );

Trên site thử, trả lại đúng mật khẩu thì trang chủ về 200 ngay.

Lỗi 2: WordPress kẹt chế độ bảo trì

Khi cập nhật, WordPress tạo một tệp .maintenance ở thư mục gốc và xoá nó khi xong. Cập nhật bị ngắt giữa chừng thì tệp có thể nằm lại. Mình tạo lại đúng tệp đó:

• Trang chủ 503, wp-admin 503.

Bản tiếng Anh ghi "Briefly unavailable for scheduled maintenance. Check back in a minute."

Tệp này chứa thời điểm bắt đầu bảo trì. Mình đo xem WordPress chờ bao lâu thì tự bỏ qua nó:

• Thời điểm lùi về 590 giây trước: vẫn 503.
• Lùi về 601 giây trước: trang chủ 200.

Tức là sau khoảng 10 phút, WordPress tự bỏ qua tệp bị bỏ lại. Không muốn chờ, hoặc site vẫn 503 quá 10 phút, thì xoá tệp:

rm .maintenance

Tên tệp bắt đầu bằng dấu chấm; nếu trình quản lý tệp của bạn không thấy nó, thử bật chế độ hiện tệp ẩn. Trên site thử, xoá xong trang chủ về 200. Trước khi dùng lại site, kiểm trang Cập nhật trong wp-admin xem lần cập nhật dở dang kia đã xong chưa.

Lỗi 3: lỗi 404 bài viết WordPress dù trang chủ vẫn chạy

Mình đưa tệp .htaccess ra khỏi thư mục gốc. Kết quả lạ nhưng rất đặc trưng:

• Trang chủ 200, ảnh 200.
• Mọi trang bài 404.

Hãy nhìn kỹ trang 404: đây là trang của máy chủ Apache, không phải trang 404 có giao diện của theme. Nghĩa là yêu cầu không tới được WordPress. Site dùng đường dẫn tĩnh đẹp (kiểu ngày và tên bài) cần .htaccess để chuyển mọi đường dẫn như vậy về cho WordPress xử lý.

Cách sửa lỗi permalink WordPress kiểu này:

1. 1Nếu còn bản sao lưu .htaccess, trả nó về chỗ cũ. Trên site thử, trả lại xong thì bài về 200.
2. 2Nếu không có, vào wp-admin, mở trang Cài đặt cấu trúc đường dẫn (wp-admin/options-permalink.php), không đổi gì, bấm nút lưu ở cuối trang. Ở bài Chuyển hosting WordPress, mình đã đo: bấm lưu ở đó thì WordPress ghi lại .htaccess, còn lệnh wp rewrite flush --hard chạy từ dòng lệnh thì không ghi lại tệp.

Lỗi này là chuyện của Apache và .htaccess. Máy chủ Nginx cấu hình theo cách khác; mình chưa thử.

Lỗi 4: lỗi nghiêm trọng WordPress do plugin

Mình tạo một plugin thử gọi một hàm không tồn tại. Trang chủ 500. Cuối trang có câu chuẩn của WordPress "Đã có một lỗi nghiêm trọng trên trang web của bạn." (bản tiếng Anh: "There has been a critical error on this website.").

Nhưng phía trên câu đó còn một khối chữ mà người xem không nên thấy:

Đó là chi tiết lỗi của PHP, gồm cả đường dẫn đầy đủ trên máy chủ. Mình gọi trang bằng curl, không đăng nhập, vẫn thấy hết. Nguyên nhân đo được: PHP mà Apache dùng trên máy thử có display_errors bằng 1, dù wp-config.php đặt WP_DEBUG là false. Nghĩa là tắt WP_DEBUG chưa đủ để giấu chi tiết lỗi; display_errors của PHP phải tắt. Chỗ tắt nằm trong cấu hình PHP của hosting; mình chưa đổi cấu hình này trên máy thử.

Lần đầu gây lỗi, plugin Query Monitor còn đang bật, và trang lỗi hiện một khung đỏ riêng của nó, cũng lộ đường dẫn máy chủ:

Cách sửa lỗi WordPress kiểu này: đổi tên thư mục plugin WordPress gây lỗi để nó không được nạp nữa:

mv wp-content/plugins/plugin-gay-loi wp-content/plugins/plugin-gay-loi-TAT

Trên site thử, trang chủ về 200 ngay. Danh sách plugin sau đó hiện plugin-gay-loi-TAT ở trạng thái không kích hoạt: đổi tên thư mục chỉ tắt plugin, không xoá.

Không biết plugin nào gây lỗi thì đọc nhật ký lỗi trước. Cách bật và đọc nhật ký an toàn nằm ở bài Lỗi 500 WordPress: đọc debug log khi không vào được wp-admin.

Với lỗi nghiêm trọng, WordPress có gửi thư "chế độ khôi phục" cho quản trị viên. Mình chưa kiểm được thư này, vì máy thử không gửi được thư ra ngoài. Nếu site thật của bạn cũng không nhận được thư nào từ WordPress, xem bài WordPress không gửi được email dù wp_mail trả true.

Những gì mình chưa kiểm

• Chưa tái hiện lỗi hết bộ nhớ, lỗi quyền tệp, lỗi chuyển hướng vòng lặp, lỗi tải tệp lên.
• Chưa thử trên Nginx.
• Chưa kiểm thư chế độ khôi phục.

Trước khi sửa lỗi WordPress theo bất kỳ cách nào có đụng tới tệp hay cơ sở dữ liệu, sao lưu đủ hai phần theo bài Khôi phục website WordPress.