問題描述

我一直在為 WordPress 開發外掛，我開發的大多數外掛都使用兩到三個類，因此不如 Buddypress 或 WooCommerce 那麼大。

我計劃開發兩個開源外掛來提供某種複雜的系統 (目前不能在開發過程中分享細節，而在開發過程中其他開發人員可以自定義功能)，而且系統需要與 Buddypress 和 WooCommerce 。

當我檢查這些外掛檔案，並意識到他們已經註冊了自己的操作和過濾器，開發人員可以根據需要進行修改。但是，我的問題是無法完全理解，我應該如何編寫一個外掛，其他人可以靈活地覆蓋函式以及新增自己的外掛。

我知道很難給出明確的答案，但我需要一些 start-up 指南，所以我可以走正確的方向。我需要註冊自己的操作和過濾器嗎？如果是的話？如果不是，我的選擇是什麼？

你的建議會幫助我很多… 謝謝

最佳解決方案

您在外掛或主題中提供的 API 取決於該特定程式碼的邏輯。可能沒有適用於所有情況的指南。

我是使用 API​​的多個外掛的貢獻者，到目前為止我學到了什麼：

  1. 在您真正瞭解使用者如何使用您的程式碼之前，不要提供 API 。釋出前兩個或三個版本沒有任何 API 。沒有自定義操作或過濾器，沒有公共方法或函式 (從來沒有任何全域性變數) 。等待使用者的請求，但不要新增程式碼，直到您知道內部程式碼結構將在長期執行為止。 Maintaining backwards compatibility of an API is hard 。這可能會阻止其他地方的改進。想想 WordPress 今天不能刪除的所有全域性變數。這是一個糟糕的 API，我們被困了很多年，因為人們 use it already 。

  2. 考慮將您的 API 與其他程式碼分開 (見上一個連結) 。您的 API 不僅對第三方開發人員有用，而且對您也是有用的。不要為自己新增限制，如果你不必。

  3. 吃你自己的狗食。如果您提供自定義掛鉤，請在程式碼中使用它們。這將為其他開發者提供有用的示例，您可以很快看到可能的缺陷。如果 WordPress 核心在內部使用 so-called Settings API，那麼今天我們就不會有這個混亂。也許。

  4. 以身作則。在外掛中使用 WordPress 核心 API 的很好的部分。避免使用 anonymous objects，常量，全域性變數和任何型別的不可預測的程式碼。

  5. 確保您使用一致的命名方案 (而不是 such a mess)，並將所有內容放在您自己的名稱空間下。

  6. 先寫檔案。稍後再釋出一個新的 (部分)API 。為所有內容建立有用的示例。你會驚奇地看到你會發現多少孔和冗餘。

  7. 避免回撥地獄。提供特定的工具來除錯您的 API，因為它們應該不起作用 (包括沒有精簡的指令碼和樣式表) 。我已經寫了一個如何 debug AJAX 的例子，只是為了說明你可以在這裡有多麼有創意。在釋放這些工具之前，請先在檔案中解釋這些工具。

  8. WordPress 的回撥悖論的另一種可能是 Observer pattern 。這將為 third-party 開發人員提供障礙，但可能導致雙方更好的程式碼。

參考文獻

注：本文內容整合自 Google/Baidu/Bing 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。