問題描述

我一直在為 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 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。