完整地替換圖片
LiteSpeed圖片最佳化處理的queue看的應該是檔案日期 (也就是Uploaded on)
如果是即刻上傳的檔案，它就會安排進queue
但是針對已經上傳過的檔案，它是無法獨立幫你force to update的
這樣的機制在什麼情境下可能遇到問題呢？
如果你找個一個replace image的外掛更換了圖片，它的webp有可能永遠都是舊的版本
所以replace image的外掛最好選可以順便更新檔案時間的
Enable Media Replace正好有這個選項
(我覺得直接從FTP拉上去應該沒辦法，這個日期恐怕是DB裡的時間；排程不知道行不行，但換圖片更新資訊應該是當務之急而不是走排程…所以沒試過)
以下是試過可以pass的操作，或許有些流程可簡化或有代替方案
- 刪除後台原檔案的group (含thumbnail、webp、cache plugin過去產生的備份等等)，只留下原檔案.png
- 使用Enable Media Replace外掛換圖並同時更新時間(這個步驟也會生成thumbnails)
- 等LiteSpeed去拉新的image group送optimizataion
- 確認新的.webp有生成並更新，完成
Enable Media Replace更換檔案的設定如下：
更換方式的欄位我有試過第二種，但是遇過(非必現)新上傳的同名檔案檔名最後變成UUID (ex. b102567e-95b1-44b0-99f8-54c756394205 像這種格式)
所以還是維持第一種了
完整地刪除圖片
如果使用後台原生的永久刪除來整理圖片，是不會刪掉webp和LiteSpeed產生的備份檔的
可以對目標檔案進行restore to backup後再刪除
不過這會牽扯到你之前是否有其他產生redundent image的歷史
(譬如過去曾經重新產生縮圖，舊的縮圖可能已經刪除了，但*.webp還活著)
所以最好到後台確認該檔案是不是還有殘留免得不用的圖片越積越多
每次更換/刪除/重新生成圖片等操作都檢查一下，有心得後filesystem就會是乾淨的，黑歷史清乾淨後也不用頻繁檢查了(希望)(…)
不要同時使用多個optimization tool
如果已經用LiteSpeed外掛處理image optimization，就盡量不要再用其他類似plugin (如EWWW)的同功能了，反之亦然
每家的處理/備份方式不一，很容易造成conflict，到時候filesystem變得又髒又亂又要回頭整理
而且同質的功能本來就比較建議只用一個外掛
如果打定主意用A家了就盡量一直使用它的服務吧，就算要換最好也打掉重練
