Thông báo bảo trì xuất hiện ngay sau một lần cập nhật plugin. Người quản trị chờ thêm, tải lại trang rồi định xóa file vừa nhìn thấy trong thư mục website. Nhưng trước khi sửa gì, cần biết tiến trình cập nhật đã kết thúc chưa và thông báo đang được tạo ở đâu. Xử lý WordPress kẹt chế độ bảo trì là một bài toán xác định trạng thái, không chỉ tìm cách làm dòng chữ biến mất.
Hướng dẫn này dành cho chủ website và người phụ trách bàn giao sự cố. Các tình huống bên dưới là ví dụ giả định, không phải báo cáo lỗi của một khách hàng Onter. Mục tiêu là phục hồi đúng phạm vi, giữ dữ liệu và tránh chạy lại một cập nhật còn chưa rõ kết quả.
Trước tiên, website đang được cập nhật hay đã dừng giữa chừng?
Hãy hỏi người vừa thao tác: cập nhật thành phần nào, bắt đầu lúc nào và giao diện có thông báo hoàn tất không. Một trang quản trị đứng yên chưa chứng minh tiến trình phía sau đã dừng. Đóng tab cũng không phải cách xác nhận server đã hủy công việc.
Nếu một đồng nghiệp đang cập nhật, thống nhất một đầu mối xử lý. Hai người cùng bấm cập nhật hoặc cùng thay file khiến việc đối chiếu khó hơn. Ghi lại phiên bản trước, phiên bản dự kiến và thông báo cuối cùng đã nhìn thấy. Không đưa mật khẩu hay dữ liệu khách hàng vào ảnh chụp trao đổi.
Chưa rõ trạng thái thì dừng thao tác ghi mới, nhưng vẫn có thể thu thập bằng chứng chỉ đọc. Đây là khác biệt quan trọng: tạm ngừng bấm nút không đồng nghĩa bỏ mặc website. Người vận hành có thể kiểm tra màn hình cập nhật, thời điểm log và trạng thái dịch vụ trong đúng phạm vi được giao.
WordPress kẹt chế độ bảo trì có thể là ba hiện tượng khác nhau
Ở cơ chế core, WordPress kiểm tra file .maintenance tại thư mục gốc. Tài liệu hàm wp_is_maintenance_mode() mô tả việc dùng thời điểm trong biến $upgrading; mốc đủ mười phút được coi là hết chế độ bảo trì theo phép kiểm này. Không nên hiểu thành mọi trang bảo trì đều tự biến mất sau mười phút.
Một plugin có thể trình bày trang bảo trì theo cơ chế riêng. Một lớp cache cũng có thể tiếp tục trả bản thông báo đã nhận trước đó. Cả ba cùng hiện chữ “bảo trì” nhưng người chịu trách nhiệm và cách xử lý khác nhau. Tên file hay ảnh chụp đơn lẻ chưa phân biệt được chúng.
Vì vậy, câu hỏi hữu ích là: phản hồi đang đến từ WordPress core, công cụ bảo trì có chủ đích hay một bản lưu trung gian? Nếu đội kỹ thuật xác nhận core đã ra khỏi bảo trì nhưng người ngoài vẫn thấy trang cũ, hãy chuyển sang kiểm tra đường phục vụ phản hồi thay vì tiếp tục sửa file core.
Đọc phản hồi thật, đừng chỉ nhìn dòng chữ
Theo tài liệu wp_maintenance(), đường xử lý core mặc định trả trạng thái 503 cùng header Retry-After. Tài liệu cũng nêu khả năng dùng drop-in maintenance.php để thay thông báo. Đây là mô tả của core, không bảo đảm mọi plugin hoặc proxy đều trả cùng mã.
Nhờ người kỹ thuật ghi lại URL, thời điểm và HTTP status của một phản hồi đại diện. So trang chủ với một bài viết đã tồn tại; không quét toàn bộ website khi server đang gặp khó. Một request có kiểm soát thường cho thông tin tốt hơn việc nhiều người cùng tải lại liên tục.
Nếu trang hiển thị thông báo nhưng trả 200, chưa thể kết luận WordPress đang khỏe. Nếu phản hồi là 503, cũng chưa đủ để kết luận lỗi database hay website bị tấn công. Mã trạng thái giúp khoanh vùng, còn kết luận cần đối chiếu với lịch cập nhật và nơi tạo phản hồi.
Đối với người làm kinh doanh, bản ghi ngắn gồm “URL nào, thấy gì, lúc nào, ai vừa thay đổi gì” đã rất hữu ích. Tránh gửi nhận định như “hỏng toàn bộ dữ liệu” khi mới chỉ thấy một trang bảo trì. Nhận định quá sớm dễ dẫn đến yêu cầu khôi phục cả website không cần thiết.
Một điểm quyết định trước mỗi thao tác phục hồi
Nếu cập nhật còn hoạt động: để người đang phụ trách theo dõi đúng công việc đó. Không chạy lại cùng cập nhật từ tab khác. Nếu có thời hạn phục vụ khách hàng, thông báo thời gian kiểm tra tiếp theo dựa trên trạng thái đã biết; đừng hứa một số phút không có căn cứ.
Nếu cập nhật đã kết thúc và core còn ở bảo trì: người có quyền vận hành kiểm tra đúng thư mục website, xác nhận file liên quan và chọn cách tắt chế độ bảo trì phù hợp. Không thao tác theo tên file tìm thấy ở một bản staging hoặc một website khác trên cùng máy chủ.
Nếu không chứng minh được cập nhật đã kết thúc: chuyển phần kiểm tra tiến trình cho đơn vị hosting hoặc người quản trị hệ thống. Cung cấp tên thành phần, mốc thời gian và thông báo đã có. Không cần gửi toàn bộ database, tài khoản quản trị hay bản sao dữ liệu khách hàng chỉ để hỏi trạng thái cập nhật.
WP-CLI có nhóm lệnh maintenance-mode cho việc kiểm tra và điều khiển chế độ bảo trì. Người vận hành cần chọn đúng website và đúng quyền trước khi dùng. Lệnh tắt bảo trì làm thay đổi trạng thái; nó không chứng minh cập nhật đã hoàn tất hay sửa được một plugin bị lỗi.
Ví dụ: hai người cùng thấy bảo trì nhưng cần hai cách xử lý
Giả sử quản trị viên đã nhận thông báo cập nhật thành công, trang quản trị mở được và kiểm tra core không còn bảo trì. Một nhân viên vẫn thấy thông báo ở trang chủ. Trong tình huống này, việc tiếp tục tìm file để xóa không giải thích được khác biệt giữa hai đường truy cập. Cần đối chiếu cache hoặc lớp phục vụ trang đang dùng.
Ở tình huống khác, cập nhật bị gián đoạn và trạng thái thành phần chưa xác nhận. Dù có thể làm thông báo biến mất, việc mở website ngay có thể đưa người dùng vào một phiên bản chưa kiểm tra. Ưu tiên lúc này là xác minh thành phần đã được cài đủ và có đường khôi phục đúng phạm vi.
Hai ví dụ cho thấy “trang đã mở lại” và “công việc cập nhật đã được nghiệm thu” là hai mốc riêng. Biên bản xử lý nên giữ cả hai. Nếu chỉ ghi thời điểm mất dòng chữ, đội vận hành có thể bỏ sót lỗi ở form, tìm kiếm hoặc chức năng chỉ xuất hiện sau đăng nhập.
Kiểm tra gì sau khi thông báo không còn?
Bắt đầu từ URL công khai đã dùng làm mốc. Kiểm tra nội dung, ảnh và điều hướng chính ở một phiên truy cập bình thường. Sau đó thử một thao tác đại diện cho chức năng vừa cập nhật trong môi trường phù hợp. Không dùng đơn hàng hoặc thông tin khách hàng thật làm dữ liệu thử ngẫu hứng.
Nếu cập nhật liên quan form, phân biệt việc form nhận dữ liệu với việc email thông báo được gửi. Nếu bài lên lịch bị ảnh hưởng, kiểm tra trạng thái bài thay vì bấm đăng lại ngay. Các hướng dẫn về WordPress không gửi được email và bài lên lịch bị trễ giải thích hai ranh giới này.
Giữ kết quả kiểm tra gắn với phiên bản thành phần đã cập nhật. Nếu có lỗi mới, ghi đúng thao tác tái hiện và phạm vi ảnh hưởng. Không quy tất cả hiện tượng cũ cho lần cập nhật vừa rồi khi chưa có đối chiếu trước sau.
Chuẩn bị lần cập nhật tiếp theo để giảm việc đoán trạng thái
Trước một thay đổi đáng kể, thống nhất người thực hiện, khung thời gian và điều kiện dừng. Tách bản thử với bản đang phục vụ người dùng; bài về ranh giới staging WordPress trình bày vì sao tên môi trường không tự ngăn email hoặc API thật.
Dùng lịch backup hiện có và phương án khôi phục theo thành phần, không mặc định mỗi lần cập nhật đều cần sao chép toàn VPS. Điều quan trọng là biết dữ liệu nào có thể thay đổi và ai chịu trách nhiệm kiểm tra khả năng phục hồi. Website có giao dịch mới cần đặc biệt tránh khôi phục database cũ một cách rộng tay.
Một bản bàn giao tốt kết thúc bằng trạng thái đã xác minh: cập nhật nào hoàn tất, chế độ bảo trì nào đã tắt, URL nào mở lại và chức năng nào đã thử. Nếu cần Onter đánh giá phạm vi bảo trì hoặc bàn giao website, hãy gửi mô tả đã bỏ dữ liệu riêng tư qua trang liên hệ. Phạm vi xử lý được xác định sau khi đối chiếu hệ thống cụ thể.
