Giới thiệu plugin WP2Static: Detect & Crawl (phần 1)

WP2Static là plugin tạo website tĩnh (static site) dành cho WordPress.

Nó là mã nguồn mở hoàn toàn trong phạm vi công cộng (public domain).

WP2Static tăng cường quyền riêng tư của bạn và tối thiểu hóa chi phí hosting.

Các bước thực hiện

  1. Sao chép trang WordPress của bạn để chuyển nó sang vị trí khác (máy tính của bạn hoặc máy chủ gốc khác)
  2. Tải về và cài đặt plugin WP2Static
  3. Cấu hình các tùy chọn triển khai
  4. Cài đặt triển khai tự động hoặc thủ công (Jobs)
  5. Kiểm tra bản triển khai / thực hiện bất cứ điều chỉnh nào nếu cần
  6. Triển khai thành sản phẩm

Cách WP2Static hoạt động

Phát hiện URL

WP2Static truy vấn cơ sở dữ liệu WordPress và file hệ thống trên trang của bạn để xác định URL nào cần được đưa vào trang web tĩnh của bạn.

Crawling

Từng URL phát hiện được sẽ được crawled, và lưu một bản sao nội dung dưới dạng file tĩnh.

Xử lý hậu kỳ

Trong file đã crawled, tất cả URL từ máy chủ dành cho việc lưu trữ WordPress động sẽ được viết lại thành tên miền dạng triển khai của bạn (deployment domain).

Triển khai

Chuyển trang web tĩnh đã được xử lý hậu kỳ tới nền tảng hosting mà bạn đã chọn.

Jobs

Tất cả các bước detect (phát hiện), crawl, post-process (xử lý hậu kỳ) và deployment (triển khai) được chạy tự động với tần số cố định hoặc dựa trên việc chỉnh sửa bài/cũng như các yếu tố kích hoạt khác.

Add-ons

Mở rộng các tùy chọn triển khai & nâng cấp quá trình xử lý form, tìm kiếm, trang thương mại điện tử & nhiều cái khác bằng các add-ons (trình cắm bổ sung) của WP2Static.

Ở trên chỉ bàn ở mức độ tổng quan, giờ chúng ta sẽ đi sâu vào từng bước.

URL Detection / Phát hiện URL

Phát hiện URL là phần đầu tiên trong chuỗi công việc của WP2Static, quy trình công việc được minh họa như hình bên dưới:

phát hiện URL

Chúng ta cần phải phát hiện các URL để WP2Static biết được URL nào cần crawl và lưu lại dưới dạng file tĩnh để về sau dùng trong việc triển khai.

Việc phát hiện URL diễn ra như thế nào?

WP2Static phát hiện tất cả URL trên trang WordPress của bạn bằng cách gửi truy vấn đến cơ sở dữ liệu để tìm kiếm tất cả các kiểu URL:

  • bài đăng (post)
  • trang (page)
  • lưu trữ (archive)
  • thư mục (category)
  • và nhiều kiểu khác…

Nó cũng nhìn vào tất cả các file trong bản cài đặt WordPress để phát hiện bất kỳ URL nào khác mà chúng ta không thể xác định thông qua cơ sở dữ liệu, chẳng hạn như các file của giao diện, thư mục cache, robots.txt và một số cái khác…

Nhưng tôi không muốn nó bao gồm các file đa phương tiện đã cũ!

Hoàn toàn được, chúng ta có thể thực hiện điều chỉnh bằng lựa chọn lọc bỏ/bổ sung các URL vào chuỗi công việc cần crawl (danh sách URL đã được xác định). Thách thức ở đây là chúng tôi không biết người dùng muốn điều gì, vì thế theo mặc định, chúng tôi nhận biết TẤT CẢ URL mà chúng tôi có thể xác định từ trang của bạn, sau đó chúng tôi để bạn điều chỉnh danh sách URL này thông qua các tùy chọn plugin, lọc tùy chỉnh hoặc thông qua trình cắm (add-on).

Có rất nhiều URL được đưa vào mà tôi nghĩ là không cần thết

Thường thì tốt hơn khi bạn cứ để chúng ở đó. Nhờ cơ chế lưu trữ của WP2Static, sau khi Job ban đầu thực hiện việc detect, crawl, post-process và deploy, thì chỉ các file thay đổi từ lần triển khai trước đó là cần crawled, process và deploy lại lần nữa.

Xác minh URL nào đã được phát hiện

  • thông qua giao diện người dùng của WP2Static: Caches > Crawl Queue (Hàng đợi phục vụ cho việc Crawl) > Show URL
  • thông qua WP-CLI: wp wp2static crawl_queue list

Cách kích hoạt phát hiện URL

  • thông qua hàng đợi trong URL Detection Job
  • thông qua câu lệnh WP-CLI wp wp2static detect
  • gọi phương thức tĩnh URLDetector::detectURLs()

Cách chỉnh sửa hàng đợi Crawl (thêm/loại bỏ/chuyển đổi các URL)

  • thông qua giao diện người dùng của WP2Static: Options > Detection Options
  • thông qua bộ lọc wp2static_modify_initial_crawl_list
  • thông qua cơ sở dữ liệu, tên bảng {wp_prefix}_wp2static_urls

Cách xóa hàng đợi Crawl

Bạn thường không cần phải xóa thủ công hàng đợi Crawl, vì WP2Static sẽ xóa nó trước mỗi Job phát hiện mới. Nó cũng là một phần của toàn bộ công việc detect, crawl, post-process, deployment chiếm rất ít thới gian, thậm chí ngay cả trên trang rất lớn (chỉ cần có vài giây).

  • thông qua giao diện của WP2Static: Caches > Crawl Queue (Detected URLs) > Delete Crawl Queue
  • thông qua WP-CLI: wp wp2static crawl_queue delete

Ví dụ về hàng đợi Crawl (phát hiện URL)

Một mẫu nhỏ về cách URL có thể được phát hiện trong trang WordPress, với giả định là giao diện, bài đăng, trang, permalinks, vân vân có thể thay đổi giữa các trang. Hàng đợi Crawl được sắp xếp theo thự tự ABC, cũng như các danh sách khác về đường dẫn/URL trong website, để giúp nó dễ dàng trong việc so sánh/khắc phục sự cố mất file.

/
/category/uncategorized/
/category/uncategorized/page/1/
/favicon.ico
/hello-world/
/page/1/
/pages/page/1/
/robots.txt
/sample-page/
/sitemap.xml
/wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css
/wp-content/plugins/wp-search-with-algolia/css/algolia-instantsearch.css
/wp-content/plugins/wp-search-with-algolia/css/algolia-logo.svg
/wp-content/plugins/wp-search-with-algolia/includes/admin/css/algolia-admin.css
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.eot
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.svg
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.ttf
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.woff
...

Điều gì xảy ra với các URL đã được phát hiện?

Hàng đợi Crawl (URL đã được phát hiện) sẽ được sử dụng trong pha Crawling của nhiệm vụ (Job) WP2Static.

Đọc thêm:  Giới thiệu plugin perfmatters dùng để tăng tốc WordPress

Vài lời của người dịch: như tôi thấy phát hiện URL là bước quan trọng nhất, vì bất kể tài nguyên nào cần dùng nhưng lại không được phát hiện để tải về sẽ ảnh hưởng đến chất lượng của trang (về mặt hiển thị hoặc/và chức năng).

Tôi đã dùng thử phiên bản 7 của WP2Static (bản thương mại) và thấy nó gặp vấn đề về phát hiện URL, chẳng hạn nó gặp vài lỗi rất nghiêm trọng như:

  1. Không đưa URL thư mục vào phần detect
  2. Không đưa URL của các tag vào phần detect
  3. Không đựa URL của thông tin tác giả vào phần detect
  4. Không detect được một số CSS và JS quan trọng

Trong đó ba cái đầu tôi nghĩ do tác giả chủ động (áp hạn chế lên các bản miễn phí) hoặc do lỗi ở phần nào đấy mà tác giả quên chưa sửa, vì đây đều là các lỗi cực kỳ nghiêm trọng, vì dù nó detect post, page và tài nguyên đa phương tiện tốt đến đâu nhưng lại bỏ quên thư mục, tag thì sẽ chẳng ai muốn dùng. Tôi sẽ đợi các phiên bản cập nhật tiếp theo để kiểm tra vấn đề này.

Với cái thứ tư, có thể là hạn chế thực sự khi WP2Static không thể nhận biết được tất cả CSS và JS, điều này có thể khắc phục được tương đối dễ dàng bằng plugin kiểu như Autoptimize, nó sẽ gom tất cả CSS và JS về và cache trong thư mục tương ứng. Bạn chỉ cần vào thư mục này trên trang động, tải nó về và up ngược lên host của trang tĩnh, đảm bảo bạn sẽ không bị thiếu bất kỳ đoạn mã CSS và JS nào.

Crawling

Pha Crawling trong WP2Static yêu cầu tùng URL đã được phát hiện và lưu nó lại trong định dạng trang tĩnh thân thiện.

crawling trang

Khi bạn ghé thăm một trang web làm từ WordPress, nội dung sẽ được lắp ráp từ các mã PHP, các mục nhập cơ sở dữ liệu và bất kỳ giao diện và plugin nào được áp dụng. WP2Static lưu trữ một bản sao chép của trang như người dùng nhìn nó – sau khi tất cả quá trình lắp ráp hoàn thành xong nhiệm vụ.

Cách crawling của WP2Static làm việc

Với từng URL được nhận biết trong hàng đợi Crawl, WP2Static sẽ:

  • gửi yêu cầu tới URL và lưu trữ các nội dung thành một file
  • thêm các URL được lưu thành công vào Crawl Cache

Trang HTML thân thiện với website tĩnh

Trong website WordPress động, truy cập vào đường dẫn có dạng như https://example.com/posts/my-sample-post/ dựa trên máy chủ của bạn và WordPress để định tuyến URL này nhằm hiển thị nội dung bài đăng thích hợp. Không có thư mục /post/ thực sự tồn tại bên trong bản cài đặt WordPress động của bạn.

Đọc thêm:  Tối ưu Google PageSpeed Insights để tăng tốc độ website

Với website tĩnh, chúng ta không có PHP và cơ sở dữ liệu để định tuyến được cấu trúc URL kỳ diệu như vậy. Thay vào đó, chúng ta cần tạo các thư mục thực để hỗ trợ đường dẫn đầy đủ mà người dùng yêu cầu, ví dụ: /posts/my-sample-post/. Hầu hết các dịch vụ hosting tĩnh hoạt động bằng cách định tuyến các yêu cầu đến các thư mục có tài liệu mặc định bên trong thư mục đó, thường là index.html. Nếu không làm như vậy, URL trong trang tĩnh cần trông giống như thế này: https://example.com/posts/my-sample-post/index.html – đây là đường dẫn không tối ưu.

Khi WP2Static crawl một URL kiểu như https://example.com/posts/my-sample-post/, nó sau đó sẽ tạo các thư mục và file bên trong thư mục Generated Static Site: /wp-content/uploads/wp2static-crawled-site/posts/my-sample-post/index.html

Với các tài nguyên tĩnh, chẳng hạn như ảnh, CSS, JavaScript, fonts, vân vân, nó sẽ tạo các thư mục cần thiết, tương tự như trang HTML, nhưng sau đó chỉ cần lưu tài nguyên tĩnh, mà không cần thực hiện thêm các bước kế tiếp.

Crawl Caching

Bất cứ lúc nào chúng ta thực hiện thay đổi trên trang WordPress, WP2Static cần phát hiện, crawl, xử lý hậu kỳ và triển khai từng URL một lần nữa, đây là quá trình rất chậm chạp (hãy hỏi bất kỳ ai từng sử dụng phiên bản 6 hoặc các phiên bản trước đó là bạn sẽ biết ngay thôi mà!).

Để khắc phục điều này, khi chúng tôi crawl thành công một URL, chúng tôi thêm nó vào CrawlCache của WP2Static. Trong các lần crawls kế tiếp, chúng tôi bỏ qua bất cứ URL nào đã có trong CrawlCache.

Caching quả là khó khăn!

Chỉ có hai thứ khó khăn trong ngành khoa học máy tính: vô hiệu hóa cache, đặt tên các thứ, và các lỗi kiểu off-by-one

Vấn đề caching website sẽ có một trang riêng trong tài liệu hướng dẫn của chúng tôi, vì có rất nhiều lớp cache nằm giữa người dùng của bạn và website của bạn. Bây giờ, tôi sẽ chỉ giải thích các quyết định được thực hiện cho Crawl Cache:

  • mọi URL đã được crawl thành công sẽ được thêm vào CrawlCache
  • các URL trong CrawlCache sẽ không được crawl thêm lần nào nữa cho đến khi được loại bỏ (vô hiệu hóa) khỏi CrawlCache
  • chỉnh sửa/xóa một post hoặc page sẽ vô hiệu hóa URL đó trong CrawlCache
  • nhiều hoạt động khác (đổi giao diện, thiết lập trang chủ khác, vân vân) sẽ phải vô hiệu hóa nhiều URL hơn (hiện vẫn chưa được triển khai trong plugin)
  • CrawlCache có thể được xóa bỏ hoàn toàn thông qua giao diện người dùng của WP2Static, WP-CLI hoặc một hàm tùy chỉnh

Tôi đã tích cực cache tất cả các URL đã được crawl thành công và tinh chỉnh dần dần các cơ chế vô hiệu hóa cache (cache-invalidation mechanisms). Ở thời điểm này, khi bạn chỉnh sửa/xóa một bài post/page, CrawlCache sẽ vô hiệu hóa URL đó, cho phép nó có crawl tươi mới trong Job kế tiếp.

Vì thế, bạn có thể thấy việc thay đổi menu, chuyển đổi giao diện hoặc các cập nhật nội dung khác cho WordPress không được phản ánh chính xác trong lần xuất website tĩnh tiếp theo của bạn. Để giảm bớt điều này, bạn có thể xóa thủ công CrawlCache giữa các Job trong giao diện người dùng của WP2Static hoặc nếu sử dụng WP-CLI, thêm lệnh wp wp2static crawl_cache delete trước lệnh wp wp2static crawl

Trước khi phiên bản 7 chính thức phát hành, tôi có khả năng chọn một trong hai tùy chọn sau:

  • thêm một checkbox vào giao diện người dùng (UI) để vô hiệu hóa CrawlCaching
  • cải thiện logic của việc vô hiệu hóa CrawCache để nó mạnh mẽ hơn

Các tùy chọn crawling

Thông tin xác thực HTTP cơ bản

Trong lõi của plugin WP2Static, chỉ có duy nhất một tùy chọn Crawling bạn có thể thiết lập nếu bạn sử dụng xác thực HTTP căn bản (basic authentication) trên trang development của bạn (tôi rất khuyến khích bạn làm điều này), bạn có thể nhập vào tên người dùng và mật khẩu trên WP2Static > Options UI screen (hoặc sử dụng WP-CLI).

Đọc thêm:  Giải thích các tùy chọn của plugin perfmatters (phần 7)

HTTP basic auth không cần thiết để sử dụng WP2Static, vì thế bạn có thể bỏ 2 trường này trống nếu không muốn sử dụng HTTP basic auth. Khi lưu, như với thông tin nhạy cảm khác của WP2Static, chúng tôi sẽ mã hóa mật khẩu basic auth khi lưu nó vào cơ sở dữ liệu.

tùy chọn về Basic Auth

HTTP basic authentication bổ sung một lớp đăng nhập/mật khẩu vào trang WordPress động dành cho mục đích phát triển của bạn (trang tĩnh được xuất sang tên miền chính thức). Bởi vì chỉ bạn và nhóm của bạn mới cần truy cập website này, sẽ rất hợp lý khi bạn khóa nó bằng một lớp bảo mật bổ sung, ngăn trang không cho những ai có ý đồ xấu nhòm ngó và các bot của máy tìm kiếm truy cập (và gây ra hiện tượng trùng lắp nội dung). Chỉ website tĩnh là cần khả năng truy cập công khai mà thôi. Đây là cách quan trọng mà WP2Static có thể cung cấp để bảo mật hơn nữa trang WordPress động của bạn.

Xác minh URL nào đã được crawl và đưa vào bộ nhớ cache

  • thông qua giao diện người dùng của WP2Static: Caches > Crawl Cache > Show URLs
  • thông qua WP-CLI: wp wp2static crawl_cache list

Xác minh URL nào đã được lưu

  • thông qua giao diện người dùng của WP2Static: Caches > Generated Static Site > Show Paths
  • thông qua WP-CLI: wp wp2static static_site list
  • thông qua thư mục: /wp-content/uploads/wp2static-crawled-site/

Cách kích hoạt trình phát hiện URL

  • thông qua hàng đợi Crawl Site Job
  • thông qua câu lệnh WP-CLI wp wp2static crawl
  • gọi lớp Crawler:
<?php
$crawler = new \WP2Static\Crawler();
$crawler->crawlSite( \WP2Static\StaticSite::getPath() );

Cách xóa hàng đợi Crawl

Bạn thường không cần xóa thủ công hàng đợi Crawl, vì WP2Static sẽ xóa nó trước đó, mỗi khi nó thực hiện Job phát hiện mới. Nó cũng là một phần trong toàn bộ Job là detect, crawl, post-process, deployment tốn rất ít thời gian, thậm chí trên các website rất lớn (chỉ mất có vài giây).

  • thông qua giao diện người dùng của WP2Static: Caches > Crawl Cache > Delete Crawl Cache
  • thông qua WP-CLI: wp wp2static crawl_cache delete

Cách xóa tệp lưu từ quá trình crawl

  • thông qua giao diện người dùng WP2Static: Caches > Generated Static Site > Delete Files
  • thông qua WP-CLI: wp wp2static static_site delete

Ví dụ về Crawl Cache

CrawlCache sẽ trông giống hệt hàng đợi Crawl (các URL đã được phát hiện) sau khi quá trình crawl đầy đủ hoàn tất, ví dụ đây là một mẫu:

/
/category/uncategorized/
/category/uncategorized/page/1/
/favicon.ico
/hello-world/
/page/1/
/pages/page/1/
/robots.txt
/sample-page/
/sitemap.xml
/wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css
/wp-content/plugins/wp-search-with-algolia/css/algolia-instantsearch.css
/wp-content/plugins/wp-search-with-algolia/css/algolia-logo.svg
/wp-content/plugins/wp-search-with-algolia/includes/admin/css/algolia-admin.css
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.eot
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.svg
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.ttf
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.woff
...

Ví dụ về tạo website tĩnh/các trang tĩnh đã crawl

Cái này sẽ trông giống với CrawlCache của bạn, lưu ý đến index.html sẽ được đính kèm vào các URL có nội dung là HTML:

/category/uncategorized/index.html
/category/uncategorized/page/1/index.html
/hello-world/index.html
/index.html
/page/1/index.html
/sample-page/index.html
/wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css
/wp-content/plugins/wp-search-with-algolia/css/algolia-instantsearch.css
/wp-content/plugins/wp-search-with-algolia/includes/admin/css/algolia-admin.css
/wp-content/plugins/wp-search-with-algolia/includes/admin/fonts/algolia.woff

Điều gì xảy ra với URL đã được crawl

Trong quy trình làm việc thông thường, các file đã crawl được lưu vào trong thư mục /wp-content/uploads/wp2static-crawled-site/. Thư mục này sau đó sẽ phải đi vào pha xử lý hậu kỳ (post-processing) trong Job của WP2Static trước khi được triển khai.

Các câu hỏi thường gặp về crawling

Tôi có một số file CSS hoặc XML phục vụ từ các đường dẫn /my-css/ hoặc /feed/, chúng sẽ vẫn hoạt động bình thường chứ?

Vì URL /feed/ phổ biến trong WordPress, tôi đã cố gắng hỗ trợ nhằm duy trì các URL này. Với các nhà cung cấp dịch vụ hosting tĩnh có tính năng về các hàm hoặc chuyển hướng kiểu serverless, điều này là có thể làm được với một chút điều chỉnh.

Trong trường hợp các file CSS, ảnh hoặc kiểu file khác được phục vụ mà không có đuôi file mở rộng (extension) trong WordPress, nó ít phổ biến và có nhiều ngoại lệ, vì thế tôi khuyên bạn nên tránh các theme/plugin tạo ra các URL kiểu như vậy. Tôi có thể xem xét hỗ trợ các trường hợp như vậy, nhưng nó sẽ nằm sâu bên dưới trong danh sách ưu tiên. Bạn có thể giải quyết trường hợp này bằng plugin kiểu như Autoptimize, nó có thể giúp các URL tài nguyên tĩnh rắc rối thân thiện hơn trong việc xuất website tĩnh.

(Dịch từ tài liệu hướng dẫn trên trang chính thức cho plugin: WP2Static[.]com)

Leave a Comment