Cái trang web này vậy mà ngày nào cũng có vấn đề xảy ra. Luôn luôn là như vậy. Khi bạn duy trì một trang web, đăng nhập vào làm việc với nó mỗi ngày, cảm giác giống như tui có một cây cảnh, con thú cưng vậy đó. Chiều ngày hôm qua tưới cây, tui không thấy có một con sâu nào. Sáng nay, vừa mới xịt phun sương được vài cái bỗng nhìn thấy cái gì đó như là một… con sâu, chó cưng bỗng có vài con ve.
Login vào Admin Dashboard (bảng điều khiển dành cho người quản trị) WordPress
Mới cách đây chưa lâu, khi tui login vào trình quản lý website này để xem lại bài ngày hôm qua viết dở dang, có chút thời gian rảnh nên muốn hoàn thành nó. Bỗng nhiên nhìn thấy thông báo:
Có phải ngày hôm nay mới hiện lên màn hình này? Không, tui chắc rằng nó đã thông báo từ trước đó rất lâu rồi. Thực lòng mà nói, lâu nay tui cũng ít chú ý bởi vì thấy rằng trang web mình đã nạp với một tốc độ không tệ tí nào nên thấy chưa cần phải chỉnh chọc.
Hôm nay, bỗng nhiên cái thông báo này gây… ngứa mắt làm sao, tui muốn dẹp nó đi, không hề muốn chậm trễ hơn.
Như trên cửa sổ có thể thấy có cái link tài liệu hướng dẫn để xem nó là cái gì, nó nói cái gì trong đó liệu tui có hiểu chút nào chăng?
Sau khi đọc một lát thì thấy rằng khi cài đặt PHP bị thiếu mất Extension, còn gọi với từ khác là phần mở rộng, mô-đun, trình cắm,… Nhưng thực sự, khi hiểu đúng, chúng dạng thư viện, mục đích hỗ trợ PHP thực hiện một số công năng nào đó mà bản thân PHP không, hoặc chưa được trang bị.
Thực hiện theo gợi ý của WordPress ngay và luôn
Sau khi đọc một hồi, tui hiểu rằng WordPress yêu cầu có 2 vấn đề được cải tiến, vấn đề thứ nhất liên quan đến cài đặt một mô-đun để xử lý hình ảnh sang xịn mịn hơn. Vấn đề thứ hai liên quan đến chức năng gửi email của WordPress, cụ thể ở đây là để email đáng tin cậy, bớt rơi vào thư mục rác.
Xử lý cải tiến thứ nhất: cài đặt, kích hoạt mô-đun imagick
Vì sao phải có mô-đun Imagick? Trước đây, và ngay cả hiện nay, GD là một thư viện xử lý ảnh mà các ứng dụng PHP thường sử dụng vì nó gọn nhẹ, phổ biến. WordPress cũng sử dụng GD. Nhưng những phiên bản WordPress gần đây thấy rằng tận dụng sức mạnh của ImageMagick cũng rất đáng giá về hiệu suất nên gợi ý người dùng cài thêm để sử dụng.
Mô-đun imagick cài cho PHP (tức một PHP Extension) này sẽ có nhiệm vụ gọi đến thư viện xử lý đồ hoạ nguồn mở rất nổi tiếng mang tên ImageMagick.
Với sự hiểu biết của tui từng vọc nhiều thứ, tui biết rằng có 2 việc phải làm: 1. Cài thư viện ImageMagick cho hệ điều hành, đây chính là công cụ để xử lý hình ảnh; 2. Cài mô-đun imagick cho PHP, đây chính là chiếc cầu nối để kết nối gửi lệnh xử lý hình ảnh đến ImageMagick.
Nếu thiếu một trong hai thứ vừa kể trên chắc chắn hệ thống không làm việc được đúng như mong đợi. Tui gom lại bằng các câu lệnh sau:
Lỗi chụp màn hình trên có lỗi, cần sửa php2nmod thành phpenmod.
Ổn rồi thì nhớ restart lại web server để web server và php-fpm nhận ra có sự thay đổi ở PHP. Kiểm tra với một file php có gọi hàm phpinfo() tui thấy như sau:
Cài đặt được rồi nhưng giờ WordPress có hoạt động với cái chức năng cải tiến này hay không cần phải có phép thử nghiệm. Không cần phải kích hoạt này nọ, tui đọc thấy nếu WordPress phát hiện ra có PHP imagick nó sẽ tự động ưu tiên thay vì GD. Nhưng Imagick có hoạt động hay không lại là chuyện khác, cần thực hiện việc kiểm tra.
Tui thực hiện như sau:
Một cửa sổ bung lên, nó là như sau:
Click ngay vào nút Sửa ảnh, hiện lên một cửa sổ chỉnh sửa khác:
Tui chỉ có thể thốt lên: ui, hổng ổn rồi. Nhưng vẫn cứ cố thêm một lần khi click vào nút Image Rotation, chọn một kiểu xoay trong menu xổ xuống xem có chuyện gì xảy ra? Nó hiện ngay lên:
Vậy là phải tìm lỗi do đâu. Cái này nếu tui chỉ mới vọc PHP, máy chủ Linux một thời gian ngắn e rằng tui “khóc tiếng Mán”, thiệt sự là như vậy. Trong trường hợp này, tui cũng có chút kinh nghiệm về quản trị server học mót từ hồi đi triển khai các dự án, nên hơi bối rối chút xíu… để nghĩ đến việc phải xem nhật ký lỗi trên hệ thống để tìm nguyên nhân.
Theo tra cứu người ta nói rằng có thể thông số memory_limit trong cấu hình php.ini hơi thấp nên chỉnh cao hơn. Tui vô chỉnh thông số này lên 128MB (hiện đang có 64MB) mà thôi. Giờ thì kết quả đã ổn rồi:
Như vậy, cải tiến thứ nhất đã được xử lý xong sau một hồi loay hoay.
Xử lý cải tiến thứ hai: chỉnh chọc DMARC:
Cái này nghe có vẻ gì đó rất gì đó nhưng tui đã xử lý gọn nhẹ, nhanh hơn tui có thể tưởng tượng bởi vì trước đây đã từng làm cho nhiều khách hàng nên nói là thuộc nằm lòng có vẻ hơi quá, nhưng không cần phri tra cứu cũng biết cách làm.
Tui lập tức vào trong dịch vụ email của tui là Zoho, kiểm tra xem đã bật app password trong đó hay chưa? Thông số của Easy SMTP của tui đã khớp hay chưa?
Gửi email test thử đến một email Gmail của tui xem thế nào. Chắc chắc đến 90% rơi vào mục Spam. Đó chính là lý do để mà chỉnh DMARC.
Việc này mất 30 giây mà thôi nhưng phải đợi ít nhất 5 phút mới có thể gửi email test lại để xem có vào Inbox hay chưa? Các bước làm như sau:
Login vào trình quản lý domain của tui tạo một record có kiểu là TXT với giá trị sau:
v=DMARC1; p=reject; rua=mailto:info@khoancatbetong.com; pct=100; adkim=s; aspf=sSau chừng 5 phút tui mở trang mxtoolbox.com lên để kiểm tra xem DMARC đã ổn hay chưa? Kết quả:
Vậy là xong rồi đó. Hai cải tiến đã được chỉnh theo gợi ý của WordPress
Đời không như mơ: sự kinh hoàng của plugin lạ xuất hiện
Sau khi xong xuôi, bỗng nhiên nhìn dải menu bên trái Admin Dashboard xuất hiện 2 plugin ở đâu lạ hoắc, tui nghi do Easy SMTP hoặc một plugin nào đó trên hệ thống có đoạn mã tải về kèm. Vì tui dám cá 100% rằng không có chuyện cài 2 thứ WPForms Lite và All in One SEO làm gì.
Chán thật, đã từ bỏ Windows bởi vì bloatware, giờ đây WordPress cũng lại dính phải cái nạn này. Hổng lẽ tương lai tui phải “Create Your Own CMS” chứ?
Đang cơn bực tức, tui mở wp-config.php ra thêm dòng này:
define( 'DISALLOW_FILE_EDIT', true );Cười ngoác cả mồm miệng ra khi kiểm tra lại Site Health Screen thì thấy như sau:
Trường hợp này được người ta gọi là “chữa trâu lành thành trâu què”. Tui hết biết làm gì luôn. Hẹn trở lại trong một bài chỉnh chọc khác./.