Phân quyền WordPress: Tạo Admin, cấp Role và cài Theme/Plugin an toàn

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 hệ thống thuộc quyền quản lý của bạn. Quyền của vai trò Editor và Contributor đã được xác minh qua REST API (HTTPS) trên LAB-CF-02 lúc 23:54 ngày 30/09/2026 (UTC+7). Trong khung giờ 00:13–00:14 ngày 01/10/2026, chúng tôi đã thực hành kích hoạt một theme có sẵn trên máy rồi khôi phục về theme ban đầu. Ngày 01/10 lúc 17:38 đã xác minh thao tác đăng nhập/đăng xuất của tài khoản admin hiện hữu; lúc 18:02 đối chiếu việc Editor tạo, sửa, xuất bản bài viết qua giao diện web và bị chặn truy cập trang quản lý plugin. Đợt thực nghiệm lúc 18:22–18:23:26 bổ sung quy trình cài mới theme/plugin, kích hoạt và đưa hệ thống về nguyên trạng trước khi thử bằng tài khoản admin hiện hữu. Ngày 02/10/2026 lúc 14:03:46 đã hoàn tất việc tạo Administrator mới bằng trọn bộ lệnh CLI đã hiệu chỉnh bên dưới, đăng nhập trên trình duyệt, xác minh quyền hạn và thu hồi tài khoản cùng phiên đăng nhập. Không sử dụng giao diện Add New trên web để tạo admin; đợt thực hành này cũng không nâng cấp các phần mềm đang chạy.

Một trong những “tai nạn kinh điển” nhất của các đội vận hành website nhỏ là tạo đúng một tài khoản Administrator, đặt mật khẩu kiểu dễ nhớ rồi gửi qua nhóm chat cho cả công ty dùng chung — từ sếp tổng, nhân viên SEO cho tới bạn cộng tác viên mới vào nghề hôm qua. Đến khi trang web bỗng dưng trắng xóa lúc nửa đêm vì ai đó tiện tay cài thử một plugin lạ, cả nhóm nhìn nhau không biết thủ phạm là ai. Nguyên tắc sống còn của phân quyền WordPress rất giản dị: mỗi người một tài khoản riêng, làm việc gì trao đúng quyền (WordPress Role) cho việc đó. Còn Theme và Plugin thực chất là mã nguồn thực thi trực tiếp trên máy chủ, nên việc cài mới, cập nhật hay gỡ bỏ bắt buộc phải có người chịu trách nhiệm rõ ràng.

Chuẩn bị tài khoản quản trị có thể khôi phục

Hãy sử dụng tài khoản Administrator đã khởi tạo từ trình cài đặt hoặc WP-CLI để đăng nhập qua kết nối HTTPS. Điều đầu tiên bạn cần rà soát là địa chỉ email quản trị phải nằm trong hộp thư mà bạn thực sự nắm quyền chủ động; trước ngày bấm nút mở site đón khách (Go-live), bạn bắt buộc phải thử nghiệm nhận email khôi phục mật khẩu theo hướng dẫn ở bài 46–47. Hãy cất giữ mật khẩu dài, phức tạp trong trình quản lý mật khẩu (Password Manager) và tạo tài khoản cá nhân cho từng thành viên thay vì xài chung một tài khoản quản trị 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, thuộc đợt xác minh hoàn tất lúc 17:38:19 (UTC+7); giữ nguyên độ phân giải gốc và chèn thêm logo. Ảnh chỉ hiển thị biểu mẫu đăng nhập trống; kết quả đăng nhập/đăng xuất được ghi nhận riêng, hoàn toàn không lộ mật khẩu trong ảnh. Bấm vào ảnh để xem kích thước đầy đủ.

Trong hồ sơ vận hành, hãy ghi rõ ai là người nắm giữ tài khoản quản trị dự phòng (Break-glass Admin) và quy trình mở phong bì sử dụng khi người phụ trách chính đi vắng hoặc nghỉ phép. Tài khoản dự phòng này cần được quản lý chặt chẽ, tuyệt đối không hào phóng ban phát quyền Administrator cho tất cả thành viên trong nhóm. Ngoài ra, nếu bạn bật xác thực hai yếu tố (2FA) thông qua plugin hoặc dịch vụ bảo mật, hãy thử nghiệm mã khôi phục (Recovery Code) và quy trình cứu hộ trên môi trường Staging hoặc lab trước khi áp dụng bắt buộc cho toàn bộ đội ngũ.

Sơ đồ tư duy phân quyền do đội ngũ localhost.vn biên soạn; đây là tài liệu hướng dẫn trực quan, 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: tạo tài khoản theo công việc

Trên giao diện quản trị, bạn truy cập vào Users → Add New (hoặc Thành viên → Thêm mới tùy ngôn ngữ hiển thị), nhập tên đăng nhập (username) riêng biệt, địa chỉ email công việc hợp lệ rồi gán đúng WordPress Role tương ứng. Hãy nhớ chỉ gửi thông tin kích hoạt tài khoản qua kênh nội bộ an toàn theo quy định của nhóm; khi chụp ảnh màn hình làm tài liệu hướng dẫn, tuyệt đối không để lộ email cá nhân thật.

Bảng tóm tắt phía trên là hệ quy chiếu mặc định của một bản WordPress nguyên bản (Core). Tuy nhiên, trong thực tế nhiều plugin như WooCommerce, plugin quản lý thành viên (Membership) hay các bộ công cụ SEO sẽ tự động chỉnh sửa hoặc đẻ thêm các Role và Capabilities (quyền hạn chi tiết) mới. Do đó, sau khi cấp tài khoản, bạn vẫn phải đăng nhập thử trên môi trường thực tế để đối chiếu quyền hạn thật sự thay vì chỉ tin vào cái tên hiển thị.

Lựa chọn WP-CLI: tạo Administrator với mật khẩu nhập tương tác

Với anh em kỹ thuật quản trị VPS, dùng WP-CLI thường nhanh, chuẩn xác và an toàn hơn hẳn thao tác chuột trên giao diện Users → Add New. Lưu ý quan trọng: hãy chạy lệnh dưới quyền user hệ điều hành sở hữu thư mục website — tuyệt đối không chạy bằng root và cũng đừng nhầm với tên tài khoản bên trong WordPress. Bạn chỉ cần gán đường dẫn tuyệt đối đã xác nhận vào biến WP_ROOT, tên đăng nhập mới vào NEW_WP_USER và địa chỉ hộp thư bạn quản lý vào NEW_WP_EMAIL. Đoạn lệnh mẫu dưới đây được thiết kế cho phiên terminal Ubuntu tương tác trên cây thư mục site của bạn, giúp tránh hoàn toàn việc lưu mật khẩu dạng rõ (plaintext) vào biến môi trường hay lịch sử dòng lệnh (shell history).

(
  set +x
  set -eu
  test "$(id -u)" -ne 0
  test -t 0
  test -t 1
  : "${WP_ROOT:?Đặt đường tuyệt đối của site}"
  : "${NEW_WP_USER:?Đặt username WordPress mới}"
  : "${NEW_WP_EMAIL:?Đặt email tài khoản mới}"
  case "$WP_ROOT" in /*) ;; *) exit 1 ;; esac
  test -d "$WP_ROOT"
  test ! -L "$WP_ROOT"
  test -r "$WP_ROOT/wp-config.php"
  test "$(stat -c '%U' "$WP_ROOT")" = "$(id -un)"
  test "$(readlink -f -- "$WP_ROOT")" = "$WP_ROOT"
  test -f "$WP_ROOT/wp-config.php"
  test ! -L "$WP_ROOT/wp-config.php"
  for site_dir in wp-content wp-content/plugins wp-content/themes; do
    test -d "$WP_ROOT/$site_dir"
    test ! -L "$WP_ROOT/$site_dir"
    test "$(readlink -f -- "$WP_ROOT/$site_dir")" = "$WP_ROOT/$site_dir"
  done
  test "$(wp --path="$WP_ROOT" config path)" = "$WP_ROOT/wp-config.php"
  wp --path="$WP_ROOT" core is-installed
  existing_logins=$(wp --path="$WP_ROOT" user list --field=user_login)
  if printf '%s\n' "$existing_logins" | grep -Fx -- "$NEW_WP_USER" >/dev/null; then
    printf '%s\n' 'Username đã tồn tại; dừng để kiểm.' >&2
    exit 1
  fi
  trap 'unset WP_PASSWORD' EXIT
  IFS= read -r -s -p 'Mật khẩu WordPress: ' WP_PASSWORD </dev/tty
  printf '\n' >/dev/tty
  test -n "$WP_PASSWORD"
  printf '%s\n' "$WP_PASSWORD" |
    wp --path="$WP_ROOT" user create "$NEW_WP_USER" "$NEW_WP_EMAIL" \
      --role=administrator --prompt=user_pass --porcelain --quiet
  unset WP_PASSWORD
)

Khi màn hình dừng lại ở dòng nhắc Mật khẩu WordPress:, bạn hãy nhập mật khẩu mạnh vào. Cơ chế read -s của Bash sẽ ẩn toàn bộ ký tự gõ trên màn hình, giữ mật khẩu trong biến cục bộ của subshell (không export ra ngoài) rồi truyền thẳng qua luồng stdin. Bên trong khối lệnh, set +x đảm bảo tắt chế độ in vết lệnh (trace) và cờ --quiet ngăn không cho WP-CLI in ngược lại tham số ra màn hình. Thực tế trên lab cho thấy: nếu bạn chỉ dùng lệnh stty -echo để tắt hiển thị bàn phím rồi gọi trực tiếp cờ prompt của WP-CLI, mật khẩu vẫn có nguy cơ bị lộ nguyên hình trong luồng xuất (output) của công cụ này! Bởi vậy, nguyên tắc bất di bất dịch là không chèn thêm set -x hay tee, không quay video màn hình, không chụp ảnh hay bật tính năng ghi transcript terminal lúc đang gõ thông tin bí mật. Khi tạo tài khoản thành công, tùy chọn --porcelain sẽ chỉ trả về một con số gọn gàng là ID của user mới. Bạn chỉ nên thêm cờ --send-email nếu hệ thống gửi thư (SMTP) của máy chủ đã được cấu hình và xác minh hoạt động trơn tru. Ngay sau đó, hãy mở một cửa sổ trình duyệt ẩn danh để thử đăng nhập vào tài khoản Administrator mới trước khi xóa hoặc hạ quyền tài khoản quản trị cũ. Trọn bộ khối lệnh CLI này đã được chạy thực nghiệm trên LAB-CF-02 vào ngày 02/10/2026; chi tiết kết quả và các lưu ý nằm ở phần báo cáo cuối bài.

Bước 2: xác minh thực tế bằng tài khoản quyền thấp

Đừng bao giờ tạo tài khoản xong rồi để đấy. Hãy mở ngay một cửa sổ trình duyệt riêng tư (Incognito/Private Window), đăng nhập bằng chính tài khoản quyền thấp vừa tạo và đóng vai nhân sự thực hiện công việc hằng ngày. Nếu là Contributor, hãy thử tạo một bài viết nháp và xác nhận rằng nút “Xuất bản” không xuất hiện (chỉ được gửi duyệt) đúng như mong đợi. Nếu là Editor, hãy thử chỉnh sửa bài viết và cố tình gõ đường dẫn vào trang quản lý plugin xem có bị chặn thẳng cánh hay không. Cái nhãn Role hiển thị trong bảng danh sách user chưa bao giờ là giấy bảo đảm 100% rằng phân quyền đang chạy đúng.

Mẹo nhỏ cho bạn: hãy luôn giữ nguyên phiên đăng nhập của Administrator ở một cửa sổ trình duyệt bình thường khác để tiện tay điều chỉnh quyền khi cần. Đến lúc dọn dẹp hoặc xóa các tài khoản thử nghiệm, hãy đọc thật kỹ tùy chọn Attribute all content to (Gán lại toàn bộ nội dung cho người khác) hoặc xóa sạch bài viết đi kèm, kẻo một cú click vội vàng lại làm bay màu hàng chục bài viết quan trọng trên site. Đặc biệt, trước khi hạ quyền hoặc xóa tài khoản Administrator duy nhất, bạn bắt buộc phải xác nhận tài khoản quản trị mới đã vào được Dashboard ngon lành và kết nối SSH tới VPS vẫn đang thông suốt.

Ảnh chụp giao diện Dashboard của tài khoản Editor thực tế ngày 01/10/2026 trong đợt thực hành hoàn tất lúc 18:02:11; giữ nguyên pixel gốc và chèn logo. Thanh menu bên trái phản ánh đúng giới hạn của tài khoản này; thao tác gõ thẳng đường dẫn trang plugin và nhận mã lỗi HTTP 403 được xác minh ở bước riêng. Bấm vào ảnh để xem kích thước đầy đủ.

Bước 3: chọn Theme/Plugin theo nhu cầu thực tế, tránh hội chứng “nghiện cài cắm”

Người mới dùng WordPress thường mắc hội chứng thích gì cài nấy: thấy bài viết trên mạng khen plugin tối ưu nào hay là cài liền 3–4 cái cùng lúc. Cách làm của dân kỹ thuật bài bản là gạch đầu dòng rõ ràng chức năng website đang thiếu — ví dụ cần biểu mẫu liên hệ (Contact Form) hay bộ nhớ đệm (Cache) — rồi mới tìm kiếm plugin trên kho chính thức WordPress.org hoặc từ nhà phát triển uy tín đã được xác thực. Hãy dành vài phút đọc kỹ phiên bản WordPress/PHP tương thích, lịch sử cập nhật gần nhất, tài liệu hướng dẫn và đặc biệt là cơ chế xuất dữ liệu (export) phòng khi sau này muốn chia tay plugin đó. Tuyệt đối đừng cài song song hai plugin cùng tranh giành quyền kiểm soát Cache hoặc Redirect, vì chúng sẽ giẫm chân lên nhau và tạo ra những lỗi cực kỳ đau đầu khi gỡ rối.

Đối với Theme, bạn hãy áp thử giao diện trên bộ nội dung tiếng Việt thực tế để đánh giá khả năng hiển thị trên màn hình di động, độ rõ nét của phông chữ và tốc độ tải trang. Nếu cần can thiệp sửa mã nguồn hoặc CSS, hãy triển khai qua cơ chế Child Theme; việc sửa trực tiếp vào Parent Theme sẽ khiến toàn bộ công sức của bạn bốc hơi ngay trong lần bấm cập nhật phiên bản tiếp theo. Hãy nhớ rằng một trang Demo lung linh với ảnh mẫu Tây phương chưa chắc đã giữ được bố cục đẹp khi lắp những tiêu đề tiếng Việt dài ngoằng của bạn vào.

Mỗi khi đưa một plugin vào hệ thống, hãy lập sổ theo dõi gọn gàng gồm: tên hiển thị, định danh slug, nguồn tải, mục đích sử dụng và người chịu trách nhiệm bảo trì. Trước khi gỡ bỏ một plugin không còn dùng tới, hãy rà soát dữ liệu cần giữ lại. Và đừng quên: một plugin ở trạng thái “Deactivated” (đã tắt) thì mã nguồn PHP của nó vẫn nằm nguyên trên ổ cứng máy chủ chứ chưa hề biến mất.

Sơ đồ quy trình chuẩn bị do đội ngũ localhost.vn biên soạn; đây là hình vẽ 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 chạy lệnh trên lab.

Bước 4: cài đặt phần mềm theo mô hình phân quyền chặt của chuỗi bài

Nếu bạn đã đi theo đúng kiến trúc bảo mật từ bài 40, tài khoản hệ điều hành chuyên trách triển khai (deploy user) sẽ nắm quyền sở hữu mã nguồn (codebase), trong khi tiến trình PHP-FPM chỉ được cấp quyền ghi hạn hẹp tại thư mục wp-content/uploads. Nhờ thiết kế tách biệt này, giao diện web Dashboard sẽ không thể tự ý ghi file để cài trực tiếp plugin hay theme mới. Thay vì phá vỡ hàng rào bảo mật bằng cách mở toang quyền ghi cho PHP, chúng ta sẽ sử dụng công cụ chính thống WP-CLI dưới quyền user triển khai thông thường (tài khoản sở hữu cây thư mục site). Tuyệt đối không chạy bằng tài khoản root kèm cờ --allow-root chỉ để lách qua cảnh báo.

Trước khi bắt tay vào cài đặt, bạn hãy gõ command -v wp để xem trên VPS đã có sẵn WP-CLI hay chưa. Nếu máy chủ chưa cài, hãy tải gói thực thi Phar qua giao thức HTTPS từ kho phát hành chính thức theo đúng hướng dẫn cài đặt WP-CLI:

(
  set -eu
  if command -v wp >/dev/null 2>&1; then
    printf '%s\n' 'WP-CLI đã có; kiểm phiên bản trước khi cài khác.' >&2
    exit 1
  fi
  test ! -e /usr/local/bin/wp
  test ! -L /usr/local/bin/wp
  wpcli_work_dir=$(mktemp -d)
  cd "$wpcli_work_dir"
  curl --fail --location --proto '=https' --tlsv1.2 \
    https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar \
    -o wp-cli.phar
  php wp-cli.phar --info
  sudo install -m 755 wp-cli.phar /usr/local/bin/wp
  wp --info
  rm -- wp-cli.phar
  cd /
  rmdir -- "$wpcli_work_dir"
)

Lưu ý nhỏ: chỉ chạy đoạn script trên khi bạn chắc chắn không có quản trị viên nào khác đang đồng thời cài đặt WP-CLI vào cùng đường dẫn đích. Khối lệnh được thiết kế để lập tức dừng lại (fail-fast) nếu bước tải file hoặc bước đối chiếu gặp trục trặc, đồng thời giữ lại thư mục tạm để bạn tiện tra cứu lỗi trước khi dọn dẹp. Hãy nhớ rằng lệnh --info chỉ xác nhận file thực thi hoạt động được với bản PHP hiện tại chứ không thay thế bước xác thực chữ ký số. Nếu quy chuẩn bảo mật của công ty bạn yêu cầu kiểm chứng chữ ký phát hành, hãy thực hiện thêm bước GPG Verification trong tài liệu chính thức trước khi chạy gói Phar. Hãy ghi chép lại số phiên bản thực tế và nói không với các đoạn script cài đặt trôi nổi chưa rõ nguồn gốc.

Sau khi đã tra cứu chính xác định danh slug của theme hoặc plugin cần dùng, bạn di chuyển vào thư mục gốc của website và thực thi:

(
  set -eu
  test "$(id -u)" -ne 0
  cd /var/www/lab-cf02
  wp core is-installed
  wp plugin list
  wp theme list
)

Cụ thể với plugin, bạn chạy lệnh wp plugin install SLUG_DA_CHON, nhìn kỹ tên gói, nguồn tải và số phiên bản trả về trên màn hình rồi mới gõ tiếp wp plugin activate SLUG_DA_CHON. Tương tự cho giao diện, bạn chạy lần lượt wp theme install SLUG_DA_CHON và wp theme activate SLUG_DA_CHON. Hãy thay thế phần chữ in hoa bằng đúng chuỗi slug viết thường không dấu đã xác nhận trên kho lưu trữ, đừng gõ tên thương hiệu có khoảng trắng hay dấu tiếng Việt vào dòng lệnh.

Nguyên tắc vàng của dân vận hành lâu năm: kích hoạt từng món một, mở trình duyệt kiểm tra ngay trang chủ, trang đăng nhập và tính năng vừa thêm xem có êm xuôi không rồi mới đụng tới món tiếp theo. Đừng bao giờ gom một rổ 10 plugin rồi bấm kích hoạt hàng loạt (Bulk Activate), vì nếu site lăn đùng ra lỗi 500 bạn sẽ tốn gấp đôi thời gian để mò xem cái nào gây họa. Với các gói giao diện hoặc plugin trả phí (Commercial/Premium), hãy tải file nén trực tiếp từ tài khoản có bản quyền hợp lệ của bạn và cài đặt theo tài liệu của hãng; tuyệt đối tránh xa các bản “nulled” hay “chia sẻ miễn phí” trên mạng nếu không muốn biến VPS của mình thành ổ đào tiền ảo hoặc phát tán mã độc.

Thực hành với phiên bản cố định từ đợt chạy lab ngày 01/10

Trên máy chủ thử nghiệm LAB-CF-02, chúng tôi đã chọn giao diện Twenty Twenty-One phiên bản 2.9 và plugin Classic Editor phiên bản 1.7.0 từ kho chính thức WordPress.org để minh họa trọn vẹn vòng đời cài đặt – kích hoạt – gỡ bỏ phần mềm. Xin lưu ý đây là các con số phiên bản thực tế tại thời điểm thực nghiệm ngày 01/10/2026 để đảm bảo tính tái lập (reproducibility), không phải lời khuyên rằng mọi website đều phải dùng hai gói này hay chúng sẽ mãi mãi là bản mới nhất. Trước khi gõ lệnh, chúng tôi đã xuất danh sách phiên bản hiện trạng, ghi nhận tên theme đang active, sao lưu toàn bộ mã nguồn cùng cơ sở dữ liệu (Database), đồng thời xác nhận cả hai gói chưa hề tồn tại trên máy. Kịch bản dưới đây áp dụng cho cấu trúc thư mục WordPress tiêu chuẩn có wp-content nằm trong WP_ROOT, thực thi bởi chính user hệ điều hành sở hữu thư mục đó.

(
  set -eu
  test "$(id -u)" -ne 0
  : "${WP_ROOT:?Đặt đường tuyệt đối của site lab đã kiểm}"
  case "$WP_ROOT" in /*) ;; *) exit 1 ;; esac
  test -d "$WP_ROOT"
  test ! -L "$WP_ROOT"
  test "$(stat -c '%U' "$WP_ROOT")" = "$(id -un)"
  test "$(readlink -f -- "$WP_ROOT")" = "$WP_ROOT"
  test -f "$WP_ROOT/wp-config.php"
  test ! -L "$WP_ROOT/wp-config.php"
  for site_dir in wp-content wp-content/plugins wp-content/themes; do
    test -d "$WP_ROOT/$site_dir"
    test ! -L "$WP_ROOT/$site_dir"
    test "$(readlink -f -- "$WP_ROOT/$site_dir")" = "$WP_ROOT/$site_dir"
  done
  test "$(wp --path="$WP_ROOT" config path)" = "$WP_ROOT/wp-config.php"
  wp --path="$WP_ROOT" core is-installed
  test ! -e "$WP_ROOT/wp-content/plugins/classic-editor"
  test ! -L "$WP_ROOT/wp-content/plugins/classic-editor"
  test ! -e "$WP_ROOT/wp-content/themes/twentytwentyone"
  test ! -L "$WP_ROOT/wp-content/themes/twentytwentyone"
  wp --path="$WP_ROOT" theme install twentytwentyone --version=2.9
  wp --path="$WP_ROOT" plugin install classic-editor --version=1.7.0
  wp --path="$WP_ROOT" plugin verify-checksums classic-editor
  wp --path="$WP_ROOT" theme list
  wp --path="$WP_ROOT" plugin list
)

Bạn có thể thấy khối lệnh trên chủ động không dùng cờ --force (ép ghi đè) hay --activate (kích hoạt gộp ngay khi tải). Sau khi tải xong và trước khi đi tiếp, chúng ta xác nhận cả hai thành phần vẫn đang nằm yên ở trạng thái chưa kích hoạt (inactive). Nếu có bất kỳ dòng lệnh nào báo lỗi giữa chừng, script sẽ dừng ngay để bạn rà soát xem phần nào đã được tải về ổ cứng, bởi khối lệnh không tự động xóa lùi. Ngoài ra, thao tác verify-checksums giúp đối chiếu mã băm các file của plugin với máy chủ WordPress.org để chắc chắn gói tải về nguyên vẹn, nhưng tất nhiên nó không phải là “bùa hộ mệnh” chứng nhận mã nguồn bên trong plugin không xung đột với cấu hình riêng của bạn.

Ảnh chụp giao diện thực tế ngày 01/10/2026 ở bước đối chiếu lúc 18:22:55 (UTC+7); cắt gọn vùng danh sách plugin, giữ nguyên pixel gốc và gắn logo. Quá trình tải gói về được thực hiện qua WP-CLI; ảnh này dùng để xác nhận trạng thái hiển thị trong Dashboard, không phải thao tác bấm cài đặt qua trình duyệt. Bấm vào ảnh để xem bản đầy đủ.

Bây giờ, chúng ta tiến hành bật từng thành phần và quan sát phản ứng của hệ thống qua 3 bước rõ ràng:

1. Chạy lệnh wp --path="$WP_ROOT" theme activate twentytwentyone. Ngay lập tức mở một bài viết công khai dưới góc nhìn khách truy cập trên cả màn hình máy tính (rộng) và khung nhìn điện thoại (hẹp) để xem nội dung có hiển thị đủ và có bị lỗi vỡ khung tràn ngang (horizontal overflow) hay không.
2. Khi giao diện mới đã vượt qua bước sát hạch hiển thị, chạy tiếp wp --path="$WP_ROOT" plugin activate classic-editor. Quay lại trình duyệt mở mục Bài viết → Thêm mới, xác nhận khung soạn thảo đã chuyển sang giao diện cổ điển (Classic Editor) cùng ô nhập tiêu đề quen thuộc.
3. Chạy lệnh wp --path="$WP_ROOT" plugin deactivate classic-editor, tải lại trang thêm bài viết mới và xác nhận trình soạn thảo khối (Block Editor / Gutenberg) đã quay trở lại bình thường. Lưu ý nhỏ: bước này nhằm xác minh việc chuyển đổi giao diện trình soạn thảo; nếu trong thực tế bạn cần đánh giá khả năng lưu bài và xuất bản của Classic Editor thì sẽ cần thêm một bước gõ và lưu nội dung riêng.

Ảnh chụp giao diện thực tế ngày 01/10/2026 lúc 18:23:00; cắt vùng danh sách các theme, giữ nguyên độ phân giải và gắn logo. Ảnh xác nhận Twenty Twenty-One đang ở trạng thái Active; việc trang bài viết ngoài mặt tiền trả về HTTP 200 kèm nội dung chuẩn trên hai kích thước màn hình được ghi nhận riêng. Bấm vào ảnh để xem đầy đủ.

Ảnh chụp giao diện thực tế ngày 01/10/2026 lúc 18:23:05; cắt phần nửa trên của khung soạn thảo, giữ nguyên pixel và gắn logo. Trong đợt này chúng tôi chỉ xác nhận giao diện trình soạn thảo thay đổi chứ chưa gõ hay lưu bài viết bằng Classic Editor; vì thế không dùng bức ảnh khung trống này làm bằng chứng xuất bản bài viết. Bấm vào ảnh để xem đầy đủ.

Bước 5: đánh giá tác động hệ thống và dữ liệu phát sinh

Mỗi khi kích hoạt một plugin hay theme mới, bạn hãy ghi chú lại những khu vực chức năng chịu ảnh hưởng rồi mở trình duyệt đối chiếu dưới cả hai góc độ: người dùng đã đăng nhập (logged-in user) và khách vãng lai (anonymous visitor). Chẳng hạn, một plugin biểu mẫu liên hệ thường âm thầm tạo thêm bảng mới (custom table) trong cơ sở dữ liệu để lưu thông tin khách gửi; một plugin SEO có thể thay đổi hoàn toàn cấu trúc đường dẫn XML Sitemap; còn các plugin tạo bộ nhớ đệm (Page Cache) rất hay gây ra cảnh tượng dở khóc dở cười là Administrator nhìn thấy giao diện mới toanh nhưng khách truy cập ngoài đời vẫn nhìn thấy trang web từ… tuần trước.

Đừng quên chạy lệnh wp plugin list để lưu lại danh sách phiên bản thực tế vào sổ tay vận hành sau khi cài xong. Dòng chữ báo “Plugin activated” màu xanh trên màn hình chỉ có nghĩa là PHP nạp file khởi chạy mà không văng lỗi cú pháp ngay lập tức, chứ hoàn toàn chưa chứng minh tính năng đó hoạt động trơn tru với hệ thống của bạn. Ngoài ra, nếu plugin yêu cầu kết nối dịch vụ bên ngoài qua API Key, hãy cấu hình thông qua cơ chế chuẩn được nhà phát triển hỗ trợ, giữ kín chuỗi khóa bí mật ngoài tầm mắt của ảnh chụp màn hình, file log hay kho chứa Git, đồng thời chỉ cấp cho khóa API đó phạm vi quyền hạn (scope) tối thiểu đủ dùng.

Sơ đồ quy trình xác minh và khôi phục do localhost.vn biên soạn; đây là hình vẽ tóm tắt luồng thao tác, không phải ảnh chụp màn hình hay kết quả chạy lệnh trên lab.

Cứu hộ khẩn cấp: làm gì khi website lăn ra lỗi ngay sau khi kích hoạt?

Giả sử vừa bấm kích hoạt một plugin mới mà cả trang web lẫn trang /wp-admin/ lập tức biến thành màn hình trắng xóa (White Screen of Death) hoặc báo lỗi 500: bình tĩnh, đừng hoảng! Miễn là bạn vẫn còn cửa sổ kết nối SSH vào máy chủ, bạn chỉ cần gõ lệnh wp plugin deactivate SLUG_DA_CHON để tắt ngay thủ phạm vừa thêm rồi tải lại trang web để đối chiếu. Trong trường hợp plugin mới gặp lỗi PHP nghiêm trọng (Fatal Error) khiến chính công cụ WP-CLI cũng bị kẹt cứng khi khởi tạo, hãy thêm cờ --skip-plugins (hoặc --skip-plugins=SLUG_LOI) theo đúng tài liệu hướng dẫn, hoặc dùng lệnh hệ điều hành đổi tên đúng thư mục của riêng plugin đó trong wp-content/plugins/ và ghi chép lại thao tác cứu hộ. Nhớ kỹ: khi đã biết đích danh plugin vừa cài gây lỗi, đừng bao giờ vung tay đổi tên cả thư mục cha wp-content làm ảnh hưởng toàn bộ ảnh và giao diện của trang web.

Tương tự, nếu giao diện mới làm vỡ nát bố cục trang web, bạn có thể chuyển nhanh về giao diện ổn định trước đó bằng lệnh wp theme activate SLUG_THEME_TRUOC. Sau khi chuyển, hãy kiểm tra cả hai thông số cấu hình stylesheet và template trong cơ sở dữ liệu so với bản ghi chép ban đầu — vì nếu website sử dụng Child Theme, hai giá trị này sẽ khác nhau chứ không giống hệt như khi dùng theme đơn lẻ. Đừng chỉ nhìn thoáng qua dòng chữ bản quyền dưới chân trang (footer) để đoán mò xem theme nào đang chạy. Một điểm cực kỳ quan trọng nữa: nếu plugin hoặc theme vừa kích hoạt đã kịp chạy script thay đổi cấu trúc bảng (database schema) hoặc ghi đè dữ liệu trong bảng wp_options, thao tác deactivate thông thường sẽ không tự động hoàn tác (rollback) những thay đổi ngầm đó. Lúc này, bản sao lưu mã nguồn và cơ sở dữ liệu (Database Backup) mà bạn tạo trước khi cài đặt mới chính là phao cứu sinh đáng tin cậy nhất — tất nhiên khi khôi phục từ bản backup, bạn cần cân nhắc xem trong khoảng thời gian ngắn vừa qua có đơn hàng hay bình luận mới nào của khách phát sinh hay không.

Ảnh chụp giao diện thực tế ngày 01/10/2026 lúc 18:23:12; hộp thoại chào mừng của trình soạn thảo khối (Block Editor) hiện đè lên màn hình sau khi tắt Classic Editor. Giữ nguyên pixel gốc, gắn thêm logo; bấm vào ảnh để xem đầy đủ. Ảnh xác nhận giao diện soạn thảo mặc định đã phục hồi, không bao gồm thao tác lưu bài viết mới.

Quay lại kịch bản thực hành trên máy chủ lab của chúng ta (vốn đang chạy giao diện gốc Twenty Twenty-Five 1.5 độc lập, không dùng Child Theme): ngay sau khi tắt plugin thử nghiệm, chúng tôi chạy lệnh wp --path="$WP_ROOT" theme activate twentytwentyfive và mở lại trang ngoài mặt tiền để xác nhận giao diện khách đã trở về nguyên vẹn trước khi dọn dẹp các gói vừa cài. Chỉ khi đối chiếu với danh sách ban đầu và chắc chắn 100% rằng Classic Editor cùng Twenty Twenty-One là hai món mới tinh vừa được thêm trong phiên thực hành này, chúng ta mới gõ lệnh gỡ bỏ hoàn toàn: wp --path="$WP_ROOT" plugin uninstall classic-editor tiếp nối bằng wp --path="$WP_ROOT" theme delete twentytwentyone. Nếu có bất kỳ cảnh báo lỗi nào xuất hiện, hãy dừng tay ngay để kiểm tra; và dĩ nhiên đừng bao giờ copy-paste máy móc hai cái tên slug này vào một website đang thực sự sử dụng chúng để vận hành! Cuối cùng, hãy đọc lại danh sách plugin/theme cùng hai giá trị stylesheet và template, giữ nguyên bản sao lưu dự phòng cho tới khi mọi bước đối chiếu hậu kỳ đều hoàn tất mỹ mãn.

Câu hỏi thường gặp (FAQ)

Tôi là chủ trang web, cứ dùng luôn tài khoản Administrator để viết bài hằng ngày cho tiện có sao không? Rất không nên! Việc tách riêng một tài khoản Editor hoặc Author để viết bài hằng ngày giúp bạn tránh được những tai nạn “trượt tay” sửa nhầm cấu hình hệ thống, đồng thời giảm thiểu thiệt hại nếu chẳng may phiên đăng nhập trên chiếc laptop bạn mang ra quán cà phê bị lộ cookie hoặc đánh cắp mật khẩu. Hãy cất chiếc chìa khóa Administrator vào két sắt và chỉ lấy ra khi thực sự cần quản trị hệ thống.

Tải plugin từ kho chính thức WordPress.org thì có yên tâm an toàn 100% không? Không có bất kỳ kho ứng dụng nào trên đời dám bảo lãnh an toàn tuyệt đối 100% mãi mãi. Một plugin hôm nay rất tốt nhưng năm sau đổi chủ sở hữu hoặc ngừng bảo trì vẫn có thể phát sinh lỗ hổng. Kho chính thức là điều kiện cần để đảm bảo nguồn gốc minh bạch, nhưng bạn vẫn phải duy trì thói quen rà soát nhu cầu, theo dõi lịch cập nhật và thử nghiệm kỹ trên môi trường lab trước khi đưa lên site chính.

Khi xóa một tài khoản nhân sự nghỉ việc thì các bài viết của họ có bị mất theo không? Điều này hoàn toàn nằm ở cú click chuột của bạn tại màn hình xác nhận xóa user (hoặc tham số --reassign trong WP-CLI). Hãy luôn đọc kỹ và chọn gán lại toàn bộ bài viết, trang tĩnh của người đó sang cho một tài khoản biên tập khác đang hoạt động trước khi bấm nút xác nhận xóa.

Bạn có thể tự tin đánh dấu hoàn thành bài thực hành này khi: các tài khoản phân quyền thấp hoạt động đúng phạm vi công việc được giao, mọi theme/plugin cài trên máy đều rõ nguồn gốc và số phiên bản, các tính năng đã được xác minh thực tế, và bạn nắm vững thao tác khôi phục (rollback) lại thành phần vừa thay đổi.

Báo cáo thực nghiệm phân quyền qua REST API trên LAB-CF-02

Đợt đối chiếu phân quyền thông qua giao thức REST API ngày 30/09/2026 được hoàn tất trong khung giờ 23:54:09–23:54:15 (UTC+7) trên nền tảng WordPress 7.1.2. Tại thời điểm bắt đầu, máy chủ lab chỉ có duy nhất một tài khoản Administrator gốc và không bật bất kỳ plugin nào. Hai tài khoản thử nghiệm mang vai trò Editor và Contributor được khởi tạo trực tiếp bằng công cụ quản trị dòng lệnh phục vụ riêng cho phiên đo kiểm này, hoàn toàn không thao tác qua biểu mẫu Add New trên trình duyệt.

Toàn bộ các truy vấn trong đợt này sử dụng Application Password tạm thời truyền qua kết nối HTTPS với cơ chế xác thực chứng chỉ TLS mặc định; tập tin nhật ký (log) được lọc sạch không lưu giữ mật khẩu. Kết quả bảng trên phản ánh chính xác ranh giới quyền hạn đối với các endpoint REST đã thử nghiệm trên lab, tất nhiên chưa đại diện cho toàn bộ danh sách Capabilities, giao diện menu quản trị, quyền sửa bài chéo giữa nhiều tác giả hay trường hợp có plugin can thiệp vào hệ thống phân quyền.

Trong đợt chạy REST ngày 30/09/2026 này, chúng tôi không tạo thêm Administrator mới, không cài đặt hay kích hoạt theme/plugin, không đăng nhập qua giao diện web Dashboard và cũng không gửi email. Các phần thực nghiệm chuyển đổi theme có sẵn và thao tác trên trình duyệt ngày 01/10 được tách bạch rõ ràng ở các mục ngay bên dưới. Sau khi kết thúc đợt đo REST, toàn bộ dữ liệu thử nghiệm đã được dọn sạch, đưa website trở về đúng trạng thái chuẩn: một user quản trị, hai bài viết đã xuất bản và không có tập tin đính kèm (attachment).

Báo cáo xác minh Admin login và vai trò Editor trên trình duyệt (01/10)

Tính đến mốc 17:38:19 (UTC+7) ngày 01/10/2026, đợt thực nghiệm trên trình duyệt đã sử dụng tài khoản Administrator hiện hữu để đăng nhập, mở trang Dashboard và thực hiện đăng xuất (logout) an toàn. Khi gõ lại đường dẫn /wp-admin/ sau khi đăng xuất, hệ thống lập tức chặn lại và yêu cầu đăng nhập. Bức ảnh đầu bài viết chỉ ghi lại giao diện biểu mẫu trống trước khi gõ mật khẩu; đợt chạy này cũng không tạo thêm tài khoản admin mới. Ngoài ra, công cụ Site Health lúc này vẫn ghi nhận một vấn đề về cập nhật nền (background updates) và sáu mục khuyến nghị cải thiện, nên chúng ta ghi nhận trung thực hiện trạng thay vì tuyên bố mọi chỉ số đều xanh mượt.

Tiếp đó, phiên thực nghiệm dành riêng cho tài khoản Editor hoàn tất lúc 18:02:11 đã xác nhận: cột menu bên trái hoàn toàn vắng bóng các mục quản lý Plugin, Giao diện (Appearance) hay Thành viên (Users), đồng thời khi cố tình truy cập thẳng vào địa chỉ trang quản lý plugin thì máy chủ trả về mã lỗi 403. Ở chiều ngược lại, tài khoản Editor thực hiện gõ tiêu đề và đoạn văn tiếng Việt có dấu, bấm lưu nháp rồi tải lại trang (reload) vẫn giữ nguyên vẹn dữ liệu; tiếp tục sửa câu chữ, lưu lại, mở trang xem trước (preview) và bấm xuất bản (publish) qua hai bước xác nhận chuẩn của trình soạn thảo khối. Khi kiểm tra bằng cửa sổ khách (chưa đăng nhập) ở cả hai độ phân giải màn hình 1440px (máy tính) và 390px (điện thoại), đường dẫn bài viết đều trả về mã HTTP 200 với đúng tiêu đề và nội dung vừa sửa, không hề lộ thanh công cụ quản trị (Admin Bar) và không bị vỡ khung tràn ngang.

Ảnh chụp giao diện thực tế ngày 01/10/2026 thuộc đợt xác minh tài khoản Editor hoàn tất lúc 18:02:11, ngay sau thao tác lưu nháp kèm tải lại trang và trước bước chỉnh sửa câu văn tiếp theo. Giữ nguyên pixel gốc, gắn logo; bấm vào ảnh để xem đầy đủ. Đây là bằng chứng thao tác biên tập nội dung của Editor, không phải thao tác cài đặt plugin.

Sau khi hoàn tất và xóa bỏ tài khoản cùng bài viết thử nghiệm, trạng thái website quay về đúng vạch xuất phát: một user duy nhất, hai bài viết công khai, không còn bản nháp hay tập tin đính kèm nào. Chúng tôi cũng đã đối chiếu mã băm (hash) của các bài viết cũ, tập tin wp-config.php, index.php, danh sách plugin đang bật và cấu hình chặn lập chỉ mục (noindex) — tất cả đều khớp 100% với trạng thái trước khi thử nghiệm. Tất nhiên, việc chặn truy cập trang plugin chỉ chứng minh hệ thống phân quyền hoạt động đúng ở khía cạnh đó; nếu quy trình làm việc của đội bạn yêu cầu kiểm soát chi tiết việc sửa bài viết của nhau hoặc có dùng plugin tùy biến lại Role, bạn sẽ cần thực hiện thêm bài test chuyên biệt.

Báo cáo thực nghiệm chuyển đổi và khôi phục Theme (01/10/2026)

Đợt thử nghiệm chuyển đổi giao diện trên máy chủ LAB-CF-02 diễn ra vào khung giờ 00:13–00:14 (UTC+7) ngày 01/10/2026. Cả hai bộ giao diện đều đã nằm sẵn trên ổ cứng từ trước: Twenty Twenty-Five 1.5 đang ở trạng thái kích hoạt (active) và Twenty Twenty-Four 1.6 đang ở trạng thái chờ (inactive). Trong lượt chạy ngắn này, chúng tôi không tải mới, không cài thêm và cũng không nâng cấp phiên bản của bất kỳ gói nào.

Quan sát trực tiếp trên trình duyệt cho thấy giao diện trang web đã thay đổi rõ rệt và bài viết tiếng Việt vẫn hiển thị chuẩn xác, không xảy ra hiện tượng vỡ khung hay thanh cuộn ngang ở cả màn hình lớn 2048px lẫn màn hình di động 390px. Ngay sau khi chuyển về giao diện gốc ban đầu, mọi tiêu đề, nội dung bài viết và cờ chặn index đều giữ nguyên. Lưu ý rằng bài test nhanh này tập trung vào hiển thị trang bài viết, chưa mở rộng sang các biểu mẫu tương tác (form), khung đăng nhập hay toàn bộ các mẫu trang tĩnh (page templates) khác của theme.

Bản sao lưu cơ sở dữ liệu (SQL dump) tạo riêng trên VPS đóng vai trò điểm chốt an toàn (chưa cần dùng tới lệnh restore trong lượt này và cũng không phải là bản sao lưu offsite ngoài máy chủ). Dù toàn bộ các chỉ số nội dung đối chiếu sau khi khôi phục theme gốc đều khớp tuyệt đối, chúng ta không vội kết luận cả cơ sở dữ liệu giống hệt từng byte so với trước lúc bấm nút — bởi lẽ bản thân WordPress hoàn toàn có thể khởi tạo hoặc cập nhật các bản ghi theme_mods / options dành riêng cho từng giao diện. Khi khép lại bài test, giao diện Twenty Twenty-Five đang hoạt động bình thường.

Báo cáo vòng đời cài đặt – kích hoạt – gỡ bỏ phần mềm lúc 18:22–18:23

Vào chiều tối ngày 01/10/2026, chúng tôi thực hiện trọn vẹn quy trình cài mới và gỡ bỏ phần mềm theo các mốc thời gian thực tế (giờ Việt Nam) dưới đây. Đợt này không tạo thêm Administrator mới mà sử dụng trực tiếp tài khoản quản trị hiện hữu để quan sát trên trình duyệt Dashboard, kết hợp chạy lệnh WP-CLI dưới quyền user triển khai. Hai gói phần mềm được tải trực tiếp từ kho chính thức downloads.wordpress.org đúng số phiên bản đã nêu; bản sao lưu SQL riêng được khởi tạo trước khi cài, giữ nguyên để phòng hờ cho tới khi đối chiếu hậu kỳ thành công rồi mới dọn dẹp (không cần phải chạy lệnh restore SQL).

Xuyên suốt cả 6 giai đoạn trên, chúng tôi đều mở kiểm tra bài viết dưới góc nhìn khách truy cập ở cả hai độ phân giải màn hình (tổng cộng 12 lượt tải trang đều trả về mã HTTP 200 đúng nội dung và không hề vỡ bố cục). Ở bước dọn dẹp hậu kỳ, các bản nháp tự động (auto-draft) và bản ghi global_styles do trình soạn thảo sinh ra khi mở giao diện đã được xóa gọn gàng; đưa cơ sở dữ liệu về đúng con số 1 user, 2 bài viết công khai và 0 bản nháp hay file đính kèm. Mã băm (hash) của nội dung bài viết, tập tin wp-config.php và index.php khớp tuyệt đối với thời điểm trước khi thực hành; danh sách cùng phiên bản plugin/theme, hai trường stylesheet, template, trạng thái không có plugin active và cấu hình noindex đều được bảo toàn nguyên vẹn. Các script hỗ trợ tạm, bản dump SQL dự phòng đã được xóa sạch và đóng trình duyệt.

Đợt thực nghiệm này chứng minh quy trình cài đặt, kích hoạt, tắt và gỡ bỏ phần mềm kết hợp kiểm chứng giao diện; tất nhiên nó chưa bao gồm bài toán nâng cấp một plugin đang ôm hàng ngàn dòng dữ liệu sống hay diễn tập tình huống plugin văng lỗi sập web. Chúng ta cũng không tuyên bố cơ sở dữ liệu giống hệt từng byte, chưa thử gửi email khôi phục mật khẩu hay xuất bản bài viết mới từ trong Classic Editor. Phần tạo tài khoản Administrator mới được tách riêng sang đợt thực nghiệm ngày 02/10 ngay dưới đây (còn thao tác lưu và xuất bản bài viết của Editor lúc 18:02 thuộc về bài test trình soạn thảo khối mặc định).

Báo cáo tạo Administrator mới và thu hồi phiên đăng nhập (02/10/2026)

Đợt thực nghiệm hoàn tất lúc 14:03:46 (UTC+7) ngày 02/10/2026 đã chạy nguyên vẹn khối lệnh WP-CLI hướng dẫn ở đầu bài dưới quyền tài khoản hệ điều hành tutorial ngay trên máy chủ lab. Tài khoản mới khởi tạo mang vai trò Administrator; khi dùng lệnh đối chiếu các quyền cốt lõi gồm manage_options, install_plugins và create_users thì tất cả đều trả về kết quả được phép. Tiếp đó, chúng tôi mở một phiên trình duyệt độc lập, đăng nhập bằng mật khẩu vừa nhập qua luồng tương tác và truy cập trơn tru vào cả hai trang Tài khoản (Users) lẫn Plugin.

Ảnh chụp màn hình thực tế ngày 02/10/2026 khi lọc riêng tài khoản thử nghiệm; cắt giữ nguyên độ phân giải pixel và gắn thêm logo. Đuôi tên miền example.invalid là chuẩn tên miền dành riêng cho mục đích thử nghiệm kỹ thuật (đảm bảo không gửi nhầm thư ra ngoài Internet), tuyệt đối không dùng cho tài khoản quản trị thật khi vận hành. Quá trình tạo user này không phát sinh lệnh gửi email.

Ảnh chụp thực tế trong cùng đợt xác minh: tài khoản Administrator mới mở được trang quản lý Plugin với đầy đủ nút chức năng. Hai plugin mặc định đang ở trạng thái tắt (inactive); đợt cài đặt thử Classic Editor ngày 01/10 là một phiên thực nghiệm độc lập đã được gỡ bỏ như báo cáo phía trên.

Ngay sau khi xác minh xong quyền hạn, chúng tôi thực hiện thu hồi toàn bộ phiên đăng nhập (session tokens) của đúng tài khoản thử nghiệm đó, dọn dẹp bản nháp tự động rỗng do trang Dashboard tạo ra rồi xóa sổ tài khoản thử nghiệm, giữ nguyên vẹn tài khoản quản trị viên gốc ban đầu. Khi quay lại cửa sổ trình duyệt vẫn đang lưu cookie đăng nhập của tài khoản vừa bị xóa và bấm tải lại trang quản lý, hệ thống lập tức đá văng phiên làm việc về lại màn hình đăng nhập trống.

Ảnh chụp thực tế sau khi thu hồi phiên làm việc, hoàn toàn không lộ mật khẩu hay chuỗi cookie trong hình; cắt nguyên pixel gốc và gắn logo. Kết quả này chứng minh tính năng thu hồi phiên đăng nhập có hiệu lực tức thì, không phải bài test gửi email đặt lại mật khẩu.

Đối chiếu lại với trạng thái chuẩn (baseline) trước khi thử nghiệm, danh sách người dùng trên hệ thống đã trở về đúng một tài khoản Administrator gốc duy nhất. Mã băm của các bài viết và trang tĩnh, nội dung tập tin wp-config.php, index.php, giao diện đang chạy, danh sách plugin active và cờ noindex đều giữ nguyên không đổi. Trình duyệt thử nghiệm đã được đóng, các tập tin script phụ trợ cũng đã được xóa sạch. Tất nhiên, do WordPress có thể ghi nhận thêm các chỉ số metadata vận hành nội bộ, chúng ta không kết luận toàn bộ cơ sở dữ liệu khớp tuyệt đối từng byte.

Bài học đắt giá rút ra từ phòng lab: trong lần thử nghiệm đầu tiên, khi chúng tôi chỉ gọi lệnh stty -echo trước khi kích hoạt cờ --prompt=user_pass của WP-CLI, mật khẩu gõ vào vẫn bị in lộ liễu ra luồng kết quả của chương trình! Phiên thử nghiệm đó lập tức được hủy bỏ và dọn sạch, không công bố log chứa thông tin nhạy cảm. Đoạn mã chuẩn đã hiệu chỉnh ở đầu bài chuyển sang dùng read -s của Bash kết hợp truyền qua ống stdin và cờ --quiet. Kết quả thực nghiệm xác nhận mật khẩu đã biến mất hoàn toàn khỏi đầu ra, nhưng nguyên tắc an toàn tối thượng vẫn là không bao giờ bật ghi log màn hình (transcript) hay chụp ảnh lúc đang gõ mật khẩu.

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

Tài liệu mã nguồn được tra cứu và đối chiếu ngày 02/10/2026: Mã nguồn WP-CLI xử lý luồng prompt tương tác và ghi nhận tham số. Đoạn mã nguồn này giải thích rõ tại sao cơ chế prompt mặc định có thể tương tác lại với luồng xuất; còn việc khẳng định mật khẩu không bị lộ là kết quả thực nghiệm từ đoạn script Bash đã được chúng tôi tinh chỉnh.

Trang thông tin của hai gói phần mềm trong ví dụ thực hành được truy cập ngày 01/10/2026. Các tài liệu kỹ thuật chính thức được đối chiếu cùng ngày gồm: WP-CLI: lệnh user create và cơ chế nhập tương tác, WP-CLI: cài đặt plugin, WP-CLI: đối chiếu mã băm checksum của plugin, WP-CLI: cài đặt theme, WordPress Documentation: Roles and Capabilities (Vai trò và Quyền hạn), WP-CLI: kích hoạt theme, WP-CLI: liệt kê danh sách theme, và WordPress Code Reference: hàm switch_theme(). Nhóm tài liệu nền tảng được đối chiếu từ ngày 30/09/2026: WP-CLI Handbook: hướng dẫn cài đặt chuẩn, WordPress Advanced Administration: gia cố bảo mật (Hardening), cùng WordPress REST API Handbook: các phương thức xác thực. Toàn bộ kịch bản xử lý sự cố và biểu mẫu đối chiếu 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 tổng quan 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: Quyền file WordPress — truy tìm nguyên nhân gốc rễ gây lỗi ghi file. Bài tiếp theo: Nghiệm thu trang chủ, bài viết, Media Library, Permalink và đăng nhập sau khi cài đặt.