WordPress 後台自訂文章列表介面
有時候在想每個禮拜寫的這些文章，不乏一些 WordPress 官方文件裡面有的函式或類別，關於它們的使用方法可以直接去翻文件，或是請 ChatGPT 解釋甚至舉出實際範例絕對比我寫出來的東西要清楚 N 倍，那麼我的寫作價值何在？
首先是不管是翻文件還是問小雀，都不會有圖片的說明，很多時候我用了這段程式碼它到底是影響哪些地方，這些在文件上只能用文字來理解，真實狀況還是要寫了之後才知道，有時候寫出來後才發現跟我所認知的結果不一樣，因此我的文章有圖說來增加閱讀者的理解力。
其次是文件寫的內容著重在單一的功能，該如何運用這些函式於實際的工作之中，需要靠的是經驗的累積，而也是因為這些踩雷的經驗讓我知道原來這個地方不能用 A 函式而要用 B，或是可以 A+B 做組合技，雖然小雀也能問到組合技，但你還是要自行確認它有沒有在喇叭，我寫的文章是人為確認過可以運作的內容。
最後是這些寫過的內容裡面提到的程式碼我都會存成程式碼片段以利未來使用，尤其是經過整理消化過的能加深自己的印象，要再利用它修改成其他功能也會很方便。
以上三點是我覺得寫文章的價值，而這些價值不管 AI 發展的多強大，甚至如果哪天它可以產出圖文並茂的教學文都不會讓我懷疑我是否該停筆，熱愛畫畫的人不會因為 AI 能產圖就不畫，作家不會因為小雀會產字就不寫，找到自己的價值就能用不一樣的視野來看待這個工具。
WordPress 後台自訂文章列表介面
 |
WordPress 後台內建的文章列表除了是使用者非常熟悉的操作介面外，更是擁有許多方便實用的功能，但由於該介面是提供給 Post 專用的顯示列表，如果今天是我們自行新增的資料內容而非 Custom Post Type 的時候，預設的文章列表介面就無法使用。
遇到這樣的情況就只有兩種方式可以處理，第一個是建立空白的 Option Page 手刻前端介面，除了表格樣式要自行設計外，還有分頁、篩選、項目顯示設定等功能都需要自己實作，處理起來會花上不少時間。
第二種方法是可以採用 WordPress 內建的類別 WP_List_Table 來處理，透過繼承的方式覆寫相關的方法，可以很快的完成文章列表，我在開發 WooCommerce 推播通知外掛的時候，就是使用這個作法來顯示自訂資料表的內容，這樣做的好處是除了節省手刻的時間外，還能維持統一的使用體驗。
由於 WP_List_Table 有非常多的屬性與方法，這邊我們先專注在以下幾個目標：
- 顯示特定自訂資料表格的內容
- 根據資料時間篩選出當週的內容
- 指定欄位排序
- 資料單筆/批次刪除
- 分頁導覽
- 新增列表頁選單
要注意的是這邊只有實作內容列表的顯示與刪除，如果需要能夠編輯內容則要另外處理編輯頁面，這部分留待下次再來處理。
自訂文章列表介面的邏輯是新增一個繼承 WP_List_Table 的子類別，然後再加入後台選單呼叫該子類別來顯示表格，下面在介紹子類別的寫法時我會先以完成的截圖說明，但要記得在還沒有註冊選單呼叫子類別前都是看不到的。
1. 顯示特定自訂資料表格的內容
在 WP_List_Table 中最關鍵的方法是用來準備資料內容的 prepare_items() 方法，該方法需要將資料存進 $item 屬性，而這屬性就是內容列表，基本架構如下（文長慎入）：
https://oberonlai.blog/wordpress-list-table/
-
這禮拜沒料到這個主題會寫這麼長，抬頭看時鐘已經寫了六個小時，還有兩個預計要寫的主題等下次再分享了。然後我下週要去花蓮放風三天，下週停刊一週，我們下下週見吧～
WordPress 開發日常
多巴胺（Dopamine）是一種神經傳遞物質，負責傳遞興奮和愉悅感。能引起渴望、興奮和希望等情緒，激勵人們追求目標。 上週日感冒了，很久沒有這麼嚴重的大感冒，發燒加喉嚨、頭爆炸痛，連續幾個晚上都沒什麼睡，白天完全沒有體力上工，不是在睡覺就是在發呆放空，受不了最後還是看了醫生吃了藥，每天等著症狀好轉。 到了週三稍微有點精神可以看書，看完「流言終結者」主持人亞當的書「創客精神」後一整個被激勵，很想要來動手做些什麼，於是拿出筆記本把一些點子畫下來，我想到可以做一個平台來搜集大家使用 Vibe Coding 開發出來的作品： 由於還沒有體力坐在電腦前工作，我就想說用平板先來做個雛形看看，付費解鎖了 Claude，也試了 Replit、Firebase Studio 來玩看看，很快的就有網站原型，再從這個原型去發想更多的功能細節。 第一次的衝擊 隔天因為需要回一些工作的訊息就開了電腦，想説回完後就關機繼續休息，結果想說把昨天弄的原型用 Cursor 來重做一次，能夠直接自己修改程式碼還是比較安心，但我忽然靈光一閃，我不是想要讓自己投入到 Vibe Coding...
原本努力了一個半月的新產品眼看就要正式釋出了，但在請了幾位客戶幫忙測試後，毅然決然暫停開發，主因是新產品有一些致命且短期無法解決的問題，再加上收入模式不明確，繼續開發下去會把自己推入險境中。 反而是請客戶試用的過程中，收到不少新功能的建議，考量到要顧好既有客戶以及營收狀況，還是決定先以既有產品的擴充功能為主，把營收站穩後再來另開戰場。 工作佔比 五月份總工作時數為 66.98 小時，比四月增加了 1.34 小時。各類工作佔比如下： 行銷：14% 產品更新：38% 產品研發：48% 這個月從下半月開始，全面採用 Vibe Coding 模式開發，在離開電腦前下好指令，回來後再驗收成果，一開始覺得很爽快，有一種人不在電腦前還是有進度的錯覺，尤其是在寫新外掛的雛形時很快就能獲得一些成果。 但如果寫流程比較多的功能，在驗收時就會開始感受到混亂，像是引用錯參考資料或是沒有遵循設計模式，一個檔案超過 500 行是家常便飯，事後反而要花時間在釐清甚至重新整理它的寫法，這部分我覺得應該可以透過提示詞來慢慢跟它磨合，就像以前跟朋友一起合作開發一樣，需要把相關的事項溝通清楚。 行銷 內容行銷...
最近常用 AI 產生程式碼，結果一堆程式自己都看不懂，只有錯誤發生時才會回頭研究到底寫了什麼。想說乾脆寫篇文章記錄一下，當作學習筆記。本篇主題是 OpenAI API 與 WordPress 的整合，讓 AI 能直接操作 WordPress。 初探工具請求（Function calling） 像 GPT 這類自然語言模型是靠訓練資料回應問題，但資料若過時，或想取得即時資訊，模型本身無法處理。這時可以透過「工具請求（Function calling）」來解決。 原理是：先告訴 AI 有哪些工具可用，當對話中出現相關需求，AI 就能自動判斷是否要使用某個工具。這些工具可以是 WordPress 的函式（如 WP_Query 查文章），也可以是外部 API（例如 Google 搜尋），執行後把結果再交給 AI 處理並產出回應，自然語言化地回答使用者。 適用場景 1. 整合客服機器人 如果你想設計聊天介面給其他人使用，像是客服機器人外掛，就很適合採用這個技術來取得網站內的資訊，像是讓客人查詢商品、訂單相關資訊、搜尋產品使用說明文件，或是讓管理員查詢營業額、網站瀏覽數據。...