WordPress「目前正在執行另一項更新程序」的判斷與解決方法

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

WordPress 顯示「目前正在執行另一項更新程序」（英文訊息為 Another update is currently in progress.）時，先確認是否有人或主機服務正在更新網站，別立刻刪除 core_updater.lock。這筆紀錄是避免兩個核心更新同時執行的保護；它可能是正常更新留下的有效鎖，也可能是中斷後未清除的舊鎖。

處理順序是：暫停重複點擊更新、確認原程序狀態、準備可還原的備份，再決定是否需要清理。清除鎖定只代表可以重新嘗試，不代表造成更新失敗的原因已修好。本文以 WordPress 官方程式碼與 WP-CLI 文件說明這條排查路線。

先確認更新還在跑，還是真的中斷

先查看是否還開著另一個後台更新頁面、同事是否正在維護，以及主機控制台是否有自動更新或維護工作。不要在不同分頁、SSH 和主機面板同時發動更新；瀏覽器頁面逾時或關閉，也不足以證明伺服器上的工作已停止。

如果主機面板顯示更新仍在進行，先等它完成並查看工作紀錄。若面板沒有狀態資訊、你也看不懂伺服器程序，交給主機支援確認，比直接解除保護更合適。可以提供這段描述：

網站在核心更新頁顯示「目前正在執行另一項更新程序」。請協助確認是否仍有 WordPress 核心更新或主機自動維護工作正在執行，並查看相同時間的 PHP／更新紀錄；在確認工作已停止前，請先不要清除更新鎖。

若已確認上一輪更新結束，先重新開啟更新頁確認目前版本與訊息。只有確定沒有其他更新正在執行，才進入後面的唯讀檢查與清理步驟。不熟悉 SSH 的讀者可以把這些檢查交給主機支援，不必為了刪一筆設定去安裝檔案管理外掛。

core_updater.lock 的 15 分鐘代表什麼？

WordPress 核心更新程式會呼叫 WP_Upgrader::create_lock( 'core_updater', 15 * MINUTE_IN_SECONDS )，把核心更新鎖的有效期限設為 15 分鐘。選項名稱是 core_updater.lock，值是建立鎖定時的 Unix 時間戳記。

create_lock() 的程式碼先嘗試建立鎖；若既有鎖仍有效，就拒絕另一個更新。若既有鎖已過期，則清除舊鎖，再嘗試取得新的鎖。因此，資料庫還看得到一筆舊紀錄，不等於每次更新都會被它擋住。

這個過期判斷在取鎖時執行，不能把「網站流量低，WP-Cron 沒被觸發」當成核心更新鎖一直無法解除的充分解釋。也不要把 15 分鐘當成強制刪鎖的倒數計時：時間到了，只能說明鎖定的時效條件，不能證明原本的 PHP 程序或主機工作已經停止。

這裡談的是核心更新的 core_updater.lock。其他更新或自動維護機制可能使用不同的鎖與條件，不應搜尋到名稱含有 updater 就全部刪除。

有 WP-CLI 時，先讀取鎖定，確認目標網站

以下指令需要主機已安裝 WP-CLI，並以具有該站管理權限的帳號操作。請把 /path/to/wordpress 換成實際 WordPress 安裝路徑。若同一台主機放了多個網站，先核對 home，避免操作到另一站。

wp --path=/path/to/wordpress option get home
wp --path=/path/to/wordpress option get core_updater.lock

wp option get 只讀取指定選項。查到鎖定時，輸出通常是時間戳記；它不是進度百分比，也無法告訴你哪個程序仍在工作。請搭配主機工作紀錄、伺服器時間與錯誤發生時間判斷。

若指令顯示找不到該選項，先確認執行路徑與站點正確；不要接著刪除其他鎖。若是載入 WordPress、連線資料庫或權限錯誤，則先處理該錯誤，不能把指令失敗解讀成鎖定不存在。

對多站台或主機代管的更新流程，請由管理該環境的人確認操作範圍。一般教學中的一條路徑，不足以代表所有站點與共享核心的狀態。

確認程序停止後，才考慮一次性清理

執行前應已確認三件事：目標網站正確、沒有其他更新工作正在執行，以及手上有包含檔案與資料庫的可用備份。若任何一項還不確定，先停在唯讀檢查，不要試著靠刪鎖觀察會發生什麼事。

確認是需要處理的殘留鎖後，可用 WP-CLI 的選項刪除指令一次性移除：

wp --path=/path/to/wordpress option delete core_updater.lock

成功訊息只代表指定選項已刪除。接著由同一個管理者、使用同一個更新入口重新嘗試一次，記錄完整結果。不要同時在後台與命令列重試，也不要把這條刪除指令加入排程。

WP-CLI 透過 WordPress 選項機制操作，不必在指令中猜資料表是不是叫 wp_options。不建議把直接執行 DELETE 的程式碼貼到 functions.php：若忘記移除，每次載入佈景主題都可能再次刪鎖，連後續正常更新的保護也一起撤掉；直接 SQL 也繞過了選項 API 的相關處理。

沒有 WP-CLI 時，請讓主機支援依實際資料庫、資料表前綴和快取配置處理同一筆選項。不要把「找到任意 options 表」或「安裝一個修復外掛」當成已確認操作範圍。

前台卡在維護畫面，與更新鎖是兩回事

.maintenance 是 WordPress 根目錄的維護模式檔案；core_updater.lock 則是資料庫裡的核心更新鎖。刪除其中一個不會自動處理另一個，也不能證明核心檔案已完整更新。

WordPress 的維護模式檢查會讀取檔案中的 $upgrading 時間戳記；標準流程在該時間超過 10 分鐘後會視為維護結束。這是內建檢查的行為，主機、外掛或快取提供的維護頁可能另有來源。

若已確認沒有更新工作、前台仍顯示維護畫面，請由管理者確認是不是殘留的 .maintenance，再移除該檔案並重新檢查網站。不要在核心檔案仍被替換時移除維護保護，也不要順手清空 wp-content/upgrade/ 或其他備份目錄；資料夾存在本身不是可刪除的依據。

解除提示後，怎麼確認真的恢復？

驗收目標不是「鎖定消失」，而是更新完成且網站仍能正常使用。更新後核對後台顯示的版本、更新結果及前台主要頁面；有登入、表單、購物或其他重要功能的網站，也要檢查那些實際流程。不要只因為首頁打得開就判定全部成功。

如果更新再次失敗，先保存新的錯誤訊息與時間。下載失敗、解壓失敗、檔案不可寫入、PHP 記憶體或執行時間錯誤，各自需要不同處理。請依紀錄查原因，而不是反覆刪鎖，或直接把 PHP 記憶體與時間限制提高到一組固定數字。

若出現 500 錯誤、504 逾時，或資料庫連線錯誤，可按實際症狀繼續排查。鎖定訊息本身不足以證明主機太便宜、外掛衝突，或需要換主機。

更新後若網站功能異常，先停止追加變更，由管理者評估使用更新前的檔案與資料庫備份還原。把刪掉的鎖定值加回去不會還原核心檔案，也不會修復資料庫。可先在WordPress 測試環境演練更新與還原，確定備份真的用得上。

下次更新前，指定一個負責入口，確認主機自動維護的時段，並準備可還原的備份。遇到鎖定時，先問「上一個更新還在做事嗎」，就不容易把保護機制當成故障直接拆掉。