Mới đây trong một podcast trên WP Tavern, Milan Petrović — tác giả của GD Custom Posts và Dev4Press — đã nói thẳng một sự thật mà nhiều admin web vẫn làm ngơ: phần lớn site WordPress bị hack hiện nay không phải vì plugin xấu, mà vì đang chạy PHP quá cũ. PHP 7.4 đã hết hạn hỗ trợ từ lâu, PHP 8.0 và 8.1 cũng vậy, nghĩa là mọi lỗ hổng mới phát hiện ở các nhánh này sẽ không bao giờ được vá. Trong bài này, mình sẽ hướng dẫn bạn nâng cấp PHP cho server WordPress từ A đến Z, an toàn tuyệt đối, có rollback nếu lỗi.
Tại sao phải nâng cấp PHP cho WordPress ngay bây giờ?
PHP là ngôn ngữ chạy toàn bộ nhân WordPress, nên phiên bản PHP quyết định cả tốc độ lẫn bảo mật của site. PHP 8.x nhanh hơn PHP 7.4 khoảng 25-40% trong các benchmark thực tế với WordPress, đồng thời được vá lỗi liên tục. Ngược lại, chạy PHP đã end-of-life nghĩa là bạn tự mở cửa cho kẻ xấu: chỉ cần một lỗ hổng RCE mới được công bố, server của bạn nằm trong danh sách mục tiêu đầu tiên. Theo Petrović, đây là nguyên nhân sâu xa đứng sau rất nhiều vụ “dọn malware đi lại quay trở lại”.
Bước 0: Kiểm tra phiên bản PHP hiện tại và yêu cầu của WordPress
Trước khi động vào bất cứ thứ gì, bạn phải biết mình đang đứng ở đâu. SSH vào server và chạy:
# Xem phiên bản PHP đang chạy trên web server
php -v
# Xem PHP nào mà site thực sự dùng (có thể khác CLI)
echo "<?php echo PHP_VERSION;" | php
# Với các site shared hosting, tạo file info.php chứa:
<?php phpinfo();
# Truy cập https://domain.com/info.php rồi XÓA NGAY sau khi xem xongHiện tại WordPress yêu cầu tối thiểu PHP 7.2.24 nhưng khuyến nghị PHP 8.1 trở lên. Nếu bạn đang ở PHP 7.4 hoặc thấp hơn, bài này dành cho bạn. Nếu đã ở 8.1, hãy nhắm tới 8.2 hoặc 8.3.
Bước 1: Backup toàn bộ — bước không được bỏ qua
Mình đã chứng kiến quá nhiều người bỏ qua bước này rồi ăn hối hận. Backup phải bao gồm cả file lẫn database, và bạn phải kiểm tra backup đó khôi phục được thật sự:
# Backup database
wp db export backup-before-php.sql --path=/var/www/thienlv.com/public_html
# Backup toàn bộ source code
tar -czf /root/backup-code-$(date +%F).tar.gz /var/www/thienlv.com/public_html
# Lưu lại phiên bản PHP hiện tại để biết đường rollback
php -v | head -1 > /root/php-version-before.txtNếu dùng VPS, tạo snapshot toàn máy chủ trước khi nâng cấp luôn là lựa chọn an toàn nhất.
Bước 2: Quét plugin và theme có tương thích PHP 8.x không?
Đây là bước khiến 90% lỗi sau nâng cấp xảy ra, nên bạn phải làm kỹ. Plugin cũ dùng hàm đã bị xóa như create_function() hay each() sẽ giết chết site ngay khi PHP đổi phiên bản. Cách kiểm tra:
# Cài plugin Health Check để xem cảnh báo tương thích
wp plugin install health-check --activate --path=/var/www/thienlv.com/public_html
# Liệt kê plugin đã lâu không cập nhật (dấu hiệu bỏ rơi)
wp plugin list --fields=name,version,update_version --path=/var/www/thienlv.com/public_htmlNguyên tắc của mình: plugin nào hơn 2 năm không cập nhật thì tìm replacement ngay, đừng hy vọng. Danh sách plugin popular thì tham khảo trang Plugin Directory trên WordPress.org, tab “Tested up to” phải từ WordPress 6.x trở lên.
Bước 3: Thử trên staging trước khi sửa server thật
Không bao giờ nâng cấp PHP trực tiếp trên site đang chạy trừ khi bạn chấp nhận downtime. Nếu hosting có tính năng staging thì dùng nó. Với VPS, cách nhanh nhất là nhân bản bằng cách chỉnh file hosts trên máy tính của bạn:
# Trên Ubuntu/Debian, cài thêm PHP 8.3 song song (không đụng bản cũ)
sudo apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-xml php8.3-mbstring
# Kiểm tra PHP 8.3 chạy song song
sudo systemctl status php8.3-fpmCách này hay ở chỗ bản PHP cũ vẫn còn nguyên, muốn quay lại chỉ cần đổi một dòng cấu hình.
Bước 4: Chuyển Nginx hoặc Apache sang PHP 8.x
Sau khi PHP 8.x đã chạy song song, bạn chỉ cần trỏ web server sang socket mới:
# NGINX: sửa trong vhost của site, ví dụ /etc/nginx/sites-available/thienlv.com
# Đổi dòng upstream php-fpm:
fastcgi_pass unix:/run/php/php8.3-fpm.sock; # trước đây là php7.4-fpm.sock
# Reload nginx
sudo nginx -t && sudo systemctl reload nginx
# APACHE: chuyển handler
sudo a2dismod php7.4
sudo a2enmod php8.3
sudo systemctl restart apache2Ngay sau khi reload, mở site ở chế độ ẩn danh và mở wp-admin để quan sát. Nếu màn hình trắng hoặc báo Fatal error: Uncaught Error: Call to undefined function, tức là có plugin dùng hàm đã loại bỏ — quay lại Bước 2.
Bước 5: Kiểm tra sau nâng cấp và đo tốc độ
Site lên được chưa phải là xong. Bạn cần xác minh cả ba thứ: chức năng, tốc độ, và error log:
# Xem error log 100 dòng cuối
sudo tail -100 /var/log/php8.3-fpm.log
sudo tail -100 /var/log/nginx/error.log
# Kiểm tra deprecated warnings trong WP debug
wp config set WP_DEBUG true --raw --path=/var/www/thienlv.com/public_html
# Xem xong nhớ tắt lại:
wp config set WP_DEBUG false --raw --path=/var/www/thienlv.com/public_htmlVề tốc độ, mình hay đo lại bằng PageSpeed Insights trước và sau nâng cấp. Thực tế trên các site mình quản lý, chuyển từ PHP 7.4 lên 8.3 giúp TTFB giảm khoảng 20-30%, đủ để cải thiện rõ Core Web Vitals. Bạn có thể đọc thêm bài tối ưu tốc độ WordPress từ server đến Core Web Vitals của mình để kết hợp thêm Redis Object Cache và FastCGI cache sau khi nâng cấp.
Nếu lỗi thì rollback như thế nào?
May mắn là vì bạn cài PHP 8.x song song ở Bước 3 nên rollback chỉ mất một phút: đổi dòng fastcgi_pass về socket PHP cũ, reload Nginx, xong. Sau đó bạn có thời gian kiểm tra từng plugin gây lỗi. Nguyên tắc: tắt hết plugin, bật lại từng cái một trên PHP mới cho tới khi tìm ra thủ phạm. Chi tiết hơn bạn xem bài hướng dẫn rollback khi nâng cấp lỗi mà mình đã viết.
Một vài lưu ý từ kinh nghiệm cá nhân
Mình từng giúp khá nhiều bạn dọn site bị hack chỉ vì chủ nhà web lười nâng PHP. Ba điều mình luôn nhắc: thứ nhất, đừng nhảy cóc qua nhiều version lớn một lần — đi từ 7.4 lên 8.1, chạy ổn rồi mới lên 8.3; thứ hai, nâng PHP là dịp hoàn hảo để rà soát danh sách plugin, cứ mỗi phiên bản PHP mới là mình lại loại được vài plugin chết; thứ ba, đặt lịch kiểm tra end-of-life của PHP, vì nhánh đang chạy hôm nay rồi cũng sẽ cũ ngày mai. Nâng cấp PHP định kỳ là việc bảo mật rẻ nhất mà hiệu quả nhất mà một admin WordPress có thể làm.
Kết luận
Nâng cấp PHP 8.x cho WordPress không khó nếu bạn làm theo đúng trình tự: backup, quét plugin, thử staging, chuyển FPM handler, rồi kiểm tra log. Toàn bộ quá trình trên một VPS nhỏ chỉ mất khoảng 30-60 phút, đổi lại là site nhanh hơn đáng kể và đóng cửa phần lớn vector tấn công phổ biến nhất hiện nay. Đừng đợi tới khi bị hack mới hành động, vì lúc đó chi phí dọn dẹp sẽ gấp trăm lần.
