WPTOOLBEAR網站工具熊WordPress PHP 升級：相容性檢查、測試與回復指南
PHP 版本過舊時，網站表面上可能還能正常開啟，卻已失去官方安全修補。真正的風險通常在某次外掛更新、流量高峰或結帳流程執行時才浮現。
安全的 WordPress PHP 升級 不該是主機控制台裡的一次點擊，而是一套可測試、可驗證、可回復的變更流程。先記錄環境、建立可還原備份，再於 staging 驗證，才能把正式站中斷的機率降到較低。
重點整理
- 已停止支援的 PHP 版本不再提供安全更新，仍在使用的網站應盡快排定升級作業。
- 核心更新、外掛、佈景主題與主機條件必須一起評估，也不能只依賴自動更新。
- 升級前應保留完整檔案與資料庫備份，並記錄原始設定、外掛清單與主機環境。
- 相容性掃描只能找出可疑程式碼，仍需在 staging 執行實際操作測試。
- 發生錯誤時，先透過主機控制台切回原設定，再視情況還原檔案與資料庫。
為什麼不能長期停留在舊版 PHP
PHP 不只是 WordPress 的附屬元件，它直接負責執行核心、外掛、佈景主題與自訂功能。伺服器上的 PHP 版本一旦停止支援，即使 WordPress 核心更新與自動更新正常運作，也不代表仍有官方安全更新可用。
PHP 7.4 的安全缺口會持續累積
PHP 7.4 的官方安全支援已於 2022 年 11 月結束。你可在 PHP 官方支援版本表 核對各版本目前的生命週期。持續使用停止維護的版本，會增加網站安全風險，也可能讓停機損失更加難以控制。
風險不只限於後台帳號被入侵。惡意程式碼可能竄改廣告、建立隱藏帳戶、寄送垃圾信，或讓購物車、表單與交易流程失效。
新版 PHP 有助於效能，但別承諾固定百分比
受支援版本能持續取得漏洞修復與安全更新，降低已知問題長期累積的風險。新版 PHP 通常也有助於效能提升，但實際效果仍取決於主機資源、快取、資料庫查詢與程式碼品質。
因此，別相信「升級一定快 50%」這類說法。若網站回傳 5xx 錯誤、商品頁打不開或重要內容無法抓取，可能間接影響 SEO 排名與轉換率。對外掛繁多、查詢複雜的 WooCommerce 網站來說，先排除慢查詢與不相容外掛，往往比單純切換 PHP 更有意義。
WordPress PHP 升級前，先完成版本盤點
先確認網站主機目前實際執行的 PHP 版本，再決定升級目標。不同主機的 cPanel、Plesk、客製控制台或代管平台，介面與功能都不同，不要照著其他網站的截圖操作。
從後台與主機控制台交叉確認版本
WordPress 後台可開啟「工具 > 網站健康 > 資訊 > 伺服器」，查看目前版本、記憶體限制與資料庫資訊。接著登入主機控制台，確認該網域或 PHP Handler 的實際設定。
兩處的 PHP 版本若不一致，先詢問主機商。多站主機帳號可能讓不同網域使用不同 PHP 版本，CLI、Cron 與網站前台也可能連到不同伺服器或執行環境。不要為了查版本，直接把 phpinfo() 公開在網站根目錄。
記下升級前的完整環境
建立一份簡單紀錄，至少保留 WordPress 核心版本、核心更新狀態、啟用中的外掛與佈景主題版本，以及自動更新設定。這些紀錄有助於掌握停止支援與安全更新風險，避免只看控制台畫面決定升級目標。
另外，也要記下快取設定、CDN、排程機制、客製程式碼位置與資料庫資訊。若站內有串接金流、物流、CRM 或 API，也要列入網站維護紀錄。
WordPress 官方需求頁 的建議可能隨時間調整，升級前應以頁面當下內容為準。實務上仍要先確認 WordPress 核心、主題與外掛組合，再選擇已完成測試的 PHP 版本。
相容性檢查要看四個層面
PHP 版本升級失敗，通常不是 WordPress 核心本身造成，而是外掛、佈景主題或自訂功能不符合新語法與型別規則。
核心、外掛與佈景主題要一起評估
先確認 WordPress 核心、正式使用的外掛與佈景主題，仍由開發者提供支援。不要只做核心更新，也要檢查套件版本、相依性與官方相容性說明。
停用但未刪除的外掛和舊檔案也要盤點。它們可能錯過漏洞修復，甚至留下惡意程式碼，因為部分主機仍會掃描整個網站目錄。
WordPress 對各 PHP 版本的支援狀態會隨核心版本調整，可參考 WordPress 的 PHP 相容性資料。即使核心列為相容，也不代表每款商業外掛和佈景主題都能安全執行。已停止支援的套件，應優先尋找替代方案。
看懂掃描報告，不要只看紅黃綠燈
PHP Compatibility Checker 等工具可協助找出舊函式、已淘汰語法或可能出錯的檔案。掃描出現警告時，先查看檔案路徑、外掛名稱、最後更新日期與錯誤類型。
報告若涉及已移除函式、相依性、型別錯誤或自訂程式碼，應列為優先處理項目。標示 Fatal error 的項目，通常代表可能發生致命錯誤。若報告指向自行修改過的 functions.php、mu-plugin 或客製外掛檔案，請交由熟悉程式設計的人員修正。
可搭配這份 PHP 版本升級相容性檢查 重新檢視核心、外掛與環境條件。掃描工具只能縮小範圍，不能保證網站完全相容。啟用自動更新前，仍應先在測試環境驗證實際功能。
先建立 staging，再建立可還原備份
直接在正式環境切換 PHP 版本，等於讓真實訪客替你測試。企業網站、電商、會員站與有預約表單的網站，尤其不該採用這種做法。
staging 要盡量接近正式環境
許多主機代管服務提供一鍵 staging，有些則需要透過 WP STAGING、Local 或手動複製方式建立。建立測試環境時，應複製正式站檔案與資料庫，並以 noindex、密碼保護或網路限制隔離，避免測試內容被搜尋引擎收錄。
測試環境也應接近正式設定，包括核心更新狀態、主要外掛、佈景主題、快取條件與擴充套件。測試期間可暫停自動更新，或固定版本，避免複製站自行變更。正式站有 WooCommerce、會員登入或 API 回傳資料時，最好改用測試金流與測試帳號，避免誤寄通知或建立真實訂單。
備份必須同時包含檔案與資料庫
升級前先執行一次臨時完整網站備份，內容至少包括 WordPress 檔案、媒體庫、必要設定檔與資料庫備份。備份至少保留一份於站外位置，不要只依賴同一台主機的單一快照。
備份檔存在，不等於它能成功還原。請先確認誰有還原權限、備份存放在哪裡，以及還原後如何驗證網站功能。
可依照 網站升級前的備份與相容性檢查 逐項盤點。高流量網站建議另做一次還原演練，確認檔案、資料庫與上傳圖片能一起回到可用狀態。
WordPress PHP 升級的標準執行順序
先安排在流量較低的時段進行網站維護，並告知客服、行銷與電商人員。升級期間應暫停不必要的自動更新，也不要同時改版、換主題、批次更新外掛或調整 DNS，避免多項變更同時發生，增加問題判斷難度。
先在測試站升級並完成驗收
建議依序完成正式執行前、測試驗證、版本切換與升級後監控：
- 先在測試環境完成 WordPress 核心更新、外掛與佈景主題更新，處理已知相容性問題。
- 再將測試站切換到預定的 PHP 版本，例如 PHP 8.3。
- 清除快取後，測試前台頁面、後台登入、表單、搜尋、會員、結帳與寄信功能。
- 查看 PHP
error_log、WordPress 除錯紀錄與主機錯誤紀錄。 - 正式切換前，確認核心、外掛與主機層級的自動更新排程，避免它們在維護時段自行執行。
- 確認測試結果無誤後，透過主機控制台完成正式切換，並在短時間內持續監控網站。
若主機允許選擇 PHP Extensions，也要保留原有擴充套件設定。intl、mbstring、curl、imagick 或 zip 缺失時，伺服器可能只讓付款、圖片處理或寄信功能局部失效，不一定會出現白畫面。
與主機商溝通時，提出具體需求
PHP 版本切換應以主機控制台或主機代管服務提供的操作為準，不要假設 cPanel、Plesk 或客製化介面的流程相同。向主機商詢問時，可清楚說明：「請確認此網域目前的 PHP 版本、可切換版本、切換後是否保留原設定、是否可建立 staging，以及快照可否連同資料庫還原。」
同時詢問 PHP 切換是否會影響 WP-CLI、Cron Job、排程備份與自訂 PHP 路徑，並確認這些項目是否使用同一個 PHP 執行版本。不要直接複製別人提供的 Cron 指令，因為帳號、目錄、PHP 執行檔與權限都可能不同。
升級後要測試哪些實際功能
正式環境驗收前，先確認目前的 PHP 版本，以及 WordPress 核心更新是否完成。網站首頁能開啟，不代表升級完成。許多相容性問題會藏在訪客不常走到的流程，例如寄信、匯入、排程工作或後台儲存設定。
以訪客路徑檢查前台功能
至少依訪客路徑開啟首頁、主要服務頁、文章頁、商品頁、搜尋、會員、聯絡表單與登入頁，並測試寄信流程。電商網站要用測試帳號完成加入購物車、優惠碼、付款、訂單與庫存更新。
多語系網站則要抽查語言切換、各版本頁面與 SEO 外掛輸出，避免錯誤回應影響 SEO 排名。測試環境轉正式站前，別忘了移除整站 noindex、密碼保護與測試網址，並確認正式站的 Sitemap 沒有混入測試環境網域。
看紀錄，也要驗證背景工作
檢查主機 error_log、wp-content/debug.log 與外掛自身日誌，也確認 WordPress 核心、外掛或佈景主題的自動更新沒有被意外停用。伺服器、WP-CLI 與排程可能使用不同版本的 PHP 環境，請分別核對網域、路徑、錯誤紀錄與執行結果。
建立一篇 10 到 15 分鐘後發布的測試文章，並觀察是否準時發布。再次確認自動更新、系統 Cron、WooCommerce 同步與備份排程確實執行並留下紀錄，通知信寄出也不能證明備份檔可用。
PHP 升級失敗時的回復流程
回復目標是先恢復可用服務，再找出根本原因。切回舊版 PHP 不保證能解決問題，也可能無法修正升級期間造成的資料或檔案問題。
何時可以先切回舊版 PHP
如果剛切換 PHP 後立刻出現白畫面、前台 500 錯誤或特定外掛致命錯誤，而且尚未新增內容、處理訂單或變更設定，可先從主機控制台切回原先記錄的 PHP 版本。
切回後要清除主機、外掛與 CDN 快取，再重新測試。若切回仍無法恢復，或錯誤出現在自訂程式碼與資料庫升級後，問題可能不只來自 PHP。
何時需要還原檔案與資料庫
升級期間若同時執行自動更新、外掛更新、修改設定，或資料庫結構已異動，單純切回 PHP 可能不足。此時先評估備份時間點與交易資料，再決定是否還原檔案與網站備份內容。
切回 PHP 與完整還原是不同處理，不應混為一談。若網站無法登入後台，可採取以下替代處理：
- 查看網站管理員信箱，使用 WordPress 寄出的 Recovery Mode 特殊連結登入。
- 透過 FTP、SFTP 或主機檔案管理員，暫時重新命名剛更新的外掛資料夾。
- 在主機控制台查看錯誤日誌，確認是哪個檔案或外掛產生錯誤。
- 請主機代管協助還原指定時間點的快照，並先確認是否包含資料庫。
程式碼錯誤應先定位問題外掛或客製程式，再進行錯誤修復，不要直接刪除正式資料。
WordPress Recovery Mode 操作說明 提供了從管理員信件進入復原模式的方法。若網站有持續交易或會員資料異動，還原前先確認備份是否涵蓋相關時間點，以及可能遺失的訂單或會員資料，必要時由維護人員進行比對。
常見問題
PHP 8.3 和 PHP 8.4，該選哪一個？
不要直接假設某個 PHP 版本適合所有網站。先查閱 WordPress 與 PHP 官方目前的支援資料，再於測試環境驗證核心、外掛與佈景主題。
確認錯誤紀錄與關鍵流程都正常後，再決定正式站使用哪個版本。不要只根據外掛頁面的「相容」標示切換。
為什麼掃描結果沒問題，正式站仍然出錯？
掃描工具無法涵蓋所有動態呼叫、第三方 API、快取行為與資料庫內容。外掛相容性問題，可能只在付款、表單送出、背景排程或特定會員權限下出現。
因此，測試時要走完實際使用流程，並觀察日誌。掃描結果是排查起點，不是正式上線的保證。
只有白畫面，沒有錯誤訊息怎麼辦？
若出現白畫面或致命錯誤，先查看主機的 PHP 錯誤日誌，再檢查是否收到 WordPress Recovery Mode 信件。
若能使用 SFTP，暫時停用最近更新或最可疑的外掛，協助找出衝突來源。不要在正式站長時間公開輸出除錯內容，避免暴露檔案路徑、外掛資訊或其他系統細節。
主機沒有舊版本，無法直接降級怎麼辦？
先聯絡主機代管，確認是否能切換至仍受支援的版本。升級期間也應暫停自動更新，完成驗證後再恢復。
如果檔案、設定或資料庫已經改變，應改用已確認可還原的網站備份或快照。不要只依賴降級來處理問題。
把 PHP 升級變成可控的維護流程
PHP 升級的價值不只在追上新版本，也是網站維護的一環，涵蓋版本盤點、核心與套件相容性、staging 測試、網站備份及正式環境驗證。維持受支援的 PHP 環境，可避免因停止支援而失去安全更新，讓網站持續具備可維護性。
當錯誤發生時，先保住服務可用性，再依日誌判斷是否切回 PHP、停用問題外掛或還原資料。網站安全與效能提升仍取決於主機、快取、資料庫和程式碼，不能保證固定改善。這套 可回復的流程，也要搭配自動更新的測試、紀錄與回復機制，比單靠一鍵升級更可靠。