在台灣接案市場上，WordPress 案子有很高的比例是 WooCommerce，而 WooCommerce 這幾年正在經歷跟佈景主題一樣的轉變 — 從 PHP 範本與短代碼搬到區塊與 API。
先講清楚現況。WooCommerce 現在的前台有兩套實作並存：
| 舊的一套 | 新的一套 | |
|---|---|---|
| 購物車頁 | [woocommerce_cart] shortcode |
woocommerce/cart 區塊 |
| 結帳頁 | [woocommerce_checkout] shortcode |
woocommerce/checkout 區塊 |
| 商品列表 | [products] shortcode 或範本迴圈 |
Product Collection 區塊 |
| 前台改版方式 | 覆蓋 woocommerce/ 範本檔 |
組合區塊、改 theme.json |
| 資料怎麼來 | PHP 直接查資料庫、伺服器端組 HTML | 前端打 Store API 拿 JSON |
| 擴充方式 | add_filter 改 PHP 輸出 |
註冊欄位、註冊金流整合、Store API 擴充 |
兩套都還能用，新開的店預設會用新的。但網路上大部分中文教學寫的是舊的那一套，而那些做法在區塊結帳頁上完全無效，這一部要處理的就是這個落差。
這個轉變其實跟我們前面講的完全同構：
single.php；WooCommerce 舊做法改商品頁 → 覆蓋 woocommerce/single-product.php
templates/single.html；WooCommerce 新做法改商品頁 → 編 single-product 這個區塊範本實際上 WooCommerce 就提供了一整組區塊範本，跟主題的 templates/ 是同一套機制：
woocommerce/templates/templates/
├── archive-product.html
├── page-cart.html
├── page-checkout.html
├── order-confirmation.html
└── blockified/ # 全區塊化的版本
也就是說之前介紹區塊的內容在 WooCommerce 這邊直接適用，差別只在於那些區塊裡面裝的不是靜態內容，而是購物車、結帳這種帶狀態的互動元件。
如果只看到短代碼換成區塊那還只是換個外殼，真正改變開發方式的是 **Store API，**WooCommerce 提供了一組公開的 REST 端點，讓前端能直接操作購物車與結帳。實測一下你自己的站台（不用登入，這是公開端點）：
$ curl https://your-site.com/wp-json/wc/store/v1/
然後會出現多個端點：
/wc/store/v1/cart
/wc/store/v1/cart/add-item
/wc/store/v1/cart/remove-item
/wc/store/v1/cart/apply-coupon
/wc/store/v1/cart/select-shipping-rate
/wc/store/v1/cart/update-customer
/wc/store/v1/checkout
/wc/store/v1/products
/wc/store/v1/products/collection-data
…
看一下購物車端點回傳什麼：
$ curl https://your-site.com/wp-json/wc/store/v1/cart
billing_address, coupons, cross_sells, errors, extensions, fees,
has_calculated_shipping, items, items_count, items_weight, needs_payment,
needs_shipping, payment_methods, payment_requirements, shipping_address,
shipping_rates, totals
這就是新版購物車與結帳頁的資料來源，前端是 React，狀態存在瀏覽器裡，每個動作（改數量、套用折價券、選運送方式）都打一次 API 拿回完整的購物車狀態然後重繪畫面。整個結帳流程從「送出表單、整頁重載」變成「打 API 局部更新」。
注意 extensions 這個欄位，它是留給你放自訂資料的地方，之後提到資料流時會用到。
一、舊的 PHP hook 大部分失效
你熟悉的 woocommerce_checkout_fields 這類 filter 是用來改 PHP 產生的結帳表單，而區塊結帳頁的表單是 React 畫的，資料來自 Store API。用原本的 filter 區塊結帳頁不會有任何變化。
二、前後端要各做一次
以前加一個結帳欄位改 PHP 就結束了，現在你要讓欄位出現在 React 表單裡（前端）、也要讓它通過驗證並存進訂單（後端）。好消息是 WooCommerce 提供了 API 讓你一次註冊、兩邊生效，不用真的寫兩份。
三、擴充點變少了，但變乾淨了
舊做法你可以用 filter 改任何一段 HTML，自由度極高，代價是 WooCommerce 每次改版都可能弄壞你的客製。新做法的擴充點是明確定義的 API，能做的事變少，但升級時不會突然爆炸。
這跟第二部講區塊佈景主題的理由是同一個，舊做法要 AI 改對它得知道你的主題覆蓋了哪些範本、哪個 hook 在哪個位置觸發、輸出的 HTML 長什麼樣，這些事散落在各處，增加 AI 開發時上下文遺失的風險。
新做法有明確的 API 邊界：註冊欄位有固定格式、金流整合有抽象類別要實作、資料有 schema。邊界明確的東西 AI 產出的正確率高很多，而你 review 的成本也低，因為你知道該檢查哪幾個點。
然而 WooCommerce 這幾年的 API 變動很快，AI 的訓練資料很可能停在舊版**，**它會很自信地給你 woocommerce_checkout_fields 的做法，因為網路上這種寫法最多，所以這一部的每一篇我都會把「AI 最可能給你的錯誤答案」跟「現在正確的做法」放在一起講。
接下來九篇的路線是這樣：
下一篇我們先把 WooCommerce 的區塊仔細盤點，光是 WooCommerce 自己註冊的區塊就有一百多個，先知道有哪些積木之後才後再組裝時才知道要用哪些材料。
文章目錄：https://oberonlai.blog/category/2026-ithome/
Hi, 我是 Oberon Lai，十多年前我從一個不懂程式的平面設計師，一頭栽進 WordPress 的世界。從佈景主題到外掛開發，從接案到自研產品，這段旅程讓我深刻理解：好的技術不只是寫出能跑的程式碼，而是真正解決人的問題。
我積極投入參與社群，公開演講紀錄如下：
我專精 WordPress 開發，從企業形象網站的設計與開發、佈景主題客製化，到既有網站的改版升級，提供完整的 WordPress 建置服務。開發面涵蓋外掛開發與維護、區塊編輯器（Gutenberg）客製區塊、ACF 與 Custom Post Type 的資料架構設計，以及 REST API 整合與 Multisite 多站架構建置。同時也協助網站效能改善與 SEO 調校、安全性檢測與強化，並導入自動化部署與版本控制流程，搭配長期的技術顧問與維運支援，讓網站上線後也能穩定運作。
亦提供 WooCommerce 商店的建置與設定，並串接綠界、LINE Pay、藍新等台灣主流金流。可依需求進行結帳頁面客製化、訂單狀態自動化流程設計，以及商品管理與庫存系統的客製開發；也支援 WooCommerce Subscription 定期定額、REST API 應用開發、報表與數據匯出等進階需求。此外，透過購物流程 UX 改善、電商網站效能調校與 HPOS 高效能訂單儲存相容開發，全面提升營運效率，並提供電商營運技術顧問服務。
AI 浪潮席捲而來，我選擇擁抱而非恐懼，我把 AI 融入開發工作流以及客戶的產品中，也持續累積「AI 看不見的部分」：真實踩坑經驗、最新漏洞情報那些只有第一線工程師才看得見的細節，如果你有任何 WordPress 的客製化需求或是 AI 開發相關的問題非常歡迎加入 LINE 官方帳號與我聯繫：
https://page.line.me/vrf7844t?oat_content=url&openQrModal=true
如果想要獲取 AI 開發實戰經驗也能訂閱我的電子報，每週五上午準時出刊：
https://oberonlai.blog/wordpress-newsletter/
iThome鐵人賽
看影片追技術