问题描述

我一直在为 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 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。