這陣子為了公司網站的更新，稍微接觸了一下 WordPress 的快取機制。
原本想要達成的目的是：「網站使用者只會在該工作階段 (session) 中第一次載入時，才會顯示預載動畫 (preload animation)。」
然而，正當準備透過 session_start() 的方式來解決這個問題時，碰巧讀到了社群夥伴王大的〈為什麼你不該在 WordPress 中使用 PHP 工作階段〉，裡面提到 session_start() 會造成潛在的安全性問題，而且 WordPress 原本的設計上，並不使用 $_SESSION 來記錄使用者狀態。
解決方案 transient
既然不應該用 session 來作為解決方案，那麼就必須要尋求替代方案了。從王大附註的參考資料中，提到了 transient 這個關鍵字，於是便循線找到社群夥伴阿竣的文章。
所謂的 WordPress Transients API，是將工作階段的資料暫存在資料庫中，用來快取查詢的一個機制。其基本語法如下：
<?php get_transient( 'transient_名稱' ); set_transient( 'transient_名稱', $SQL查詢結果, 失效時間 );
於是異想天開的寫下了類似的程式碼：
<?php
if ( false === get_transient( 'preload_is_played' ) ) {
// 這裡開始執行動畫
set_transient( 'preload_is_played', true, 120 );
// 因為在測試環境，所以先定義 120 秒的失效時間
}測試的當下好像煞有其事，但其實中間有一個邏輯問題，導致我們並不能透過 transient 的快取機制來處理「判斷是否啟用預載動畫」。
如果我們透過 transient 來當作解法，這樣會導致以下的邏輯錯誤：
使用者 A 進入網站後，系統定義了一個 transient，此時使用者 B 進入網站時，因為 transient 仍然存在於資料庫中，因此預載動畫便失效了。
結語
透過 transient 的機制，來快取資料庫查詢，對於頁面中可能同時存在數個查詢的情況，或是需要串接外部 API 時 (譬如 Google Map API) 應該會有幫助。但是用在偵測個別使用者的行為時，便沒有辦法達到想要的結果。
如果要根據使用者來判斷播放預載動畫的行為，應該還是要用 Cookies 的機制來處理。明天再來繼續研究 Cookies。
