​

隨著 ChatGPT 的火熱，在工作時我也開始導入使用它查詢程式碼，很多常用但一直記不住的 WordPress 寫法直接問它真的超快，像是根據 User ID 取得 / 更新會員資料、訂單或商品的 Query 迴圈、PHP 或 JS 的操縱陣列的方法等等。

以往都要去查手冊或是 Stackoverflow，萬一沒有提供我需要的範例，可能就要自己修修改改，但有了 ChatGPT 就像是多了一位助理工程師一樣，任何程式碼的範例只要問的夠具體，它都可以寫出正確的答案，就算答錯還可以糾正它讓它變得更好，有時候它還會教我一些我不知道的用法，身為知識工作者我覺得 AI 是不可獲缺的利器，它能讓我們省下時間專注更重要的事。

然而 AI 的創作也正在發生，用它來產生的內容越來愈多，不管內容的正確與否，只是為了單純獲得更多曝光，都讓我憂慮在資訊爆炸的年代，有了 AI 只會出現更多假資訊、假消息，而隨著 AI 的運算能力提升，訊息的真假一定會越來越難分辨，到最後我們人類只能靠 AI 來判斷 AI 的真偽。

另外在用 ChatGPT 的當下我就在想現在只能問它問題，不知道有沒有辦法叫它幫我做一些事，像是請它查商品庫存然後直接幫我下單，或是當我收到帶有特定關鍵字的信件時，自動寄出一封它寫好的回覆郵件，結果這禮拜就喵到 Toolformer 的新聞，當 AI 可以自行根據產出的文字執行一些行為的時候，整個軟體產業一定會有天翻地覆的改變。

這不禁讓我思考人的學習量再怎麼大也不可能比 AI 多，當 AI 擁有全人類的知識後，我們剩下的是什麼？過去的經驗？對於事物的感知？創造的價值？我沒有答案，現在的我只知道可以靠 AI 進行更有效的學習，就像我這禮拜靠 ChatGPT 總算搞懂如何開發 WordPress 區塊了XD

一、突破 WordPress 區塊開發的困境

之前我一直卡在不知道該如何引入區塊的主要 JS 檔，研究了老半天整理出以下的脈絡：

主要 JS 有四種引入方式：

1. 在 init hook 時用 register_block_type，使用參數 editor_script 引入主要 JS
2. 在 init hook 時用 register_block_type，然後引入 block.json，把主要 JS 的路徑寫在裡面
3. 在 init hook 時用 register_block_type，然後引入帶有 block.json 的目錄，把主要 JS 的路徑寫在裡面，通常一個區塊就是一個目錄，裡面含 block.json、主要 JS 以及 SCSS
4. 在 enqueue_block_assets hook 用 wp_enqueue_script 來引入主要 JS

至於要用哪種方法會關係到前端打包工具 build 的方式，由於大部分的教學都是用官方的套件 @wordpres/create-block 建立一個全新的外掛，而我想要的是整合在既有的外掛之中，因此被目錄結構這件事搞得很暈，因為還要考量到 PHP 的 Autoload。

最後我的目錄設計如下：

assets 是所有前端檔案，不會被 PHP 的 Autoload 給載入，然後 src 是原始碼，為了區別非區塊的前端檔案，我多開了一個 blocks 資料夾來放，然後 dist 是透過 wpackio 編譯後的檔案，處理 JSX、Babel、SCSS 的轉譯，同時有 hot reload 的功能，所以理論上我只要取得 wpackio 編譯後的 JS 然後用上面四種方法的其中一個載入即可。

由於實際路徑必須透過 wpackio 的 PHP 動態產生，因此方法二跟三寫在 block.json 裡面的方法就行不通，只剩下一跟四，由於 wpackio 有一個封裝 wp_enqueue_script 的 class，因此我選擇方法四。

需要注意的是參數 js_dep ，就跟 wp_enqeue_script 的依賴套件一樣，這邊必須要引入 block 相關的 package 後在 JS 裡面才能去 import，但我推測直接用 npm 安裝應該也行，之後有時間我再補上比較完整的說明，具體程式碼如下：https://oberonlai.blog/wordpress-block-editor/​

二、前臺顯示 ACF 的設定頁面

這禮拜做到一個需求是要讓 ACF 的設定頁面可以在前台顯示，印象中有看過過獨立的外掛在做，但查了之後發現 ACF 內建的函式就可以處理，只要先在 Header 引入 ACF 必須的前端檔案後，就能用 acf_form() 來顯示表單。

首先先用勾點 wp_head 將載入 ACF 資源的函式 acf_form_head() 掛進去，它的順序要比 get_header() 前面，其次用 acf_form() 帶入所需的設定欄位，需要傳入的參數有：

• post_id ⇒ 自訂欄位的所在頁面 ID，由於我的欄位做成全站設定，因此這邊帶入的是 options
• field_groups ⇒自訂欄位的 post_id，也可以傳欄位的 key 值，該參數接受陣列，因此可以傳多個自訂欄位進去
• submit_value ⇒ 送出按鈕的文字
• post_title ⇒ 前台表單的標題

具體程式碼如下：https://oberonlai.blog/acf-form/​

三、如何修改既有 WordPress 外掛的流程思考

常遇到讀者來信問說該如何知道要修改外掛功能時該用哪個勾點，坦白說我也不知道，只能靠著經驗跟 Google 來找，但常常也會卡關就是了，於是我試著紀錄自己在找線索時的思考方向與步驟，作為除錯時的一個參考。

我的情境是這樣：客戶發現課程外掛 LearnDash 在顧客送出訂單後且訂單狀態變更為處理中時，顧客就能看到課程內容，但有些付款方式當訂單處理中時事實上還沒付款完成，因此造成顧客還沒付錢就能看到課程內容，為了要修改這問題我的思路如下：

1. 先從資料庫裡面查紀錄使用者課程開通的欄位叫什麼
2. 從程式碼裡面去找寫入該欄位的函式寫在哪邊
3. 但發現程式碼太大不容易爬
4. 於是換個方向，先測試是在哪幾種訂單狀態會開通
5. 找到只有在訂單狀態為完成、處理中時會開通
6. 找到訂單變成取消時會移除開通權限
7. 發現該功能寫在 LearnDash 的擴充 learndash-woocommerce
8. 使用 VSCode 開啟該擴功的資料夾進行搜索
9. 搜尋關鍵字 processing、completed 或是 hook
10. 發現在勾點 woocommerce_order_status_processing 有觸發 add_course_access() 的方法
11. 找到後思考該如何不動到原始碼的情況下進行修改
12. 發現到移除課程觀看權限的方法是 remove_course_access()

所以我最後的解法是在勾點 woocommerce_order_status_processing 的地方多呼叫一次 remove_course_access()，就能確保當訂單狀態變為處理中時能移除課程權限：

​https://oberonlai.blog/wordpress-plugin-thinking/​

短短三行程式碼中間的思考過程也是滿長的，如果真要請 ChatGPT 協助我縮短這個研究的過程還真不知道該如何下手XD

-

希望你我都能學會如何使用 AI 這樣強大的工具，而不是反過來被 AI 利用，我們下週見！