WordPress Critical Error / White Screen: Cách xử lý và phục hồi an toàn

WordPress Critical Error hoặc White Screen thường xuất hiện khi PHP gặp fatal error hoặc một extension làm request không thể hoàn tất. Đây là symptom, không phải root cause. Cách xử lý an toàn là xác định phạm vi, giữ log/recovery point, dùng Recovery Mode khi có thể và cô lập change hoặc extension gây lỗi thay vì vô hiệu hóa ngẫu nhiên.

Tóm tắt: Kiểm tra email Recovery Mode, PHP/application log, recent update, plugin/theme và compatibility PHP; nếu incident bắt đầu sau change, rollback có kiểm soát; sau khi site hoạt động lại, smoke test và tái hiện trên staging.

Critical Error và White Screen khác nhau thế nào?

WordPress hiện có cơ chế fatal error handler và Recovery Mode cho một số lỗi nghiêm trọng. “There has been a critical error on this website” là thông báo người dùng có thể thấy khi WordPress phát hiện fatal error; White Screen là symptom giao diện trống hoặc request không render nội dung.

Cả hai đều cần log và context để xác định nguyên nhân; không thể kết luận “do plugin” chỉ từ symptom.

Những nguyên nhân thường gặp

• plugin/theme fatal error;
• PHP version không tương thích;
• function/class conflict;
• memory/resource issue;
• file thiếu hoặc permission lỗi;
• database/application dependency;
• custom code sau deploy;
• update core/plugin/theme vừa thực hiện.

Bước 1: kiểm tra phạm vi

Frontend lỗi nhưng admin vẫn vào được hay toàn site chết? Chỉ một URL hay mọi request? Có HTTP 500 không? Nếu lỗi thuộc nhóm 5xx diện rộng, xem quy trình triage lỗi 500/502/503/504.

Bước 2: kiểm tra Recovery Mode

WordPress Recovery Mode có thể gửi email chứa link đăng nhập đặc biệt để tạm pause extension gây fatal error trong phiên recovery. Đây là cơ chế hỗ trợ điều tra, không phải “fix tự động”. Email recovery phải đi tới đúng địa chỉ quản trị và không nên chia sẻ link ra ngoài đội có quyền.

Bước 3: đọc log trước khi thay đổi nhiều thứ

PHP error log, application log và timestamp giúp xác định file, function hoặc extension liên quan. Nếu xóa log hoặc thay nhiều plugin cùng lúc, bạn mất bằng chứng để kết nối incident với recent change.

Bước 4: đối chiếu recent change

Nếu lỗi xuất hiện ngay sau update, deploy hoặc thay PHP, ưu tiên flow WordPress lỗi sau cập nhật: freeze, xác định version trước/sau và rollback có kiểm soát nếu phù hợp.

Bước 5: cô lập extension gây lỗi

Nếu log/Recovery Mode chỉ ra plugin hoặc theme, cô lập đúng extension đó thay vì tắt toàn bộ hệ thống một cách mù quáng. Trước khi disable hoặc rollback, kiểm tra dependency và chức năng business mà extension đang phục vụ.

Bước 6: kiểm tra PHP compatibility

Một plugin cũ có thể chạy ở phiên bản PHP trước nhưng fatal sau khi PHP nâng cấp. Xem vòng đời WordPress, theme và PHP để quản lý compatibility thay vì giữ stack cũ vô thời hạn.

Khi nào restore backup?

Restore toàn site chỉ nên dùng khi recovery path nhỏ hơn không đủ hoặc dữ liệu/code đã hỏng. Cần xác định recovery point đã được kiểm tra và bảo toàn dữ liệu mới phát sinh trước khi restore.

Smoke test sau recovery

• frontend và admin;
• form;
• checkout/order;
• email;
• API/webhook;
• cron/background job;
• error log;
• 5xx rate;
• cache/CDN nếu liên quan.

Những việc không nên làm

• update hàng loạt plugin khi đang Critical Error;
• xóa log trước khi đọc;
• restore backup cũ mà không kiểm tra dữ liệu mới;
• đổi PHP nhiều phiên bản liên tục trên production;
• tắt tất cả plugin mà không ghi trạng thái ban đầu;
• coi việc homepage mở lại là đủ.

Khi nào đây là một Incident Response thực sự?

Nếu Critical Error làm toàn site hoặc checkout ngừng hoạt động, kéo dài, không có workaround hoặc không xác định được owner/change, hãy điều phối theo Website Incident Response thay vì troubleshooting ad-hoc.

Phòng ngừa Critical Error tái diễn

• test update trên staging;
• quản lý plugin/theme lifecycle;
• giữ backup/recovery point;
• deploy từng change có thể truy vết;
• monitor 5xx và error log;
• có rollback criteria;
• không để plugin hết vòng đời kéo dài.

Khi nào nên gọi hỗ trợ?

Nếu không vào được admin, Recovery Mode không đến, không có log/quyền hosting hoặc site đang mất giao dịch, xem dịch vụ sửa lỗi website khẩn cấp để triage trước khi tiếp tục thay đổi.

FAQ

Critical Error có luôn do plugin không?

Không. Theme, PHP, custom code, memory, database hoặc dependency khác đều có thể gây fatal error.

Recovery Mode có luôn gửi email không?

Không nên giả định. Việc gửi email còn phụ thuộc cấu hình email và lỗi có được WordPress xử lý theo Recovery Mode hay không.

White Screen có phải lỗi 500?

Có thể, nhưng không phải mọi White Screen đều được người dùng nhìn thấy dưới dạng mã 500. Cần kiểm tra HTTP response và log.

Đọc tiếp trong cụm Website Incident Response

• Website Incident Response: framework chung để điều phối severity, containment và recovery.
• WordPress lỗi sau cập nhật: xử lý change incident và rollback version.
• Website lỗi 500/502/503/504: xác định khi fatal error biểu hiện thành HTTP 500 hoặc lỗi upstream.
• Website bị down: triage khi lỗi làm mất truy cập rộng hơn WordPress.
• Staging WordPress: tái hiện lỗi và kiểm thử fix ngoài production.

Kết luận

Critical Error và White Screen cần được xử lý như symptom của một failure trong WordPress/PHP stack. Recovery nhanh nhất thường đến từ việc giữ timeline rõ, đọc log, dùng Recovery Mode khi có thể và rollback đúng change thay vì thử nhiều thay đổi không kiểm soát.

Nguồn tham khảo: WP_Fatal_Error_Handler và WP_Recovery_Mode.