开发 WordPress 插件时的经验教训

每个 WordPress 插件开发人员都在与难以维护的棘手问题和代码作斗争。 当升级破坏我们的插件时，我们会在深夜为我们的用户提供支持并撕毁我们的头发。 让我告诉你如何使它更容易。

在本文中，我将分享我五年开发 WordPress 插件的经验。 我写的第一个插件是一个简单的营销插件。 它显示了一个带有 Google 搜索短语的号召性用语 (CTA) 按钮。 从那时起，我又编写了 11 个免费插件，并且我维护了几乎所有的插件。 我已经为我的客户编写了大约 40 个插件，从非常小的插件到现在已经维护了一年多的插件。

良好的开发和支持会带来更多的下载。 更多的下载意味着更多的钱和更好的声誉。 本文将向您展示我学到的教训和犯过的错误，以便您改进插件开发。

1. 解决问题

如果您的插件不能解决问题，则不会下载。 就这么简单。

使用 Advanced Cron Manager 插件（超过 8,000 次活动安装）。 它可以帮助难以调试 cron 的 WordPress 用户。 该插件是出于需要而编写的——我需要一些东西来帮助自己。 我不需要推销这个，因为人们已经需要它了。 它搔了他们的痒。

另一方面，有一个 Bug — fly on the screen 插件（70 多个活动安装）。 它随机模拟屏幕上的苍蝇。 它并没有真正解决问题，所以它不会有大量的观众。 不过，这是一个有趣的插件开发。

专注于一个问题。 当人们看不到他们的 SEO 表现不佳时，他们会安装一个 SEO 插件。 当人们想要加速他们的网站时，他们会安装一个缓存插件。 当人们找不到他们的问题的解决方案时，他们就会找到一个为他们编写解决方案的开发人员。

正如 David Hehenberger 在他关于编写成功插件的文章中所证明的那样，需求是 WordPress 用户决定是否安装特定插件的关键因素。

如果您有机会解决某人的问题，请抓住机会。

2. 支持您的产品

“五分之三的美国人会尝试新品牌或新公司以获得更好的服务体验。 十分之七的人表示他们愿意在他们认为提供优质服务的公司上花更多的钱。”

— 尼基耶格尔

不要忽视你的支持。 不要把它当作必须的，而更像是一个机会。

高质量的支持对于您的插件发展至关重要。 即使是具有最佳代码的插件也会获得一些支持票。 使用您的插件的人越多，您获得的门票就越多。 更好的用户体验会让你获得更少的票，但你永远不会到达收件箱 0。

每次有人在支持论坛上发布消息时，我都会立即收到电子邮件通知，我会尽快回复。 它得到了回报。 由于支持，我获得了绝大多数好评。 这是一个副作用：良好的支持通常会转化为 5 星评价。

当您提供出色的支持时，人们开始信任您和您的产品。 插件是一种产品，即使它是完全免费和开源的。

良好的支持比每天写一个简短的答案更复杂。 当您的插件获得关注时，您每天将获得几张门票。 如果您主动并在客户提出问题之前回答他们的问题，则管理起来会容易得多。

以下是您可以采取的一些操作的列表：

• 在您的存储库中创建一个常见问题解答部分。
• 将“在您询问之前”主题固定在您的支持论坛顶部，突出显示故障排除提示和常见问题解答。
• 确保您的插件易于使用，并且用户知道他们在安装后应该做什么。 用户体验很重要。
• 分析支持问题并解决痛点。 设立一个委员会，人们可以在其中投票选出他们想要的功能。
• 创建一个展示插件如何工作的视频，并将其添加到 WordPress.org 存储库中插件的主页。

您使用什么软件来支持您的产品并不重要。 WordPress.org 的官方支持论坛与电子邮件或您自己的支持系统一样有效。 我使用 WordPress.org 的论坛获取免费插件，使用我自己的系统获取高级插件。

3. 不要使用 Composer

Composer 是包管理器软件。 软件包存储库托管在 packagist.org 上，您可以轻松地将它们下载到您的项目中。 它就像 PHP 的 NPM 或 Bower。 以 Composer 的方式管理第三方包是一种很好的做法，但不要在 WordPress 项目中使用它。

我知道，我丢了一颗炸弹。 让我解释。

Composer 是一款很棒的软件。 我自己使用它，但不在公共 WordPress 项目中使用。 问题在于冲突。 WordPress 没有任何全局包管理器，因此每个插件都必须加载自己的依赖项。 当两个插件加载相同的依赖项时，会导致致命错误。

这个问题并没有真正理想的解决方案，但 Composer 使情况变得更糟。 您可以手动将依赖项捆绑到源中，并始终检查您是否可以安全地加载它。

Composer 与 WordPress 插件有关的问题仍未解决，并且在不久的将来不会有任何可行的解决方案来解决这个问题。 这个问题是多年前提出的，正如您在 WP Tavern 的文章中看到的那样，许多开发人员都在尝试解决它，但没有任何运气。

您可以做的最好的事情是确保条件和环境适合运行您的代码。

4、合理支持PHP老版本

不支持非常旧的 PHP 版本，例如 5.2。 安全问题和维护不值得，而且您不会从这些旧版本中获得更多安装。

使用 PHP 5.6 作为最低要求，尽管官方支持将在 2018 年底之前停止。WordPress 本身需要 PHP 7.2。

有一种运动不鼓励对旧 PHP 版本的支持。 Yoast 团队发布了 Whip 库，您可以将其包含在您的插件中，并向您的用户显示有关他们的 PHP 版本以及他们应该升级的原因的重要信息。

告诉您的用户您支持哪些版本，并确保他们的网站在您的插件安装到过低版本后不会中断。

5. 关注质量代码

一开始编写好的代码很困难。 学习“SOLID”原则和设计模式并改变旧的编码习惯需要时间。

曾经我花了三天时间在 WordPress 中显示一个简单的字符串，当时我决定使用更好的编码实践重写我的一个插件。 知道它应该花费 30 分钟，这令人沮丧。 改变我的心态很痛苦，但值得。

为什么这么难？ 因为你开始编写一开始看起来有点矫枉过正而且不是很直观的代码。 我一直在问自己，“这真的需要吗？” 例如，您必须将逻辑分成不同的类，并确保每个类负责单一的事情。 您还必须为翻译、自定义帖子类型注册、资产管理、表单处理程序等分离类。然后，您可以从简单的小对象中组合出更大的结构。 这称为依赖注入。 这与拥有所有代码的“前端”和“管理”类非常不同。

另一个违反直觉的做法是将所有操作和过滤器保留在构造函数方法之外。 这样，您在创建对象时不会调用任何操作，这对单元测试非常有帮助。 您还可以更好地控制执行哪些方法以及何时执行。 我希望我在编写一个由构造函数方法中的操作引起的无限循环的项目之前知道这一点。 这些类型的错误很难追踪，也很难修复。 该项目必须重构。

以上只是一些示例，但您应该了解 SOLID 原则。 这些对任何系统和任何编码语言都有效。

当您遵循所有最佳实践时，您就会达到每个新功能都适合的地步。您无需调整任何内容或对现有代码进行任何例外处理。 太奇妙了。 您的代码不会变得更复杂，而是会变得更高级，而不会失去灵活性。

此外，正确格式化您的代码，并确保团队中的每个成员都遵循标准。 标准将使您的代码可预测并且更易于阅读和测试。 WordPress 有自己的标准，您可以在项目中实施。

6. 提前测试你的插件

我以艰难的方式吸取了这一教训。 缺乏测试导致我发布了一个带有致命错误的插件的新版本。 两次。 两次，我都获得了 1 星评级，但我无法将其转化为正面评价。

您可以手动或自动测试。 Travis CI 是与 GitHub 集成的持续测试产品。 我为我的 Notification 插件构建了一个非常简单的测试套件，它只检查插件是否可以在每个 PHP 版本上正确启动。 这样，我可以确定插件是没有错误的，而且我不必太注意在每个环境中测试它。

每个自动化测试只需要几分之一秒。 完成 100 个自动化测试大约需要 10 分钟，而手动测试每个案例大约需要 2 分钟。

您在预先测试插件上投入的时间越多，从长远来看，它为您节省的时间就越多。

要开始自动化测试，您可以使用 WP-CLI \\`wp scaffold plugin-test\\` 命令，它会安装您需要的所有配置。

7. 记录你的工作

开发人员不喜欢编写文档是陈词滥调。 这是开发过程中最无聊的部分，但有一点可以走很长的路。

编写自记录代码。 注意变量、函数和类名。 不要制作任何复杂的结构，例如不易阅读的级联。

记录代码的另一种方法是使用“文档块”，它是每个文件、函数和类的注释。 如果你写了函数的工作原理和作用，那么六个月后你需要调试它时会更容易理解。 WordPress 编码标准通过强制您编写文档块来涵盖这一部分。

使用这两种技术将节省您编写文档的时间，但并不是每个人都可以阅读代码文档。

对于最终用户，您必须撰写高质量、简短且易于阅读的文章，解释系统的工作原理和使用方法。 视频更好； 许多人更喜欢看一个简短的教程而不是阅读一篇文章。 他们不会看代码，所以让他们的生活更轻松。 良好的文档还可以减少支持票。

结论

这七项规则帮助我开发了优质产品，这些产品开始成为 BracketSpace 的核心业务。 我希望他们也能在您使用 WordPress 插件的过程中为您提供帮助。

在评论中让我知道您的黄金开发规则是什么，或者您是否发现上述任何一项特别有用。