Nghiệm thu WordPress sau cài đặt: Bài viết, Media, Permalink và Login

Phạm vi thực hành: Ubuntu 24.04 LTS trên VPS thử nghiệm độc lập; tên miền lab lab-cf02.localhost.vn. Chỉ thao tác trên tài sản thuộc quyền quản lý của bạn. Chúng tôi đã thực hiện đo kiểm Media Library, bài viết và phân quyền thông qua REST API (HTTPS) kết hợp truy cập HTTP góc nhìn khách trên LAB-CF-02 lúc 23:54 ngày 30/09/2026 (UTC+7). Sang ngày 01/10, các đợt thực nghiệm kết thúc lúc 17:35:49 và 17:38:19 bổ sung thao tác trực tiếp trên giao diện Media Library, xem trước (preview) bản nháp, đăng nhập/đăng xuất tài khoản admin, mở Dashboard, đọc Site Health và duyệt web như khách vãng lai bằng trình duyệt thật. Đợt chạy kết thúc lúc 18:02:11 cùng ngày đã xác minh thêm vai trò Editor cùng quy trình tạo – sửa – xuất bản bài viết bằng trình soạn thảo khối (Block Editor UI). Tại thời điểm đó Site Health vẫn còn một số cảnh báo cần lưu ý; riêng tính năng gửi/nhận email và biểu mẫu liên hệ sẽ được tách sang các bài chuyên sâu sau.

Dòng chữ “Success! WordPress has been installed” hiện ra trên màn hình luôn mang lại cảm giác rất phấn khích, nhưng với dân làm hạ tầng lâu năm thì đó mới chỉ là lúc… bắt đầu đổ mồ hôi. Thực tế có vô số kịch bản trớ trêu sau khi cài: trang chủ mở lên mượt mà nhưng hễ bấm vào bài viết bất kỳ là văng lỗi 404 Not Found vì quên cấu hình Rewrite Rules trên NGINX; tài khoản Administrator đăng nhập ngon lành nhưng tính năng gửi mail khôi phục mật khẩu hoàn toàn tê liệt; hoặc tải ảnh lên Media Library báo thành công nhưng đường dẫn ảnh ngoài trang khách lại trả về lỗi 403 Forbidden. Thực hiện quy trình nghiệm thu WordPress sau cài đặt (Smoke Test) qua từng hạng mục nhỏ dưới đây sẽ giúp bạn tóm gọn các lỗi ngầm đó ngay từ trong trứng nước, lưu lại bằng chứng rõ ràng và dọn dẹp sạch sẽ dữ liệu nháp trước khi bàn giao.

Chuẩn bị bộ dữ liệu kiểm thử chuẩn chỉnh

Trước tiên, bạn cần có một môi trường lab hoặc Staging độc lập đã cấu hình HTTPS khớp tên miền, kèm theo tài khoản Administrator và tài khoản biên tập (Editor) đã thiết lập ở bài 41. Hãy chuẩn bị sẵn một tấm ảnh dung lượng nhỏ thuộc bản quyền của bạn, đặt tên file rõ ràng không dấu và đảm bảo bên trong ảnh (kể cả dữ liệu EXIF) không chứa thông tin nhạy cảm. Về phần chữ, hãy soạn một tiêu đề rõ ràng kiểu “Bài viết kiểm thử cài đặt lab” kèm vài đoạn văn tiếng Việt có đầy đủ dấu thanh để đánh giá khả năng lưu trữ bảng mã UTF-8 và hiển thị phông chữ ngoài mặt tiền.

Đừng quên ghi chép lại phiên bản WordPress, phiên bản PHP và danh sách các Plugin / Theme đang kích hoạt vào sổ tay vận hành. Nếu bạn vừa tay nhanh cài thêm plugin tạo bộ nhớ đệm (Cache) hoặc tường lửa bảo mật (WAF), hãy đánh dấu đậm vào biên bản bởi chúng cực kỳ hay can thiệp vào luồng xử lý Cookie, REST API cũng như giao diện mà khách truy cập nhìn thấy. Nguyên tắc gỡ rối bất di bất dịch: khi phát hiện lỗi, mỗi lần chỉ thay đổi đúng một thông số cấu hình rồi thử lại ngay để biết chính xác liều thuốc nào thực sự phát huy tác dụng.

Sơ đồ quy trình nghiệm thu do đội ngũ localhost.vn biên soạn; đây là tài liệu hệ thống hóa kiến thức, không phải ảnh chụp màn hình hay bằng chứng thực thi từ máy chủ lab.

Bước 1: đóng vai khách vãng lai mở trang chủ

Hãy mở một cửa sổ trình duyệt ẩn danh (Private/Incognito Window) hoàn toàn chưa đăng nhập vào WordPress và truy cập địa chỉ https://lab-cf02.localhost.vn/. Hãy nhìn kỹ tiêu đề website (Site Title), nội dung nhận diện đặc trưng và thanh địa chỉ URL để chắc chắn 100% rằng bạn đang kết nối vào đúng máy chủ mục tiêu, chứ không phải đang xem nhầm một máy chủ cũ do bộ nhớ đệm DNS trên máy tính chưa cập nhật.

Song song với trình duyệt, hãy mở terminal và gọi lệnh kiểm tra phản hồi HTTP Header:

curl -I https://lab-cf02.localhost.vn/

Kinh nghiệm xương máu là đừng thấy mã phản hồi HTTP/2 200 mà vội mừng rỡ đóng máy! Trong thế giới PHP, đôi khi một trang trắng tinh (White Screen) hoặc một trang đang in cảnh báo lỗi PHP Warning vẫn hồn nhiên trả về status code 200 OK như thường. Vì vậy, bạn bắt buộc phải kết hợp nhìn cả mã phản hồi lẫn đọc nội dung hiển thị thực tế trên trình duyệt. Nếu phát hiện có chuyển hướng (Redirect 301/302), hãy rà soát xem điểm đích cuối cùng có đúng là URL chính thống hay không và có bị rơi vào vòng lặp vô tận (Redirect Loop) hay không. Ngoài ra, vì đây là môi trường lab thử nghiệm nên chúng ta chủ động giữ nguyên chế độ chặn lập chỉ mục (noindex); tuyệt đối đừng bỏ chặn index trên trang nháp chỉ để làm đẹp báo cáo.

Bước 2: tạo mới, lưu nháp, chỉnh sửa và xuất bản một bài viết

Bây giờ, bạn hãy vào giao diện Dashboard tạo một bài viết thử nghiệm, bấm lưu nháp (Save draft) rồi mở chế độ xem trước (Preview). Sau đó, hãy thử sửa lại một câu văn bất kỳ và bấm lưu lần nữa. Nếu quy định của môi trường lab cho phép đăng bài công khai, bạn hãy bấm xuất bản (Publish) để lấy đường dẫn thực tế kiểm tra dưới góc nhìn khách vãng lai; còn nếu đang làm trên môi trường Staging có khóa mật khẩu bảo vệ tầng ngoài, hãy thực hiện trong đúng phạm vi được cấp phép.

Quy trình thao tác chuẩn trên trình soạn thảo khối (Block Editor) như sau: gõ tiêu đề và đoạn văn tiếng Việt có dấu, bấm nút Lưu nháp, sau đó chủ động bấm tải lại toàn bộ trang trình duyệt (Reload / F5) để xem chữ nghĩa có còn nằm nguyên trên màn hình hay không. Tiếp theo, hãy sửa một câu văn, lưu lại và mở tab Xem trước. Khi đã sẵn sàng xuất bản trên lab, bấm nút Xuất bản ở góc phải, kiểm tra kỹ chế độ hiển thị công khai cùng mốc thời gian trong bảng xác nhận trượt ra rồi bấm xác nhận xuất bản lần thứ hai. Ngay lập tức, hãy copy đường dẫn bài viết sang cửa sổ ẩn danh của khách để đối chiếu. Đừng bao giờ chỉ tin vào dòng thông báo nhỏ xíu “Draft saved” ở góc màn hình; thao tác tải lại trang (F5) và nhìn thấy tận mắt câu văn vừa sửa mới là bằng chứng thép xác nhận dữ liệu đã nằm gọn trong MySQL/MariaDB.

Ảnh chụp giao diện thực tế ngày 01/10/2026 trong đợt thực nghiệm tài khoản Editor hoàn tất lúc 18:02:11 (UTC+7), ngay sau thao tác lưu nháp và bấm tải lại trang; giữ nguyên độ phân giải pixel gốc và gắn logo. Đây là trạng thái bản nháp trước khi thực hiện bước sửa câu văn tiếp theo, chưa phải trang bài viết đã xuất bản. Bấm vào ảnh để xem kích thước đầy đủ.

Sau khi bấm F5 làm mới trang Dashboard, hãy đọc kỹ lại từng dấu câu tiếng Việt, hình ảnh đính kèm và các đường link để chắc chắn dữ liệu được tải lên từ cơ sở dữ liệu chứ không phải chỉ đang nằm tạm trong bộ nhớ trình duyệt. Nếu trình soạn thảo Gutenberg bỗng dưng hiện thông báo đỏ chót Updating failed. The response is not a valid JSON response, bạn đừng vội vàng chạy ra terminal gõ lệnh chmod 777 cho thư mục web! Hãy bình tĩnh bấm F12 mở tab Network / Console của trình duyệt để xem mã trạng thái HTTP thực sự của request gửi tới /wp-json/ là gì.

Rất nhiều trường hợp lỗi “JSON không hợp lệ” thực chất là do trình soạn thảo gửi request tới REST API nhưng lại bị một quy tắc tường lửa (WAF), một lệnh chuyển hướng cấu hình sai trong NGINX hoặc một dòng thông báo lỗi PHP chèn ngang trả về mã HTML thay vì chuỗi JSON chuẩn. Hãy ghi chép lại đường dẫn URL và mã lỗi HTTP trong tab Network để truy vết nguyên nhân gốc rễ, nhưng tuyệt đối nhớ xóa hoặc làm mờ các chuỗi Cookie và X-WP-Nonce nếu bạn chụp ảnh màn hình gửi đi hỏi đồng nghiệp.

Ảnh chụp trình duyệt thực tế ngày 01/10/2026 trong đợt xác minh media hoàn tất lúc 17:35:49 (UTC+7); giữ nguyên pixel gốc và gắn logo ở chân ảnh. Bản nháp này được khởi tạo thông qua REST API có xác thực rồi mở xem trước trên trình duyệt, không phải bằng chứng thao tác gõ/lưu/xuất bản qua giao diện Block Editor. Đây là màn hình Preview khi đang đăng nhập, không phải đường dẫn công khai cho khách. Bấm vào ảnh để xem đầy đủ.

Bước 3: sát hạch đường dẫn tĩnh (Permalink) và bẫy 404 kinh điển trên NGINX

Với một website mới dựng như trong bài này, bạn hãy truy cập vào Settings → Permalinks (Cài đặt → Đường dẫn tĩnh), chọn cấu trúc đường dẫn thân thiện với người đọc và công cụ tìm kiếm — phổ biến nhất cho site tin tức/blog là Post name (Tên bài viết) — rồi bấm lưu lại. (Lưu ý: nếu bạn đang tiếp quản một website cũ đã có hàng trăm bài viết được Google lập chỉ mục từ lâu, tuyệt đối không đổi cấu trúc Permalink tùy tiện khi chưa thiết lập bảng ánh xạ chuyển hướng Redirect 301 đầy đủ).

Sau khi lưu cấu trúc đường dẫn đẹp (Pretty Permalinks), hãy mở lại bài viết vừa xuất bản ở Bước 2 trong cửa sổ ẩn danh. Nếu trang chủ vẫn lên bình thường mà bấm vào bài viết lại đập vào mắt lỗi 404 Not Found của NGINX, thủ phạm đến 99% nằm ở khối điều hướng trong cấu hình Virtual Host của NGINX:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Một sự thật mà nhiều bạn mới chuyển từ Shared Hosting (chạy Apache/LiteSpeed) sang quản trị VPS hay quên: NGINX hoàn toàn không đọc và không quan tâm tới tập tin .htaccess của Apache! Vì vậy, dù bạn có vào trong Dashboard bấm nút “Save Changes” ở trang Permalinks đến chục lần để ép WordPress sinh lại Rewrite Rules trong .htaccess thì NGINX vẫn sẽ ngơ ngác trả về lỗi 404 nếu thiếu chỉ thị try_files $uri $uri/ /index.php?$args; trong block cấu hình server. Sau khi bổ sung đúng chỉ thị này vào file cấu hình NGINX, hãy luôn chạy cặp lệnh an toàn sudo nginx -t && sudo systemctl reload nginx để chỉ nạp lại cấu hình khi cú pháp đã chuẩn 100%, rồi mở lại đường dẫn bài viết vừa bị lỗi để tận hưởng thành quả.

Chưa hết, hãy làm thêm một phép thử ngược: gõ bừa một đường dẫn chắc chắn không tồn tại trên site (ví dụ /duong-dan-nay-khong-he-ton-tai-12345). Một hệ thống chuẩn chỉnh phải trả về giao diện trang báo lỗi 404 kèm theo mã trạng thái HTTP đúng là 404 Not Found, chứ không phải cấu hình sai tới mức đường dẫn rác nào cũng trả về nội dung trang chủ kèm mã 200 OK (Soft 404) — một thảm họa thực sự cho cả trải nghiệm người đọc lẫn SEO.

Sơ đồ chẩn đoán lỗi theo triệu chứng do localhost.vn biên soạn; đây là hình vẽ hướng dẫn tư duy gỡ rối, không phải ảnh chụp màn hình hay kết quả chạy lệnh trên lab.

Bước 4: nghiệm thu luồng Media Library từ lúc tải lên đến lúc hiển thị

Tiếp theo, bạn hãy tải tấm ảnh chuẩn bị sẵn lên Media Library (Thư viện Media), bấm mở cửa sổ chi tiết của tập tin đính kèm (Attachment Details) để kiểm tra đường dẫn tĩnh của file ảnh cũng như việc hệ thống có cắt (crop/resize) ra đủ các kích thước ảnh thu nhỏ (thumbnails) hay không. Sau đó, hãy chèn tấm ảnh vào bài viết và mở xem dưới góc nhìn khách vãng lai trên cả màn hình máy tính rộng lẫn màn hình điện thoại hẹp. Hãy xác nhận bức ảnh tải lên mượt mà, giữ đúng tỷ lệ khung hình (aspect ratio) và không đâm thủng lề trang web.

Nếu ngay từ bước tải ảnh lên đã văng thông báo lỗi, bạn hãy áp dụng đúng quy trình chẩn đoán ở bài 40: rà soát chủ sở hữu và nhóm (owner/group), quyền ghi của thư mục wp-content/uploads theo từng năm/tháng, dung lượng ổ cứng cùng số lượng inode còn trống, và giới hạn kích thước tải lên (client_max_body_size trong NGINX cùng upload_max_filesize / post_max_size trong PHP). Ngược lại, nếu file ảnh đã nằm gọn trên ổ cứng nhưng ngoài trình duyệt lại hiển thị biểu tượng ảnh vỡ, hãy kiểm tra đường dẫn URL, lỗi trộn lẫn giao thức HTTP/HTTPS (Mixed Content) và mã phản hồi HTTP trực tiếp của file ảnh đó trước. Tuyệt đối không hoảng loạn đi đổi quyền toàn bộ cây thư mục mã nguồn WordPress.

Khi điền văn bản thay thế (Alt Text) cho ảnh, hãy mô tả ngắn gọn, tự nhiên đúng thông tin mà bức ảnh truyền tải cho người đọc (và trình đọc màn hình của người khiếm thị), tránh thói quen nhồi nhét từ khóa SEO một cách vô hồn. Những hình ảnh thuần túy mang tính trang trí đường viền có thể để trống thuộc tính alt theo chuẩn trợ năng. Riêng với hệ thống tài liệu kỹ thuật như chuỗi bài này, chúng tôi luôn phân biệt rạch ròi trong chú thích đâu là sơ đồ biên soạn minh họa và đâu là ảnh chụp màn hình thực nghiệm trên máy chủ.

Trong đợt chạy giao diện ngày 01/10, chúng tôi đã nhập văn bản Alt Text tiếng Việt vào ô chi tiết ảnh trong Media Library, chờ lưu xong rồi đóng lại và tải lại trang để đối chiếu. Bạn cũng nên tập thói quen này: việc dòng chữ đang nằm trong ô input lúc bạn vừa gõ xong chưa chứng tỏ yêu cầu lưu ngầm (AJAX) phía sau đã ghi thành công vào cơ sở dữ liệu.

Ảnh chụp giao diện thực tế ngày 01/10/2026 của đợt thực nghiệm hoàn tất lúc 17:35:49, sau khi lưu thuộc tính Alt Text và tải lại trang để đối chiếu; giữ nguyên pixel gốc và gắn logo. Hình sơ đồ hiển thị bên trong khung preview chính là tập tin ảnh mẫu được chúng tôi upload để thử nghiệm tính năng Media, không phải một bức ảnh chụp màn hình thao tác phân quyền file khác. Bấm vào ảnh để xem kích thước đầy đủ.

Bước 5: xác minh luồng đăng nhập, đăng xuất và ranh giới phân quyền

Hãy bấm đăng xuất (Logout) khỏi tài khoản Administrator, sau đó đăng nhập lại qua đường dẫn HTTPS để vào trang Dashboard. Tiếp theo, mở một cửa sổ trình duyệt riêng biệt để đăng nhập bằng tài khoản biên tập (Editor): mục tiêu là xác nhận tài khoản này thực hiện trơn tru mọi thao tác viết bài, đăng ảnh được giao nhưng bị khóa chặt trước các khu vực nhạy cảm như cài đặt phần mềm hay quản lý người dùng.

Trong đợt chạy thực nghiệm ngày 01/10, giao diện của tài khoản Editor hoàn toàn không hiển thị các mục menu Plugin, Giao diện (Appearance) hay Thành viên (Users); đồng thời khi chúng tôi cố tình gõ thẳng địa chỉ /wp-admin/plugins.php lên thanh URL của trình duyệt thì máy chủ lập tức trả về màn hình chặn với mã lỗi HTTP 403 Forbidden. Bước gõ thẳng URL này cực kỳ quan trọng trong kiểm thử bảo mật, bởi một số plugin viết ẩu chỉ dùng CSS hoặc hàm giao diện để ẩn mục menu đi chứ quên không khóa quyền truy cập thực sự ở tầng xử lý phía sau! Tất nhiên, kết quả này xác nhận cho cấu hình mặc định trên máy chủ lab của chúng ta, chưa đại diện cho mọi tổ hợp quyền hạn khi có cài thêm plugin bên thứ ba.

Ảnh chụp giao diện Dashboard của Editor thực tế ngày 01/10/2026 trong đợt hoàn tất lúc 18:02:11; giữ nguyên pixel gốc và gắn logo. Bức ảnh phản ánh các mục menu được phép hiển thị của vai trò này; còn phản hồi HTTP 403 khi truy cập trực tiếp đường dẫn trang plugin là bước xác minh độc lập không nằm trong khuôn hình này. Bấm vào ảnh để xem đầy đủ.

Sau khi bấm đăng xuất khỏi hệ thống, bạn hãy thử gõ trực tiếp một đường dẫn quản trị bên trong /wp-admin/ để chắc chắn rằng WordPress lập tức chặn lại và đẩy bạn về màn hình yêu cầu đăng nhập chuẩn. Hãy để ý kỹ thanh địa chỉ lúc bị chuyển hướng: URL phải giữ nguyên tên miền chính thức hiện tại chứ không được nhảy về địa chỉ IP hay tên miền nháp cũ kỹ nào đó. Nếu bạn gặp hiện tượng nhập đúng mật khẩu mà trình duyệt cứ xoay vòng vòng đẩy về lại trang login (Login Loop), hãy rà soát ngay thiết lập Cookie, hai giá trị siteurl / home, cấu hình chuyển tiếp header X-Forwarded-Proto khi đứng sau Reverse Proxy, và đảm bảo hệ thống Page Cache tuyệt đối không lưu đệm các trang thuộc /wp-admin/ hay wp-login.php.

Đối với tính năng “Quên mật khẩu” (Lost your password?), ở bước này bạn hãy ghi nhận trung thực vào biên bản là chưa nghiệm thu gửi/nhận thư; toàn bộ luồng cấu hình SMTP và kiểm thử nhận thư khôi phục sẽ được giải quyết triệt để ở bài 46–47. Đừng thấy có dòng link “Bạn quên mật khẩu?” nằm trên màn hình đăng nhập mà vội tích xanh là tính năng khôi phục đã hoạt động!

Ảnh chụp trình duyệt thực tế ngày 01/10/2026 trước khi điền thông tin đăng nhập, thuộc đợt xác minh hoàn tất lúc 17:38:19 (UTC+7); giữ nguyên pixel gốc và gắn logo. Bức ảnh chỉ ghi nhận giao diện biểu mẫu trống; kết quả thực hiện đăng nhập và đăng xuất được tổng hợp riêng ở bảng báo cáo phía dưới. Bấm vào ảnh để xem đầy đủ.

Bước 6: đọc báo cáo Site Health và soi file Log một cách tỉnh táo

Hãy dùng tài khoản quản trị truy cập vào mục Tools → Site Health (Công cụ → Tình trạng trang web) và đọc kỹ từng dòng thông báo. Những cảnh báo liên quan đến tiến trình lập lịch ngầm (WP-Cron) hoặc REST API bị nghẽn có thể khiến tính năng hẹn giờ đăng bài hoặc trình soạn thảo khối gặp trục trặc; trong khi đó, các đề xuất cài thêm PHP module cần được cân nhắc dựa trên nhu cầu thực sự của trang web. Bí quyết của người có kinh nghiệm là ghi chép lại số phiên bản cùng nội dung cảnh báo cụ thể để lên phương án xử lý hợp lý, thay vì mắc chứng “ám ảnh cưỡng chế” cố tìm mọi cách ép thanh trạng thái phải chuyển sang màu xanh 100% bằng mọi giá.

Song song đó, hãy mở terminal đọc tập tin nhật ký lỗi (error.log) của đúng Virtual Host NGINX và tiến trình PHP-FPM xung quanh khung giờ bạn vừa thao tác thử nghiệm. Khi trích xuất log vào biên bản hoặc gửi đi trao đổi kỹ thuật, chỉ cắt lấy đúng những dòng thông báo lỗi liên quan, tránh copy-paste nguyên cả file log dài chứa địa chỉ IP cá nhân của người dùng thật. Ngoài ra, nếu bạn tạm thời bật hằng số WP_DEBUG_LOG để truy tìm lỗi, hãy nhớ tắt đi ngay sau khi đã bắt được bệnh, đồng thời cấu hình NGINX chặn truy cập trực tiếp từ ngoài trình duyệt vào các tập tin .log.

Đọc hiểu các cảnh báo thực tế trên Lab thay vì tự huyễn hoặc rằng mọi thứ đều hoàn hảo

Trong đợt thực nghiệm kết thúc lúc 17:38:19 ngày 01/10/2026, chúng tôi mở trang Site Health trên máy chủ LAB-CF-02 và ghi nhận kết quả nguyên bản gồm: 1 vấn đề nghiêm trọng (Critical issue) và 6 khuyến nghị cải thiện (Recommended improvements). Vấn đề nghiêm trọng duy nhất xoay quanh việc cơ chế cập nhật tự động chạy nền (Background updates) đang báo chưa hoạt động như kỳ vọng mặc định. Ở bước nghiệm thu này, chúng ta ghi nhận trung thực hiện trạng quan sát được chứ chưa can thiệp sửa ngay; bước tiếp theo trong quy trình vận hành sẽ là bấm mở mũi tên xem chi tiết lý do và đối chiếu xem nó có hoàn toàn hợp lý với mô hình khóa quyền ghi file của chúng ta ở bài 40 hay không.

Ảnh chụp màn hình Site Health thực tế ngày 01/10/2026 trong đợt hoàn tất lúc 17:38:19, giữ nguyên độ phân giải pixel và gắn logo. Do các thanh thu gọn (accordion) đang ở trạng thái thu gọn nên bức ảnh tổng quan này chưa liệt kê tên cụ thể của PHP module bị thiếu hay chi tiết thông báo cập nhật nền. Dòng chữ “Kiểm tra đã đạt” ở cuối trang là nhóm các bài kiểm tra đã vượt qua, không có nghĩa là toàn bộ trang web không còn cảnh báo nào. Bấm vào ảnh để xem đầy đủ.

Bảng phân tích phía trên giúp bạn thấy rõ cách đọc hiểu bản chất của 6 dòng khuyến nghị thay vì coi chúng như 6 lỗi bắt buộc phải xóa sạch bằng mọi giá. Chỉ thực hiện thay đổi cấu hình khi có lý do kỹ thuật xác đáng rồi xác minh lại các tính năng liên quan; đừng bao giờ phá vỡ thiết kế phân quyền file hay bật index cho trang thử nghiệm chỉ để chiều lòng một bảng điểm tự động.

Sơ đồ nguyên tắc ghi chép biên bản nghiệm thu do localhost.vn biên soạn; đây là hình vẽ hệ thống hóa quy trình, không phải ảnh chụp màn hình hay kết quả chạy lệnh trên lab.

Mẫu biên bản nghiệm thu (Pass / Fail Checklist)

Bạn có thể sao chép bảng mẫu trên làm khung ghi chép cho chính dự án của mình; nguyên tắc vàng là chỗ nào gặp lỗi thì ghi rõ “Fail”, chỗ nào chưa đụng tới thì ghi thẳng thắn là “Chưa thử”. Chi tiết kết quả thực nghiệm qua giao thức REST/HTTP ngày 30/09 và qua trình duyệt web ngày 01/10 của chúng tôi được trình bày đầy đủ ngay bên dưới. Hãy nhớ: việc 5 hạng mục đầu tiên đạt điểm tối đa không hề biến hạng mục thứ 6 (chưa thử) tự động trở thành “Đạt”.

Dọn dẹp dữ liệu nháp, phương án khôi phục và Câu hỏi thường gặp (FAQ)

Sau khi đã thu thập đủ ảnh chụp và log cho biên bản nghiệm thu, bạn hãy xóa các bài viết và hình ảnh thử nghiệm thông qua công cụ của WordPress, đồng thời dọn sạch cả mục Thùng rác (Trash) để tránh để lại các đường dẫn rác như /bai-viet-thu-nghiem-123/ trên website thật. Hãy cất giữ các tập tin log cần thiết vào thư mục lưu trữ nội bộ sau khi đã lọc bỏ thông tin nhạy cảm. Nếu muốn đổi lại cấu trúc Permalink khác trên môi trường lab, bạn có thể chọn lại dễ dàng; nhưng một khi website đã ra mắt công chúng và các đường dẫn đã được chia sẻ ra ngoài, mọi sự thay đổi cấu trúc URL đều bắt buộc phải đi kèm kế hoạch chuyển hướng Redirect 301 bài bản.

Cả 5 hạng mục trên đều báo Pass hết rồi thì tôi bấm nút công bố website ra mắt công chúng ngay được chưa? Khoan đã, bình tĩnh! Bộ danh sách này mới chỉ giúp bạn nghiệm thu phần khung sườn cốt lõi sau khi cài đặt WordPress. Để thực sự mở cửa đón người dùng thật, chúng ta còn phải đi qua chặng kiểm tra hệ thống gửi/nhận email và biểu mẫu liên hệ, rà soát nội dung thật, cấu hình lập chỉ mục SEO, thiết lập sao lưu tự động (Backup) và diễn tập khôi phục sự cố ở các bài tiếp theo.

Tôi có cần phải viết cả một hệ thống kiểm thử tự động (Automated E2E Testing) đồ sộ cho một trang WordPress mới dựng không? Với một website quy mô vừa và nhỏ mới khởi tạo thì hoàn toàn chưa cần thiết phải vác dao mổ trâu giết gà như vậy. Một quy trình kiểm thử nhanh (Smoke Test) gọn gàng, bám sát đúng hành trình thực tế của người đọc và quản trị viên kèm theo biên bản ghi nhận kết quả trung thực sẽ mang lại giá trị thực tiễn cao hơn gấp nhiều lần so với việc bấm loạn xạ không lưu vết.

Tôi nên lưu trữ biên bản nghiệm thu này ở đâu cho hợp lý? Hãy lưu vào sổ tay vận hành dự án (Runbook / Lab Journal) có ghi rõ mốc ngày giờ, số phiên bản phần mềm và người thực hiện. Khi cần gửi ảnh chụp màn hình hoặc log lên các diễn đàn hay nhóm hỗ trợ kỹ thuật để nhờ bắt bệnh, hãy luôn che kín mật khẩu/cookie và cung cấp rõ đường dẫn URL, chức năng đang thao tác cùng thời điểm chính xác xảy ra lỗi.

Báo cáo thực nghiệm qua REST API và HTTP trên LAB-CF-02 (30/09/2026)

Đợt xác minh tổng hợp cho Media Library, bài viết và truy cập góc nhìn khách vào cuối ngày 30/09/2026 được ghi nhận tại khung giờ 23:54:09–23:54:15 (UTC+7) trên phiên bản WordPress 7.1.2. Toàn bộ các bước trong đợt này được thực thi tự động hóa qua REST API trên nền HTTPS kết hợp truy vấn HTTP như khách vãng lai, giữ nguyên cơ chế kiểm tra chứng chỉ TLS tiêu chuẩn. Sự cố không ghi được file khi tải ảnh ở bài trước đã được giải quyết triệt để bằng cách cấp đúng quyền sở hữu cho thư mục năm/tháng theo chuẩn của bài 40.

Tập tin hình ảnh được sử dụng để đo kiểm luồng Media trong đợt này là một bản vẽ sơ đồ có sẵn do đội ngũ localhost.vn thiết kế. Việc mã băm SHA256 của file tải xuống từ URL công khai trùng khớp hoàn toàn với file gốc ban đầu chứng minh quá trình truyền tải và lưu trữ file gốc không làm hỏng dữ liệu. Tất nhiên, việc đọc thấy metadata và nhận mã HTTP 200 từ đường dẫn thumbnail qua công cụ dòng lệnh chưa thể thay thế cho đôi mắt người thật nhìn bố cục hiển thị trên màn hình máy tính và điện thoại.

Tương tự, việc xác thực thành công qua REST API rồi nhận mã 401 sau khi xóa tài khoản mới chỉ kiểm chứng tầng API, chưa đại diện cho luồng đăng nhập/đăng xuất lưu phiên bằng Cookie trên trình duyệt web. Đợt chạy tự động ngày 30/09 này chưa đi vào giao diện Dashboard, màn hình Preview của trình soạn thảo, giao diện Media Library, trang Site Health hay tính năng gửi/nhận email. Chính vì vậy, chúng tôi đã thực hiện tiếp đợt nghiệm thu trực tiếp trên trình duyệt vào ngày 01/10 ngay dưới đây. Lưu ý rằng toàn bộ bài viết và ảnh nháp trong đợt thử nghiệm đã được xóa sạch sau khi hoàn tất nên các đường dẫn tạm thời đó không còn tồn tại trên máy chủ.

Báo cáo nghiệm thu trên trình duyệt thực tế ngày 01/10/2026

Các đợt xác minh dưới đây được thực hiện trực tiếp trên trình duyệt web độc lập kết nối tới máy chủ LAB-CF-02. Các mốc thời gian ghi theo múi giờ Việt Nam (UTC+7) là thời điểm hoàn tất từng đợt đo kiểm tổng thể, không phải giây chính xác bấm nút chụp của từng bức ảnh riêng lẻ.

Chi tiết đợt xác minh Editor tạo, sửa và xuất bản bài viết qua giao diện lúc 18:02

Đợt thực nghiệm hoàn tất lúc 18:02:11 ngày 01/10/2026 (UTC+7) sử dụng một tài khoản Editor khởi tạo riêng cho phiên làm việc này. Toàn bộ quá trình gõ chữ, lưu nháp, chỉnh sửa và bấm xuất bản đều được thao tác trực tiếp trên giao diện trình soạn thảo khối (Block Editor); đồng thời các truy vấn mạng do trình duyệt gửi đi cũng được giám sát để đối chiếu trạng thái lưu bài. Đây là phiên thao tác giao diện hoàn toàn độc lập với bản nháp kiểm tra ảnh tạo bằng REST API lúc 17:35.

Ảnh chụp trang khách thực tế ngày 01/10/2026 trong đợt hoàn tất lúc 18:02:11; cắt vùng khung nhìn phía trên (1440 × 900 pixel) trên màn hình máy tính, giữ nguyên độ phân giải gốc và gắn logo. Hình ảnh này minh họa phần đầu trang desktop (khung nhìn di động 390px được đối chiếu riêng). Bấm vào ảnh để xem kích thước đầy đủ.

Quá trình đối chiếu hậu kỳ xác nhận mã băm (hash) của các bài viết công khai có sẵn từ trước, nội dung tập tin wp-config.php và index.php đều trùng khớp 100% với trạng thái chuẩn ban đầu; danh sách plugin đang bật và cấu hình chặn lập chỉ mục (noindex) hoàn toàn không bị xê dịch. Toàn bộ dữ liệu thử nghiệm, thông tin đăng nhập tạm thời và các script hỗ trợ đã được xóa sạch, trình duyệt cũng đã đóng lại. Lưu ý rằng thao tác dọn dẹp chỉ nhắm chính xác vào các dòng dữ liệu (bao gồm bản ghi revision và custom styles tự sinh) của phiên thử nghiệm, tuyệt đối không chạy lệnh xóa càn trên một website đang vận hành thật.

Như vậy, chúng ta đã có đầy đủ bằng chứng thực nghiệm trên cả giao diện người dùng (UI) lẫn tầng API cho các luồng: tải ảnh Media Library, xem trước bản nháp, đăng nhập/đăng xuất Administrator, duyệt trang như khách vãng lai và quy trình Editor tạo – sửa – xuất bản bài viết. Tuy nhiên, xin nhấn mạnh rằng các đợt chạy này chưa bao gồm việc kiểm thử gửi/nhận email, biểu mẫu liên hệ (Contact Form) hay tính năng nhận thư đặt lại mật khẩu. Các hạng mục về chuyển đổi giao diện, mở lập chỉ mục Google, tối ưu tiến trình WP-Cron hay xử lý cảnh báo trong Site Health cũng được giữ nguyên chưa can thiệp ở bước này. Hãy tiếp tục áp dụng phương pháp làm việc minh bạch này cho website của bạn: kiểm tới đâu ghi nhận rõ Pass / Fail / Chưa thử tới đó.

Tài liệu tham khảo và hành trình tiếp theo

Các bằng chứng thực nghiệm trên trình duyệt được ghi nhận bổ sung vào ngày 01/10/2026; tài liệu chính thức về WordPress Documentation: Media Library Screen cùng WordPress Block Editor (Gutenberg) và WordPress Roles and Capabilities được tra cứu đối chiếu trong cùng ngày. Các tài liệu kỹ thuật nền tảng giữ mốc đối chiếu ngày 30/09/2026 bao gồm: WordPress Settings Permalinks Screen, WordPress Advanced Administration: How to Install WordPress, WordPress REST API Reference: Media Endpoints, và WordPress REST API: Authentication. Các sơ đồ chẩn đoán lỗi và mẫu biên bản nghiệm thu trong bài được biên soạn riêng cho chuỗi bài thực hành này.

Mời bạn xem lại bức tranh tổng thể tại lộ trình cài đặt và vận hành WordPress trên VPS từ A đến Z. Bài trước: Phân quyền WordPress — tạo Admin, cấp Role và cài Theme/Plugin an toàn. Bài tiếp theo: Xin cấp mới và cấu hình gia hạn tự động chứng chỉ TLS (HTTPS) cho tên miền thử nghiệm.