WooCommerce 台灣金流結帳區塊


先前分享過 WordPress 目前積極在推動的 WooCommerce Blocks 區塊編輯器,裡面甚至包含了結帳頁的區塊,可以同步購物車的商品數量以及直接在編輯器中管理結帳欄位,但很可惜的是這個結帳區塊支援的金流外掛有限,更不用說是台灣的金流,因此決定自己先跳坑踩個雷來試著整合一下,實作效果如下:

如果你也想體驗看看的話可以依照以下步驟:

  1. 安裝 WooCommerce 6.4.0 版以上
  2. 安裝 WooCommerce Blocks 7.4.0 版以上
  3. 安裝 RY WooCommerce Tools 最新版
  4. 下載 WooCommerce 台灣金流結帳區塊 taiwan-payments-for-wc-block.zip
  5. 啟用以上四支外掛
  6. 啟用 RY Tools 綠界金流模組
  7. WooCommerce 付款方式啟用綠界信用卡
  8. 將結帳頁面的短代碼移除,改用 checkout 區塊

順利的話就可以在 4. Payment Options 的地方看到綠界信用卡的選項:

目前這支外掛只支援綠界信用卡的選項,其他付款方式都還沒整合,所以就先幫我玩玩就好,如果你想用在正式環境的話建議是不要,我接下來會陸續整合其他的台灣金流外掛,有任何想法再跟我說吧,以下是寫給開發者看的內容:

整合 WooCommerce Blocks payment method 心得

心得一句話:「真是天殺的難搞!」

可能東西還很新吧,相關的教學都還只有官方的 Github 說明,而裡面的範例給的是 WooCommerce Stripe Plugin 帶有 52 個檔案變動的 Pull Request,還需要自己爬哪裡用到關鍵的 Hook 跟 Class,然後因為 Stripe 這支外掛結構滿大的,研究起來花了不少時間,後來索性去看 WooCommerce 內建的付款方式是如何整合。

但下場也沒好到哪裡去,woocommerce-gutenberg-products-block 裡面東西更多,引入 block 的方式跟官方文件又有些許不同,於是去抓目前已經有支援結帳區塊的金流外掛,最後找到 woocommerce-gateway-eway 這支,它的結構相對單純好理解得多。

整合過程中踩到以下幾個雷:

1. 找不到抽象類別 AbstractPaymentMethodType

整合的方式跟建立金流很像,也是需要繼承一支類別來給定對應的方法,但不管是用 autoload 還是 require 的方式載入,都無法抓到 WooCommerce Blocks 裡面 AbstractPaymentMethodType 這個類別:

我是直接複製貼上文件裡面的 namespace,想說都完全照貼了怎麼可能還會有錯,搞了好久想說從別的外掛複製看看,才驚覺文件裡面的路徑寫錯,Integration 少了一個 s…

這告訴我官方文件不一定是 100% 正確的…

2. 缺少類別判斷

發現上述問題後以為接下來就海闊天空了,但事情沒那麼簡單,我習慣用 autoload 來載入 PHP 檔案,但發現如果直接在外掛的主檔案做載入的話,依舊抓不到 AbstractPaymentMethodType,後來文件裡面有寫因為載入順序的話,必須要先判斷該類別是否存在,有存在的話才進行載入,實驗過正確的寫法如下:

3. Webpack 編譯環境

本來想打算用官方的 @wordpress/create-block 來做,但知道他是根據 create-react-app 而來的所以應該很肥,因此想說自己來配置 Webpack 環境,無奈東西太多且相關的知識還遠遠不足,目前第一版外掛 JS 的編譯部分我完全沒處理,我是作弊直接拿 WooCommerce 內建的 BankTransfer 編譯過的 JavaScript 來改XD,關鍵在 name 的這個地方要改成跟金流類別裡面同樣的 id 名稱:

詳細的外掛結構可以參考 Github 存放庫,我會繼續把 Webpack 的環境配置給搞懂,到時候再把它開源出來,希望透過這樣的拋磚可以讓開發者大大們願意嘗試整合 WooCommerce Blocks,重點是可以一起交流研究,不然光是少了 s 的那一關我就快被逼瘋了,我們下週見!

WordPress 開發日常

Read more from WordPress 開發日常

創業的時光真是飛快得不可思議。明明才剛寫完第一個月的回顧,怎麼一下子又到了第二個月。這個月我全力投入開發新產品,原以為靠 AI 協助,兩週內就能搞定,沒想到一弄就是一整個月,還卡關連連,導致原本預定的行銷工作停滯不前。但我真的很喜歡開發產品的過程,彷彿在解謎闖關,每解開一個難題就多學一點新知,形成一種自我成長的良性循環。 工作佔比 四月份總工作時數為 65.64 小時,比三月增加了 24 小時。各類工作佔比如下: 行銷:30% 產品更新:7% 產品研發:63% 其中一個週末我整整兩天都在工作,有幾天甚至加班到晚上七點多。比較難統計的是晚上洗完澡到就寢前,還是會用平板跟 AI 討論白天卡住的問題,甚至請它幫我先寫好隔天要用的功能。若將這些時數也納入,總工時應該超過 70 小時。 我覺得比較理想的工作狀態是一個月大約 50 小時。像加班的那個週末,一直卡關讓我很煩躁,為了突破瓶頸逼自己解完才能休息,結果越急越解不開。後來乾脆休息一天,結果回來上工十分鐘就解決了。 所以還是得適時讓自己充電,給大腦一點空白,真正需要動腦時才有空間處理複雜問題。 行銷 內容行銷...

最近剛完成第一個完全由 AI 協助我開發的 WordPress 外掛,想說應該可以來整理一下這次開發的工作流程以及用到的工具,整體的心得是有 AI 實在是快超多,開發的速度跟飛的一樣,尤其是邊做邊想到新功能時,問一下複製貼上就能搞定,就像在裝外掛。 但不變的是 AI 跟我一樣會卡關,雖然每次它的解釋都好像解決了,但實際上測試就是無法,一直回饋給它後丟出新的解法,結果還是不行,這時候就要停下來自己看程式碼,然後思考是哪一行可能會出問題。 發現有可能造成問題的地方,再拿回去問 AI,這時候它就會說:「沒錯,你發現到問題的關鍵了!」我心裡想的是這應該是你要告訴我的啊 🤣,但整體而言這樣的開發節奏讓我可以很快的進入心流,不用擔心程式碼細節而是產品的方向,真的是回不去沒有 AI 協助的日子了~ 以下我從企劃、開發以及除錯階段,來說明我是如何用 AI 來設計這支外掛的。 企劃階段 這支外掛的主要功能是延續我上一個產品的概念,契機是因為 LINE Notify...

自從 LINE Notify 終止服務後所有站長都在找尋替代方案,如果還是想在 LINE 裡面收到管理員的訂單通知,只能採用與一般顧客相同的方式,也就是申請官方帳號接收通知,雖然一樣有免費額度可以使用,但對於量大的站長來說又是一筆新的支出成本。 如果不想要新增這筆開銷,勢必要尋找其他即時通訊軟體來接收通知,像是採用 Discord 或是 Telegram,如果站長本身就沒有在使用這些軟體需要額外安裝,安裝後還需要申請開發者帳號取得金鑰,而網站這邊也要另外使用外掛或是請工程師進行串接。 難道沒有更方便、更優雅的方式來解決這個問題嗎?不僅可以在桌機上收到通知,同時還能推播到手機甚至是穿戴型裝置上,最重要的是每一則推播不會被收費、也不用擔心原本免費的方案終止服務或是漲價,而這解決方案我們在各大新聞網站都曾見過它,那就是網頁推播通知技術 ( Web Push Notification )。 外掛介紹 DWP 網站助理整合網頁推播通知,可以讓訂閱者在訂單狀態改變時收到推播訊息,支援所有平台,包含 Windows、MacOS、Android 以及 iOS...