WordPress 7.0 新功能總覽＋升級檢查清單

WordPress 7.0 於 2026 年 5 月 20 日正式發布，代號 Armstrong，官方將它定位為把 AI 基礎建設帶進核心的新時代起點。這一版同時翻新了整個後台介面、新增多個實用區塊、調整開發者工具，並把 PHP 支援下限一口氣提高到 7.4。如果你管理的網站還停在 6.x，這一版的升級前檢查特別值得認真做，因為環境門檻變了，AI 功能的定位也和過去的改版邏輯不同。

WordPress 7.0 在版本史上的位置

依照 WordPress 官方文件的記載，WordPress 7.0 於 2026 年 5 月 20 日對外發布。官方發布公告以爵士樂手 Louis Armstrong 的名字為這一版命名，介紹他是公認的第一位偉大爵士獨奏者，親手把爵士樂從樂團形式的藝術轉變為獨奏者的藝術。用音樂家命名版本是 WordPress 的老傳統，官方公告說得明白，每一個版本都在向一位對音樂世界留下深刻印記的藝術家致意。

代號之外，版本號本身跳上 7.0 也帶有宣示意味。官方公告把這一版定位為新時代的起點，說它為 AI 貫穿整個 WordPress 體驗打下地基。從後續的官方路線圖也能看出這層意義，WordPress 專案在 2026 年設下的目標之一，是交付三個主要版本，並讓 7.0 推進第三階段的協作功能、客戶端媒體處理、響應式樣式控制與更多區塊工具。

這些目標不是空話，拆開 7.0 的內容清單就能對上號。AI 軸線由 AI Client、Abilities API、Connectors 畫面與 Connectors API 幾個部件撐起，後台軸線有全新配色與畫面轉場，響應式軸線出現了依裝置顯示區塊的控制，區塊工具軸線則補上 Heading、Icons、Breadcrumbs 三個新區塊。路線圖上的響應式樣式控制與區塊工具等關鍵詞，在 7.0 已找得到對應的實體功能，即時協作則如後文所述移出 7.0，這也是把 7.0 稱為分水嶺版本的實質理由。

從規模數字看，這是一次大型改版。官方發布公告稱，超過 875 位來自世界各地的貢獻者參與了 7.0，其中超過 200 位是首次參與的新貢獻者，整體交付了 420 項以上的強化與修正。開發團隊在 Field Guide 補充了更細的帳面數字：核心追蹤系統裡有超過 419 張票證列入這一版，其中 76 張以上屬於強化與功能請求，超過 300 張是錯誤修正，另有 40 張以上聚焦在編輯器、90 張以上聚焦在管理後台。納入這一版的 Gutenberg 22.0 到 22.6 各版本，合計帶來 411 項強化與超過 486 項錯誤修正。

想看第一手資料的讀者，可以直接查官方發布公告、開發團隊整理的 WordPress 7.0 Field Guide，以及官方版本說明頁。以下的功能整理與升級建議，都以這幾份官方資料為本。

版本時間線：從 6.9 到 7.2

把 7.0 放進時間線看，節奏會更清楚。前一代 WordPress 6.9 代號 Gene，於 2025 年 12 月 2 日發布。7.0 之後的 WordPress 7.1 代號 Mary Lou，於 2026 年 8 月 19 日發布。再往下一版，官方路線圖把 7.2 排在 2026 年 12 月 10 日，同時載明這個日期僅供粗略規劃參考。

對時間敏感的讀者，可以把官方路線圖加入書籤，路線圖並載明新功能會在發布前一個月凍結，之後焦點全放在該版本的品質與效能。安排升級時程時，先確認本站使用的主題、外掛與自訂區塊能配合目標版本，並在更新前完成相容性測試。

↔ 左右捲動檢視完整表格

版本	代號	發布狀態	官方記載日期
WordPress 6.9	Gene	已發布	2025 年 12 月 2 日
WordPress 7.0	Armstrong	已發布	2026 年 5 月 20 日
WordPress 7.1	Mary Lou	已發布	2026 年 8 月 19 日
WordPress 7.2	路線圖未列代號	預定日期（官方標明僅供規劃參考）	2026 年 12 月 10 日

一個實際的推論：因為 7.1 已經發布，現在才要處理升級的網站，不需要特別停留在 7.0。7.1 的版本說明頁寫的是與 7.0 同一套更新流程，從管理後台的控制台＞更新選單就能自動更新到最新版本。換句話說，7.0 這一版的意義不在「趕快升上它」，而在於它引入了 AI 架構、後台改版與 PHP 門檻變動。評估 7.1 的升級時，這些變化值得逐項核對。後續版本的功能與支援條件，仍要對照該版本的官方說明與網站相容性測試。

三種網站，三種升級急迫度

升級的急迫度因站而異，先對號入座再決定節奏。第一種是還在 PHP 7.2 或 7.3 上運作的網站，這類網站已經被 7.0 的環境門檻擋在門外，官方說明它們會留在 6.9 分支，修正會在可行時回溯至 WordPress 4.7，但無法取得 7.0 的新功能。這類網站若要升上 7.0，須先規劃 PHP 環境升級與相容性測試。

第二種是主機環境已達標、網站運作穩定的維護型站長。這類網站仍要先確認外掛、主題與自訂區塊能配合新版，再備妥檔案與資料庫的可還原備份，從控制台＞更新執行自動更新。更新後巡查重點頁面、編輯流程與網站狀態，特別留意 contentOnly 與預設角色警示，才算走完整份檢查清單。

第三種是想把 AI 用進內容流程的團隊。7.0 之後的 WordPress 具備了供應商中立的 AI 管道，從 Connectors 畫面接上供應商、安裝公告提到的選配 AI 外掛，產圖、標題摘要、替代文字建議就能進入編輯器。這類團隊可先測試供應商連線與外掛功能，再決定是否納入內容流程。

AI 進入核心：這一版真正的分水嶺

7.0 極具分量的一句官方定調，是它「為 AI 貫穿整個 WordPress 體驗奠定基礎」。具體拆開來看，這次進到核心的不是某一個 AI 功能，而是一組基礎建設，讓 WordPress 本身具備和生成式 AI 模型溝通的管道。這和「內建一個 AI 寫作助手」是不同層級的設計。

Field Guide 兩度強調一個關鍵詞：供應商中立。新的 WP AI Client 提供一個中央介面，讓外掛能與生成式 AI 模型溝通，而且不綁定任何一家供應商，請求路由由 WordPress 核心處理。對站長的意義在於，AI 供應商的選擇權留在自己手上，官方在 Connectors 畫面預設列了 Anthropic、Google、OpenAI 三家，也開放自行設定其他連線。外掛若透過這套供應商中立的介面呼叫模型，改用另一個供應商時可沿用核心的請求路由，但仍需核對模型能力、驗證方式與外掛實作，不能預設應用無須調整。

更值得留意的是這套機制的野心不只是 AI。官方功能總覽頁說明，Connectors 畫面是管理各種對外服務整合的單一中樞，AI 供應商只是其中一類，任何需要連接外部服務的外掛，都可以運用這套標準化的連線管理系統。採用 Connectors API 的外掛可使用核心的標準化連線管理。站長能在同一個入口檢視已註冊的連線器與中繼資料，未採用這套 API 的外掛仍須依各自的設定頁檢查連線。

Field Guide 開頭綜覽的收尾一句值得原味咀嚼，開發團隊說這些關鍵的基礎建設只是開端，鋪的是通往代理式協作者的道路。7.0 提供 AI Client、Abilities API 與連線管理等基礎。團隊若要採用相關功能，可先核對供應商、模型與外掛的實作。各功能的介紹與畫面演示，官方功能總覽頁有完整整理。

WP AI Client 與 Abilities API：核心裡的 AI 引擎室

WP AI Client 是這套 AI 架構的中樞。官方公告的說法是，核心裡新的 AI Client 讓 WordPress 能與生成式 AI 模型溝通，連線則集中在一個後台中樞管理。開發筆記 Introducing the AI Client in WordPress 7.0 與 Field Guide 對它有更完整的說明，模型可以先從預設清單入手，再加入自己愛用的項目。

與 AI Client 綁在一起的是 Abilities API。Field Guide 說明，Abilities API 直接整合進 WP AI Client，提供可編織進工作流程的新 AI 能力，讓多個能力接連流暢執行。對外掛開發者來說，核心可處理請求路由，Abilities API 則提供組合能力與工作流程的基礎。模型能力與外掛實作仍須自行核對。

開發者側的配套也相當完整。開發者可以用新的 using_model_preference 函式宣告模型的偏好順序，配合功能偵測把能力對應到可用的模型，官方說這能降低成本並加快處理速度。進階呼叫有 WP_AI_Client_Prompt_Builder 類別可用，而 wordpress/wp-ai-client 套件會自動處理升級到 7.0 的轉接。這些名字不需要一般站長記住，但它們說明了一件事，官方這次是認真把 AI 當成一等公民的基礎建設來做，不是掛個聊天框交代了事。

Connectors 畫面與 Connectors API：連線管理的新家

對一般使用者來說，AI 架構裡看得到的部分是 Connectors 畫面，位置在設定＞Connectors。官方公告形容它是所有對外連線的中央樞紐，內建三個預設選項，也可以加入自己的連線，完成驗證後「點幾下」就能開始使用 AI 能力。以第一次設定的體驗來說，這樣的設計把連接供應商的設定，收斂成單一畫面的表單作業。

支撐這個畫面的是 Connectors API。Field Guide 把它稱為 Connectors 畫面的骨幹，一套支援納入各種代理程式的擴充 API。目前它支援兩種驗證方式，api_key 與 none，依供應商的中繼資料決定。開發者可以透過 wp_connectors_init 動作覆寫連線器的中繼資料。若要建立新型連線器，仍須依相關開發文件確認註冊流程與驗證需求。

對裝了多個外掛的網站來說，這個畫面還有一層管理價值。採用 Connectors API 並完成註冊的連線器會在 Connectors 畫面自動顯示，登錄的中繼資料也以卡片形式呈現。站長可以從這裡檢視採用此機制的連線器，並依供應商的中繼資料確認支援 api_key 或 none。其他外掛的連線與金鑰仍須按實際設定方式盤點。

Client-Side Abilities：AI 能力的瀏覽器端搭檔

AI 能力不只在伺服器端。7.0 還引入了 Client-Side Abilities 套件，官方公告說它是 Abilities API 的 JavaScript 對應版本，附帶內建介面與命令面板，交付大量新的與混合型的 AI 能力。這套 JavaScript 對應機制讓外掛可以建立客戶端能力，也能和伺服器端能力組成工作流程。能力是否呼叫伺服器，取決於外掛的實作，不能只憑套件名稱推定互動速度。

開發者側的使用方式，Field Guide 寫得具體：佇列 @wordpress/core-abilities 會自動透過 REST API 抓取並註冊伺服器端的能力，只佇列 @wordpress/abilities 則單獨處理外掛自己的客戶端能力。註冊完成的能力會依可自訂的分類整理。開發者可透過對應套件處理伺服器端或客戶端能力，編輯器裡的實際介面與操作仍取決於各外掛如何實作。

Client-Side Abilities 把能力機制延伸到 JavaScript 端，官方同時提到客戶端與混合型能力。開發者可按功能需求選擇客戶端能力，或透過 @wordpress/core-abilities 取用由 REST API 註冊的伺服器端能力。兩種路徑的實際互動速度須依外掛實作與網站環境測試，不能由套件名稱直接推定。

REST API 在 7.0 扮演的角色，也讓另一條架構路線更值得認識：無頭 WordPress。這種做法把前台完全交給另一套前端程式，只把 WordPress 留作內容管理與資料來源，所有內容經由內建的 REST API 或外加的 WPGraphQL 介面取得。無頭架構的完整入門從定義、工具選擇到 SEO 與資安影響一次講清楚，評估網站要不要走向前後端分離時是很好的起點。

選配 AI 外掛：把工具裝進編輯器

核心的 AI 架構之外，官方公告同時點名了一個新的 AI 外掛。它是選配性質，安裝後能把一組持續增加的工具直接帶進編輯器，官方列出的例子包括產生與編輯圖片、建立標題或摘要、建議圖片的替代文字。功能總覽頁的說法相同，並補充這組工具會持續成長。

這個「核心放架構、外掛放工具」的分層值得細看。核心提供 AI Client、Abilities API 與連線管理機制，產圖、標題摘要和替代文字建議則由公告提到的選配 AI 外掛提供。有產圖、寫摘要、補替代文字需求的人，再自行安裝外掛取得工具。想使用替代文字建議的內容團隊可安裝選配外掛，並由編輯人員覆核建議是否符合圖片內容。

後台翻新：Modern 新風貌

除了 AI，7.0 另一個一眼就看得到的變化是管理後台。官方公告說這一版帶來徹底翻新的管理後台，配上時尚的新配色與乾淨的收尾。新主題有正式名字，就叫 Modern，Field Guide 記載它涵蓋管理頁首，配色選擇器、指令碼載入器與若干使用者函式都在換裝範圍，多站網路的使用者註冊頁也一併更新。

官方對 Modern 主題的描述是：煥然一新的調色盤、更高的對比、升級的字體排印。功能總覽頁的說法更白話，管理後台變得更安靜、更現代，換上全新的預設配色，按鈕與輸入框都更新過，頁面之間用淡出淡入銜接，不再是過去的生硬切換。編輯與管理人員接觸新配色、按鈕、輸入框與轉場時，可在更新後巡查操作流程是否符合網站需求，並記錄要調整的地方。

畫面轉場與減少動態的尊重

後台的轉場效果背後是跨文件檢視轉場技術。Field Guide 說明，系統為管理選單項目設定個別的轉場名稱，在子選單於畫面間切換時觸發簡單的視覺滑動效果。技術細節之外，更值得肯定的是無障礙考量，官方明確寫著，只有作業系統層級沒有設定減少動態偏好時，檢視轉場才會啟用。更新後可確認後台轉場是否遵循作業系統的減少動態偏好。

⌘K 命令面板快捷：後台操作的新入口

7.0 在上方管理列加入了命令面板的快捷圖示，登入使用者會看到 ⌘K 或 Ctrl+K 圖示，點一下就展開命令面板。官方公告的形容是，不論你在後台哪個畫面，都能一鍵取用愛用工具。把命令面板放進預設管理列，這種「打字找功能」的操作方式，顯然被官方視為重要入口。

字型總管：字型管理獨立成頁

字型管理在 7.0 有了專屬頁面。官方公告說，不論使用哪種佈景主題，都可以從同一個地方探索字體排印，在新的字型管理頁面安裝、上傳並管理字型收藏，支援區塊、混合與傳統三類主題。功能總覽頁補充了關鍵的前後差異，字型庫過去只在區塊主題提供，現在則橫跨所有 WordPress 主題。

這個改動對還在用傳統主題的網站意義尤其大。字型庫過去只支援區塊主題，7.0 才擴及傳統與混合主題，讓站長能從新的專屬頁面安裝、上傳與管理字型收藏。這說明字型管理入口擴大了，更換主題後字型與版面的呈現仍須在實際網站確認。

視覺化版本修訂：把編輯史變成時間軸

版本修訂系統在 7.0 變得更直觀。官方公告形容，可以視覺化地滑過各個修訂版本，一眼看出哪裡變了，標記讓編輯決策更直覺，選好要的版本後立即還原。功能總覽頁的描述更具體，用時間軸滑桿檢視文章的修訂歷史，看見文件裡每個區塊層級的視覺標記變化，找到想要的版本後一鍵還原。

Field Guide 補上了編輯器內的細節，使用者可以直接在編輯器裡用滑桿比對兩個修訂版本，文件檢查器會顯示變更摘要，每個變更位置有顏色指示與變更規模，點下去就跳到頁面上的那個位置。編輯者可用摘要、顏色指示與位置跳轉，直接比對要查的修訂內容。

三個新區塊與圖庫燈箱：排版工具補齊

區塊層面，Field Guide 記載 7.0 出貨了三個新區塊，Heading、Icons、Breadcrumbs，同時為 Gallery 區塊加入燈箱支援。同時導覽連結區塊支援動態網址，Cover 區塊可以嵌入影片作為區段背景。

新的 Heading 區塊內建所有標題層級的變體，在側邊欄檢查器快速切換層級，也支援快速轉換，並出現在搜尋與斜線插入器裡。標題層級需要調整時，可以在側邊欄檢查器切換，也能透過快速轉換選用合適的標題變體。Icons 區塊則讓你可以在頁面任何位置加入圖示，從內建圖庫挑選、放入後再依設計調整樣式。

Breadcrumbs 區塊對內容網站特別實用。Field Guide 說明它會自動反映網站的導覽層級，適合放在頁首等全域部位，開發者也能透過新的篩選器增刪修改麵包屑路徑，指定要出現的分類法與詞彙。這讓網站能依自身導覽層級與分類法設定麵包屑路徑。啟用後仍須檢查實際頁面的連結與層級是否正確。

實際編排內容時，這批新區塊的組合值得想一想。Breadcrumbs 放進頁首等全域部位後，讀者可從麵包屑查看網站呈現的導覽層級，實際連結與層級仍須檢查。Icons 區塊讓圖示的加入變成編輯器裡的標準操作，跨頁面的圖示樣式仍須由編輯者確認。Heading 區塊可以在側邊欄切換層級，也支援快速轉換。若插入後發現層級不合適，可透過這些操作調整。

Gallery 區塊的燈箱支援附帶幻燈片選項。官方的操作說明很簡單，建立並插入圖庫後，點連結圖示再選「點擊放大」（原文 enlarge on click）即可。段落區塊也有新能力，文字可以排成欄位版面，並新增可選用的文字縮排支援。Field Guide 逐項列出文字行縮排、文字欄位、寬高尺寸支援、尺寸預設值與寬幅全幅圖片的長寬比等一系列排版支援的擴充，排版精細度的天花板又抬高了一截。

依裝置顯示區塊：行動版排版的正規軍

7.0 引入了依裝置類型自訂區塊可見性的能力。官方公告的說法是，可以依裝置隱藏或顯示區塊，而且不影響其他視區。功能總覽頁給了使用場景，選擇每個螢幕尺寸要出現哪些區塊，建立更乾淨的行動版版面，簡化區段，同時在迭代過程中保留替代版本。

操作的入口也不止一處。Field Guide 記載，區塊工具列、區塊檢查器側邊欄與命令面板都能開啟區塊可見性選項視窗，清單檢視裡則會在有作用中可見性規則的區塊旁顯示圖示，標明它在哪些視區被隱藏。例如想讓電腦版保留一個區塊、手機版隱藏它，可以透過新的可見性設定處理，並在清單檢視查看該區塊套用的視區規則。

運用上有一個提醒，可見性規則是排版工具，不該被當成內容策略的替代品。比較健康的用法是把桌面版的裝飾性元素、大型圖片或次要的促銷區塊，在行動版收乾淨，讓手機使用者先看到內容本體，而不是把重要資訊一律藏起來。規則立好後，也記得在實際裝置上抽查幾頁，確認每個視區呈現的都是預期的樣子。

導覽覆蓋層與 Pattern 單元化：選單設計的自由度

7.0 把行動版的漢堡選單覆蓋層區塊化了。官方公告說，選單覆蓋層可以用區塊與模式設計打造，樣式完全自訂。Field Guide 的細節是，漢堡選單覆蓋層可以在網站編輯器裡用區塊與模式自訂，並有一個專屬的 Navigation Overlay Close 區塊，讓你把關閉按鈕放在覆蓋層裡的任何位置並調整樣式。功能總覽頁則點出設計自由度，可以加欄位、放大字體、對齊到滿意為止，從預先建好的範本起步，或從零打造。

Pattern 的行為也升級了。官方公告形容，模式可以作為單一單位行動，需要更細的控制時可以拆離。功能總覽頁的說法更貼近使用情境，把模式放到頁面上，它就像一個區塊那樣行動，不必在層層巢狀區塊裡翻找想改的元素，替換文字與圖片、從檢查器調整樣式，需要進階編輯時點一下「編輯模式」（原文 edit pattern）就能取用全部工具。

伴隨而來的是一個開發者需要留意的重大變更。Field Guide 載明，過去依賴內部區塊不受限編輯的模式，現在預設進入 contentOnly 模式，新的 disableContentOnlyForUnsyncedPatterns 設定或 block_editor_settings_all 篩選器可以為未同步模式退出這個預設。這項預設改變了模式的可編輯範圍，更新前應核對既有模式的操作需求。對做模式產品的外掛與主題開發者，這是 7.0 該優先驗證的相容性變更之一。

區塊層級自訂 CSS：樣式控制下沉到區塊

自訂 CSS 在 7.0 下放到區塊層級。官方公告說，可以在文章或頁面裡直接為個別區塊套用自訂 CSS，精細控制內容的每個細節。針對需要特別處理的版面，可以把樣式規則限定在個別區塊。編輯時仍應查看前台呈現，確認區塊在不同視區的樣式符合預期。

開發者工具箱：PHP-only 區塊與可擴充的網站編輯器

開發者側的變化集中在三個方向。第一是 PHP-only 區塊註冊，官方公告說區塊與模式可以直接在伺服器端用 PHP 建立並自動向區塊 API 註冊。Field Guide 的細節是，當區塊宣告 supports 裡的 autoRegister 為 true 並搭配渲染回呼，就會自動註冊並曝露給客戶端，屬性可以在編輯器裡編輯，檢查器控制項也能從屬性自動生成。對熟悉 PHP 的開發者，這提供只用 PHP 建立區塊與模式的路徑。

第二是 Interactivity API 的新 watch 函式，它訂閱回呼內存取的任何信號變化，信號一變就重新執行回呼，為互動式區塊提供更細的響應能力。第三是可擴充網站編輯器的地基，Field Guide 說 7.0 鋪好了路由與路由驗證的基礎，新的 @wordpress/boot 套件讓外掛能建立自訂的網站編輯器頁面，@wordpress/scripts 也重構為從目錄建置，減少對 Webpack 的依賴。

其他值得記下的還有，Block Hooks 的邏輯從各自的文章類型篩選器搬到 REST 控制器，外掛清單頁新增 plugins_list_status_text 篩選器，分頁標籤文字可自訂。DataViews 與 DataForms 則有新的 Activity 版面、Details 版面、改善的視窗外觀，以及欄位 API 支援註冊第三方類型。這些變更擴充了外掛清單自訂、資料版面與網站編輯器整合所需的工具。

對不寫程式的讀者，這一段的意義在於生態走向。PHP-only 註冊讓開發者可用 PHP 建立區塊與模式，網站編輯器的路由與自訂頁面則為外掛提供新的整合入口。這些功能能否改善現有網站的編輯流程，仍須依外掛實作與相容性測試判斷。

效能與無障礙：圖片載入與操作支援的改善

效能方面，功能總覽頁記載 7.0 改善了圖片載入優先順序的準確度，避免導覽覆蓋層或互動區塊裡的隱藏圖片拖累關鍵資源的載入。傳統主題的按需區塊樣式表載入更可靠，腳本也能相依於腳本模組以減少轉譯阻塞。圖片載入與轉譯阻塞會影響關鍵資源何時送達，實際速度改善幅度仍須以更新前後的量測結果判斷。

無障礙方面，功能總覽頁說明 7.0 涵蓋全平台的修正，改善媒體管理、語音控制的可用性，並隨新配色提升色彩對比。Field Guide 補了兩個具體項目，新的 wp_get_image_alttext 函式會從圖片的 IPTC 中繼資料匯入替代文字，登入密碼重設則預先填入使用者名稱以符合 WCAG 2.2。標題屬性的清理也在同步進行，三個作者連結函式預設移除標題屬性，兩個函式可用新參數控制。這批無障礙修正針對媒體管理、語音控制與色彩對比，升級後仍可用實際頁面檢查輔助操作是否符合預期。

對圖片檔含有 IPTC 替代文字中繼資料的工作流程，新的 wp_get_image_alttext() 函式提供匯入這項資訊的途徑。若網站希望運用這項能力，仍須測試圖片匯入後的欄位結果，不能只因函式存在就推定替代文字已自動補齊。

基礎環境：PHP 下限提高到 7.4

對不少網站來說，7.0 該優先處理的變更其實很樸素，PHP 版本門檻。開發團隊在 2026 年 1 月的PHP 版本支援說明中交代，7.0 停止支援 PHP 7.2 與 7.3，最低建議版本維持 8.3，新的最低支援版本是 7.4.0。調整的依據也寫得清楚，上一次調高最低支援版本是 2024 年 7 月到 7.2.24，此後 PHP 7.2 與 7.3 的合計使用率跌到受監測 WordPress 網站的 4% 以下，低於專案慣用的 5% 門檻。這條線的由來官方也有交代，某個 PHP 版本的使用率必須跌破 5% 基準，才會被考慮讓它功成身退。

版本搭配上，官方說明 WordPress 核心與 PHP 8.0 到 8.3 完整相容，與 8.4 及 8.5 則是搶鮮相容。官方需求頁開出的建議環境是 PHP 8.3 以上，資料庫 MariaDB 10.11 以上或 MySQL 8.0 以上，並支援 HTTPS。需求頁也保留了舊環境的緩衝說明，WordPress 在 PHP 7.4 以上與 MySQL 5.5.5 以上仍可運作。其中已到官方生命週期終點的舊版本，可能讓網站暴露於安全風險。要調整 PHP 版本時，先確認主機商提供的設定方式，不確定就直接詢問主機商。

這份說明也附了一組監測數字，可以看出調整的市場基礎。筆記發布當下，PHP 8.2 占 27.29%，PHP 7.4 占 22.20%，PHP 8.3 占 16.74%，PHP 7.3 與 7.2 各只剩 2.04% 與 1.81%。被淘汰的兩個版本合計不到 4%，這是官方收緊支援線的底氣，也代表跟上腳步的網站占了絕對多數。

周邊套件也有一輪更新。Field Guide 記載，CodeMirror 更新到最新的 v5 版本，伴隨 CSSLint、HTMLHint、JSONLint 一併更新，Esprima 換成 Espree 以支援 ES6 與 JavaScript 檢查。backbone.js 升級到 1.6.1，Requests 庫從 2.0.11 更新到 2.0.17，PHPMailer 更新到 7.0.2。一般站長不需要記這些版本號，但如果網站上有倚賴舊函式庫行為的外掛，升級後的第一次完整巡檢值得包含它們。

即時協作為何缺席

按照官方路線圖的說法，7.0 原本承擔著推進第三階段協作功能的任務，但即時協作最終沒有出貨。開發團隊在 2026 年 5 月 8 日的移出公告中說明，專案層級做出了把即時協作移出 7.0 的決定，原因是對目前的作法是否夠穩健沒有信心，列舉的顧慮包括影響範圍、競爭狀態、伺服器負載、記憶體效率，以及模糊測試中反覆出現的錯誤。公告同時確認發布時程不變。

移出公告列出的顧慮包括影響範圍、競爭狀態、伺服器負載、記憶體效率，以及模糊測試反覆發現的錯誤。這些項目說明了即時協作未納入 7.0 的理由，公告也確認發布時程維持不變。評估網站是否升級，仍要檢查本站環境、外掛與主題的相容性。

這則公告的用詞值得原味呈現，公告說這是困難的決定，畢竟已經投入大量工作，但它是為了交付穩定可靠的 7.0 而做。公告也明確表示，即時協作對 WordPress 仍然重要且令人期待，後續會分享更大範圍測試與持續迭代的計畫，為未來的版本做準備。對期待多人同編的團隊，結論是方向不變，時間點延後。

升級前檢查清單

把官方資訊收斂成實際可執行的檢查，升級 7.0 前建議照下面的順序走一遍。核心邏輯有兩條，環境要先過門檻，相容性要先驗證再更新。

↔ 左右捲動檢視完整表格

檢查項目	檢查內容	官方依據
PHP 版本	至少 7.4.0，建議 8.3。8.0 至 8.3 完整相容，8.4 與 8.5 為搶鮮相容	開發筆記與需求頁
資料庫與 HTTPS	MariaDB 10.11 以上或 MySQL 8.0 以上，支援 HTTPS	官方需求頁
完整備份	檔案與資料庫都要備，並確認備份可還原	升級作業通則
外掛與主題相容	自訂區塊是否使用 Block API v3 以上。未同步模式的 contentOnly 預設變更是否影響編輯流程	Field Guide
預設新使用者角色	設定＞一般裡的預設角色若曾設為管理員或編輯，升級後留意網站狀態的警示	Field Guide

PHP 檢查是整份清單的第一關。可先檢查主機商提供的環境資訊，或直接詢問主機商，把官方建議的 8.3 與最低支援的 7.4 當成兩條線，低於 7.4 就先升主機環境再談 WordPress 更新。資料庫版本與 HTTPS 支援也順手一起確認，這三項是官方需求頁列出的完整環境建議，清單之後官方只補了一句 That's really it，就是這麼簡單。

備份的原則是完整與可還原。檔案與資料庫兩者都要涵蓋，只備其一不算過關，備份完成後確認還原路徑可行，再進行更新。這是版本升級的通則，不因 7.0 而改變，7.0 同時涉及 PHP 門檻、區塊編輯與底層函式庫，更新前確認備份可還原尤其重要。

相容性檢查把力氣放在兩個點上。自訂區塊方面，Field Guide 說明 iframe 編輯器會在文章內所有區塊都使用 Block API v3 以上時強制啟用，未達條件則退回，持有舊版 API 區塊的網站要與開發者確認行為。模式編輯方面，未同步模式的 contentOnly 成為預設，若有外掛或主題依賴過去不受限的內部區塊編輯，先讀它們的更新日誌，或在預備環境完整試一輪。清單之外還有一個環境事實要知道，PHP 7.2 與 7.3 的網站不會收到 7.0 的更新，官方說明這類站台會留在 6.9 分支，修正會在可行時回溯至 WordPress 4.7。若要取得 7.0 的功能，仍須先處理 PHP 環境與相容性。預設角色那項則是 7.0 收窄預設角色選項的調整，管理員與編輯角色已從新使用者的預設角色選單移除，若網站先前選過這兩個角色，網站狀態會在更新時提出警示，開發者也有新的 default_role_dropdown_excluded_roles 篩選器可以調整排除清單。

升級流程與升級後檢查

官方文件給的更新路徑很單純，到管理後台的控制台＞更新選單自動更新，或到版本封存頁手動下載。7.1 的版本說明頁寫的是同樣的流程，印證了前面的建議，晚升級的網站直接更新到最新版即可。對照著看，管理後台提供了更新入口，更新前仍須完成環境、備份與相容性檢查。新手如果想從頭理解安裝與架站的完整流程，可以先讀WordPress 安裝教學與WordPress 架站全攻略。

升級完成後，建議依序確認幾件事。先看網站狀態有無警示，特別是前面提到的預設角色項目。再巡一遍重點頁面的版面，尤其是有巢狀模式與自訂區塊的頁面，確認 contentOnly 與 iframe 編輯器的變更沒有影響編輯流程。後台的新配色與轉場效果順手感受一下，到設定＞Connectors 看看 AI 連線畫面，即使暫不啟用，先知道入口在哪裡。收尾時把關鍵外掛快速過一遍，特別是表單、快取與 SEO 這類深入運作層的工具，有狀況時先回到它們的更新日誌找線索。挑選與評估這類工具的方法，可以參考WordPress 外掛推薦清單。

如果網站同時考慮換主機或調整環境，7.0 的 PHP 門檻是個合理的觸發點，主機選擇的完整比較可以看WordPress 主機挑選指南。備份沒有固定作法的團隊，可以先建立WordPress 備份與還原的基本盤，再考慮導入自動備份外掛。編輯流程的調整則可以搭配區塊編輯器的頁面編輯教學與區塊編輯器外掛的介紹，把新版本的能力放進團隊的日常。網站速度的後續調整，延續到WordPress 速度優化的完整作法。權限與角色的整體規劃，搭配使用者權限指南一併檢視會更完整。

整體看下來，7.0 是一次方向感很清楚的大改版。AI 的地基、後台的翻新、排版的細化、環境門檻的提高，各自指向 WordPress 對下一階段的想像。把升級當成一次網站健檢的機會，照清單確認環境、備份與相容性，更新後再檢查網站狀態、重點頁面與編輯流程，才能知道這次升級是否順利完成。