Nâng Cấp PHP 8.x Cho WordPress An Toàn: Hướng Dẫn A-Z Từ Kiểm Tra Đến Rollback

Mấy hôm trước mình nghe lại podcast của WP Tavern với Milan Petrović, người đứng sau plugin GD Rating System, và anh ấy nói một câu khiến mình ngồi dậy hẳn: phần lớn admin WordPress lo lắng đủ thứ về plugin, theme, firewall, nhưng lại đang chạy site của mình trên nền PHP đã lỗi thời từ nhiều năm. Đúng thật, mình từng rà soát vài chục VPS khách hàng và số site chạy PHP 7.4 hoặc cũ hơn còn nhiều hơn mình tưởng. Bài này mình sẽ hướng dẫn từ A đến Z cách kiểm tra phiên bản PHP đang chạy, đánh giá độ tương thích, nâng cấp lên PHP 8.x an toàn và quay lui được nếu có sự cố, toàn bộ bằng dòng lệnh.

PHP cũ gây rủi ro gì cho website WordPress?

Ngắn gọn: PHP cũ nghĩa là bạn tự đóng cửa bảo mật rồi chờ người ta đến. PHP 7.4 đã kết thúc vòng đời hỗ trợ từ lâu, mọi lỗ hổng phát hiện sau đó sẽ không bao giờ được vá chính thức. Kẻ tấn công chỉ cần quét header hoặc probe một file đặc thù là biết site bạn chạy PHP mấy, từ đó dùng khai thác có sẵn. Ngoài bảo mật, PHP 8.x còn cho hiệu năng tốt hơn hẳn: JIT compiler, OPcache cải tiến, các tối ưu ở core giúp trang WordPress render nhanh hơn đáng kể mà không đổi một dòng code nào.

Làm sao kiểm tra website đang chạy PHP phiên bản nào?

Có ba cách, mình hay dùng cả ba để đối chiếu. Cách nhanh nhất là SSH vào server rồi gõ lệnh trực tiếp. Nếu dùng shared hosting thì vào cPanel hoặc panel của nhà cung cấp, mục Select PHP Version hoặc MultiPHP Manager sẽ hiển thị. Cách thứ ba, tận dụng WP-CLI mà không cần vào bảng điều khiển nào:

# Xem phiên bản PHP của CLI hiện tại
php -v

# Xem PHP mà web server thực sự dùng (qua WP-CLI)
wp cli info

# Rà soát toàn bộ site xem có báo lỗi environment không
wp doctor check --all

Lưu ý quan trọng: phiên bản PHP của dòng lệnh và của web server có thể khác nhau, đặc biệt trên VPS cài nhiều PHP qua phpswitch hoặc sury.org. Đừng nhìn php -v xong tưởng mọi thứ ổn rồi thôi, hãy kiểm tra cả phpinfo thật của site.

WordPress và plugin của bạn đã sẵn sàng cho PHP 8.x chưa?

Đây là bước hầu như mọi người bỏ qua, rồi nâng cấp xong trắng trang mới hoảng. Trước khi động vào PHP, mình luôn rà compat trước. WordPress core từ phiên bản 6.x trở đi yêu cầu tối thiểu PHP 7.2 và chạy tốt trên 8.3, 8.4. Vấn đề nằm ở plugin và theme cũ, nhất là mấy plugin form, slider tải từ nguồn lạ chưa update ba bốn năm.

# Liệt kê plugin đã cũ hoặc bị bỏ, ứng viên gây lỗi khi nâng PHP
wp plugin list --fields=name,version,update --format=table

# Cập nhật hết plugin, theme trước khi nâng PHP
wp plugin update --all
wp theme update --all

# Xem health check của site theo chuẩn WordPress
wp core verify-checksums
wp doctor check --all

Mẹo của mình: nếu một plugin đã hơn 24 tháng không cập nhật và không có bản thay thế, hãy chủ động gỡ hoặc tìm alternative ngay bây giờ, đừng đợi nó hỏng sau khi nâng PHP. Plugin chết trên PHP 8 thường chết vì hàm create_function() hoặc curly braces trong string, hai thứ bị xóa hoàn toàn từ PHP 8.

Quy trình nâng cấp PHP 8.x an toàn từng bước thế nào?

Nguyên tắc vàng của mình: luôn nâng từng nhánh lớn một lần, không nhảy cóc từ 7.4 lên 8.4 luôn. Đi 7.4 lên 8.0, ổn rồi mới lên 8.2, 8.3. Mỗi bước cách nhau ít nhất một ngày chạy thật. Và tuyệt đối có bản backups đủ bộ: database, thư mục wp-content và cấu hình web server.

# Bước 1: Backup đủ bộ trước khi làm gì
wp db export backup-before-php.sql
tar -czf wp-content-backup.tar.gz wp-content/

# Bước 2: Trên Ubuntu/Debian cài nhánh PHP mới (ví dụ 8.3)
sudo apt install php8.3-fpm php8.3-mysql php8.3-curl 
  php8.3-xml php8.3-mbstring php8.3-gd php8.3-imagick 
  php8.3-zip php8.3-intl php8.3-opcache

# Bước 3: Chạy linter toàn bộ code trên nhánh PHP mới
# để bắt lỗi cú pháp trước khi chuyển thật
find /var/www/site/public_html -name "*.php" 
  -exec php8.3 -l {} ; 2>&1 | grep -v "No syntax errors"

# Bước 4: Chuyển web server sang PHP-FPM mới (Nginx)
sudo systemctl enable --now php8.3-fpm
# Sửa upstream socket trong config Nginx:
# fastcgi_pass unix:/run/php/php8.3-fpm.sock;
sudo nginx -t && sudo systemctl reload nginx

Bước 3 là bước mình thấy đáng giá nhất mà ít ai làm: linter chạy toàn bộ file PHP bằng nhánh mới sẽ liệt kê chính xác file nào chết cú pháp, bạn vá xong rồi mới chuyển, thay vì mò mẫm trong error log sau khi trắng trang.

Cấu hình OPcache nào để PHP 8.x chạy nhanh nhất?

Nâng PHP mà không chỉnh OPcache là phí một nửa công sức. OPcache giữ bytecode đã compile trong RAM, WordPress có hàng nghìn file include mỗi request nên khác biệt rất rõ. Mình dùng bộ cấu hình sau cho VPS 2GB RAM:

; /etc/php/8.3/fpm/php.ini
opcache.enable = 1
opcache.memory_consumption = 192
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 16000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

Giải thích nhanh: revalidate_freq = 60 nghĩa là OPcache kiểm tra file thay đổi mỗi 60 giây, vừa nhanh vừa không bị cache file cũ khi bạn sửa code. Nếu site đã ổn định, có thể tăng lên 300. Sau khi sửa, khởi động lại FPM bằng sudo systemctl restart php8.3-fpm rồi đo lại tốc độ bằng wp package hoặc PageSpeed.

Sau khi nâng cấp cần kiểm tra những gì và làm sao quay lui?

Checklist 10 phút ngay sau khi nhấn chuyển: mở trang chủ, một bài viết, một trang liên hệ có form, thử đăng nhập wp-admin, xem giỏ hàng nếu có WooCommerce, và chạy wp doctor check --all. Đồng thời theo dõi error log trực tiếp:

# Theo dõi error log của FPM trong thời gian thực
sudo tail -f /var/log/php8.3-fpm.log

# Xem error log của site
tail -f /var/www/site/logs/error.log

# Nếu catastrophically fail, quay về nhánh PHP cũ trong 30 giây:
sudo systemctl disable --now php8.3-fpm
sudo systemctl enable --now php8.2-fpm
# Đổi lại fastcgi_pass về socket cũ rồi:
sudo nginx -t && sudo systemctl reload nginx

Chính vì có đường quay lui 30 giây này mà mình luôn cài song song nhiều nhánh PHP-FPM thay vì ghi đè. Khả năng rollback nhanh quan trọng hơn mọi benchmark.

Kết luận

Nâng PHP 8.x cho WordPress là một trong những việc cho lợi ích cao nhất so với công sức bỏ ra: bảo mật được vá liên tục, tốc độ tăng miễn phí, và các bản WordPress mới dần sẽ yêu cầu tối thiểu cao hơn. Nếu bạn vẫn đang chạy PHP 7.4 hoặc cũ hơn, hãy dành một buổi tối cuối tuần này làm theo quy trình bên trên: kiểm tra, lint, nâng từng bước, chỉnh OPcache, giữ đường quay lui. Site bạn sẽ khỏe hơn và bạn cũng ngủ ngon hơn. Nếu muốn đi sâu tiếp, bài hướng dẫn cấu hình Redis Object Cache và bài bật Brotli cho WordPress là cặp bài bổ sung rất hợp sau khi xong PHP.