網頁開發

WordPress 7.0 才上線三週，React 19 就被緊急回退：43% 網站背後，外掛生態的 JS 相依債開始計息

2026.06.12 · 41 次瀏覽
WordPress 7.0 才上線三週，React 19 就被緊急回退：43% 網站背後，外掛生態的 JS 相依債開始計息
“

官方 6 月開發者月報揭露：外掛自帶的 React 18 runtime 與 React 19 同載即崩潰，Core 團隊改走 7.1 漸進路線。一段 grep 指令、一份 createRoot 遷移範例、四種應對策略成本比較，給台灣中小企業與接案商的一週行動清單。 ”

分享：
LinkedIn X LINE Email

2026 年 6 月 10 日，WordPress 官方開發者部落格發佈〈What's new for developers? (June 2026)〉月度更新，這是 7.0「Armstrong」5 月 20 日釋出後的第一份完整開發者情報。整份月報最關鍵的一條只有一行，卻值得每個靠 WordPress 吃飯的人停下手邊工作：React 19 升級已在 6 月 5 日於 Gutenberg 被緊急回退。原因不在核心，而在外掛。對台灣大量仍跑在 WordPress 上的企業官網來說，這一行字直接決定了未來半年的維護排程。

把時間軸拉長看，這不是一次普通的回退。2018 年 WordPress 5.0 引入 Gutenberg 區塊編輯器，把 React 深植進全球最大的 CMS；官方同時提供 @wordpress/element 抽象層，希望外掛作者不要直接相依特定 React 版本。React 19 早在 2024 年 12 月就穩定釋出，Core 團隊等了約 18 個月，原本要在 7.0 週期一口氣升上去，5 月 27 日的 dev note 連外掛遷移清單都列好了。結果上線兩週後宣佈回退：多個外掛自帶打包的 React 18 JSX runtime helpers，與 React 19 同時載入時直接讓編輯器 crash。策略從「一次到位」改成「7.1 週期漸進升級」。

影響範圍遠超出 Gutenberg 本身。根據 W3Techs 統計，WordPress 驅動全球約 43% 的網站；台灣中小企業的官網、活動頁、購物站大量落在這個生態。dev note 列出的必改項目——棄用 ReactDOM.render() 與 hydrate()、改用 createRoot()/hydrateRoot()、移除 unmountComponentAtNode()、避免 findDOMNode()——每一項都指向同一件事：你網站裡某個外掛，可能還活在 2022 年的 React 寫法裡，而這筆債遲早要還。更麻煩的是，客戶通常分不清核心與外掛的責任界線——網站一壞，第一通電話打給的是維護它的接案商，不是外掛作者。

下文提供一段偵測外掛是否自帶 React 的 CLI、一份 render 改 createRoot 的遷移範例、四種應對策略的成本比較表，以及一個與主流相反的判斷：真正的風險從來不是 WordPress 核心太舊。讀完之後，你應該能在一週內，對手上每一個 WordPress 站做出明確的去留決定。

技術細節：回退了什麼、外掛該改什麼

先定座標：WordPress 7.0 最低需求 PHP 7.4、官方建議 8.3、已完整支援 PHP 8.5（見 官方 PHP 支援釐清）；Gutenberg 23.3 隨本期月報釋出。回退主因是 React 19 的 API 斷點，React 官方升級指南與 WordPress dev note 指向一致的必改項目。先用 CLI 揪出自帶 React 的外掛：

# 在 WordPress 根目錄執行：找出 build 產物含 react-dom / jsx-runtime 的外掛
grep -rl --include="*.js" -e "react-dom" -e "jsx-runtime" wp-content/plugins 
  | cut -d/ -f3 | sort -u
 
# 搭配 WP-CLI 比對外掛版本與可用更新
wp plugin list --fields=name,version,update_version --update=available

命中的外掛，再檢查程式碼是否仍用舊 API，遷移方式如下：

// React 18 寫法（React 19 移除）
import ReactDOM from 'react-dom';
ReactDOM.render(<App />, container);
ReactDOM.unmountComponentAtNode(container);
 
// React 19 寫法
import { createRoot } from 'react-dom/client';
const root = createRoot(container);
root.render(<App />);
root.unmount();
 
// WordPress 外掛正解：改從 @wordpress/element 匯入，讓核心統一管理 React 版本
import { createRoot } from '@wordpress/element';

月報其他值得追的線：瀏覽器端媒體處理測試徵集（VIPS 編譯成 WASM，在瀏覽器直接生成圖片 sub-sizes，支援 AVIF、WebP、HEIC、Ultra HDR、JPEG XL，還能把 GIF 轉成影片）；Gutenberg 23.3 把媒體編輯 modal 設為預設裁切體驗，並引入單一 block 實例的 pseudo-state 樣式；wp-now 正式廢棄、改用 Playground CLI；7.1 已啟動協作編輯 outreach。核心動得很快——這是後面觀點的伏筆。

三類讀者的立刻行動

  • 工程師：在 staging 跑上面的 grep，列出自帶 react-dom 的外掛；自家外掛改從 @wordpress/element 匯入並完成 createRoot 遷移，順手檢查 ref callback 回傳值與 TypeScript 型別。
  • 技術負責人：把「外掛 JS 相依性」納入資產盤點，依「官方維護／商業授權／已棄坑」分級，自帶 React 且已棄坑者列入 7.1 前替換名單，並凍結 production 的自動大版本更新。
  • 創業者／接案商：盤點維護合約內的 WordPress 站，主動向客戶發出 7.x 相容性通知——這是把一次性建站轉成經常性維護收入的天然切入點。

比較與權衡：四種應對策略

方案優點缺點遷移成本
等官方 7.1 漸進升級零工時、跟官方節奏主動權在外掛作者手上，7.1 可能再撞牆近乎 0，但風險遞延
自行更新外掛 build立即消債、可控只適用自家或可改的外掛，商業外掛改不動每外掛約 0.5–2 人日
鎖定版本不升級短期最省事安全更新逐步斷供，債務複利0，但累積後最貴
遷出 WordPress 改客製化（如 Laravel）相依性完全可控、長期維護成本可預測前期投入高、需重做內容流程中型站約 1–3 個月專案

不會告訴你的事

  • 反向觀點一：回退是止痛，不是治療。外掛作者失去升級急迫性，債務只是延後到 7.1 再爆一次。@wordpress/element 從來不是強制規範，商業外掛為了相容舊版 WordPress，反而有誘因繼續自帶 React。
  • 反向觀點二：月報亮點沒有看起來那麼能用。瀏覽器端媒體處理目前僅 Chromium 預設啟用，Firefox 與 Safari 預設關閉，RAM 2GB 以下裝置直接跳過——以行動流量為主的台灣電商，短期別把它當可依賴的基礎建設。
  • dev note 的清單只覆蓋官方點名的 API；頁面編輯器、表單類外掛常有自己的 React portal 與事件系統，grep 掃不到的執行期衝突仍可能存在，唯一保險是 staging 實測。

未來 3 個月會發生什麼

7.1 週期會以漸進方式重啟 React 19 升級，預期先在 Gutenberg 外掛通道試水；協作編輯 outreach 的訪談結果將影響 7.1 主打功能。可觀察指標：React 19 相關 ticket 的回報量、主流表單與頁面編輯器外掛的 changelog 是否出現 createRoot、client-side media 在 Firefox/Safari 的預設開關進度，以及 Playground CLI 取代 wp-now 後的開發者遷移速度。

常見問題 FAQ

我的 WordPress 7.0 網站現在會壞掉嗎？

不會。回退代表 7.0 仍然跑 React 18，現況穩定。風險在 7.1 重啟升級時：自帶 React 18 的外掛若屆時仍未更新，編輯器可能再度 crash。現在是盤點的窗口期，不是恐慌期。

怎麼知道哪些外掛自帶 React？

用本文的 grep 指令掃 wp-content/plugins，搜尋 react-dom 與 jsx-runtime 字串；命中的外掛再查 changelog 是否提到 React 19 或 createRoot，沒提到的就寫信問作者或列入觀察名單。

WordPress 7.0 對 PHP 版本的要求是什麼？

最低 PHP 7.4、官方建議 8.3、PHP 8.5 已完整支援。如果主機還停在 7.4，建議把 PHP 升級與外掛盤點排進同一次維護窗口，一次處理兩筆技術債。

我是外掛作者，現在該做什麼？

立刻把 React 匯入改成 @wordpress/element，棄用 render()、hydrate()、unmountComponentAtNode()、findDOMNode()，檢查 ref callback 與 TypeScript 型別，然後用 Playground CLI 在 nightly 環境先測一輪，不要等 7.1 beta。

我的觀點

主流敘事說 WordPress 的風險是「核心老舊、遲早被 headless 方案取代」。這次事件證明恰恰相反：核心現代化的速度——React 19、WASM 媒體處理、Playground CLI、協作編輯——已經快過外掛生態的消化能力。真正的未爆彈是外掛的 JS 相依性債：43% 的市佔率意味著這是世界上最大一片「不受核心團隊控制的 JavaScript 安裝基礎」。React 19 回退不是核心的失敗，而是這筆生態債第一次被迫攤上帳面。

對 ScriptWalker 的啟示有兩個。其一，「WordPress 7.x 相容性健檢」可以打包成固定價維護商品：掃外掛、出報告、給替換與升級建議，交付成本低、可重複賣。其二，當客戶的站重度依賴三個以上自帶 React 的棄坑外掛，就是提出 Laravel 客製化遷移的正確時機——賣的不是重寫，是把不可控的相依性換成可控的。需要健檢或評估遷移：

資料來源

分享：
LinkedIn X LINE Email
網頁開發 返回文章列表
上一篇 顧問型外包：適合誰、怎麼計價，以及什麼時候你其實什麼都不用做 下一篇 多語系網站怎麼做？從網址結構、hreflang 到翻譯流程的完整規劃