WP LinkedIn Auto Share 外掛 — 編譯摘要

濃縮

1. 解決「簡單但重複」問題的最佳方案是自動化，而非忍耐：手動貼連結到 LinkedIn 很簡單，但重複一百次就值得投入開發一支外掛來自動化。
2. 輕量單一職責的外掛優於大而全的方案：市面上有 Jetpack Social、Buffer 等選擇，但對只需要 LinkedIn 同步的人來說太重。整支外掛只有一個 PHP 檔案，無前端建置、無 Composer 依賴。
3. Gutenberg 的 Meta Box 時序是 WordPress 外掛開發的已知陷阱：Meta box 資料在 REST API 完成發布之後才送出（透過 iframe），需要雙重觸發機制搭配防重複才能正確運作。

質疑

結論 1：自動化 vs. 忍耐

• 前提假設：文章發布頻率夠高（日更或週更）。如果一個月才發一篇，手動操作的成本幾乎為零。
• 反例：使用 Zapier/Make 等 no-code 自動化工具可能比開發外掛更快完成同樣的事。

結論 2：輕量單一職責

• 前提假設：需求真的只有 LinkedIn 同步。但社群經營通常是多平台的，未來可能需要擴充到 X、Threads 等。
• 邊界條件：LinkedIn Access Token 60 天過期需要手動更新，長期維護成本不為零。

結論 3：Gutenberg Meta Box 時序陷阱

• 前提假設：使用 Gutenberg 編輯器。經典編輯器沒有這個問題，但使用者正在減少。
• 換場景：任何依賴 WordPress REST API 的外掛都可能遇到類似的時序問題。

對標

1. 重複 100 次 → 自動化 ↔ DevOps 的自動化門檻法則：「做第三次就自動化」的原則在運維和內容發布中同樣適用。
2. 單一職責外掛 ↔ Unix 哲學：「做好一件事」的設計原則跨越了作業系統和 WordPress 生態。
3. Gutenberg 時序陷阱 ↔ 前後端分離的副作用：當編輯器（前端）和資料儲存（後端）非同步，時序問題是必然的。

關聯概念

• [[WordPress 外掛開發實踐]]
• [[自動化決策門檻]]
• [[單一職責原則]]
• [[Gutenberg 開發陷阱]]
• [[WordPress 生態系統]]