跳到主要内容

WooCommerce 扩展开发最佳实践

想创建一个插件来扩展 WooCommerce 吗？ 您来对地方了。

WooCommerce 扩展与普通的 WordPress 插件相同。 更多信息，请访问 撰写插件。

您的 WooCommerce 扩展应该：

  • 遵循所有 WordPress 插件的编码标准，以及 最佳实践指南，以确保在 WordPress 系统中与其他 WordPress 插件和谐共存。
  • 具有单一的核心功能，并尽可能地使用 WooCommerce 的功能。
  • 不做任何恶意、非法或不诚实的事情，例如，通过第三方系统插入垃圾链接或可执行代码，除非这些行为是服务的一部分或明确允许在服务的服务条款中。
  • 不应破坏或覆盖核心 Marketplace 的连接，例如，扩展程序不能创建带有品牌名称的顶级菜单项，也不能引入自己的遥测数据。
  • 遵循 WooCommerce 的 兼容性和互操作性指南。

商家每天都会使用 WooCommerce 扩展，他们应该在使用过程中获得统一且愉快的体验，而不会因为广告而干扰他们的 WP 管理界面或商店。

最佳实践​

  1. 检查 WooCommerce 是否已启用. 大多数 WooCommerce 插件只有在 WooCommerce 已经启用时才需要运行。 了解如何检查 WooCommerce 是否已启用。
  2. 主插件文件应采用插件的名称. 例如：一个目录名为 plugin-name 的插件，其主文件应命名为 plugin-name.php。
  3. 文本域名应与您的插件目录名称匹配. 例如：一个目录名为 plugin-name 的插件，其文本域名应为 plugin-name。 请勿使用下划线。
  4. 国际化: 遵循 WordPress 开发者国际化指南。
  5. 本地化: 插件代码中的所有文本字符串应使用英语。 这是 WordPress 的默认语言环境，英语始终应该是第一种语言。 如果您的插件面向特定市场（例如西班牙或意大利），请在您的插件包中包含适用于这些语言的翻译文件。 了解更多信息，请查看 使用 Makepot 翻译您的插件。
  6. 遵循 WordPress PHP 指南. WordPress 有一套 指南，旨在保持所有 WordPress 代码的一致性和易读性。 这包括引号、缩进、花括号样式、简短的 PHP 标签、Yoda 条件、命名约定等等。 请仔细阅读这些指南。
  7. 尽量避免创建自定义数据库表. 尽可能使用 WordPress 文章类型、分类法 和 选项。 更多信息，请查看我们的 数据存储入门指南。
  8. 防止数据泄露，确保您没有提供直接访问 PHP 文件的途径。 了解如何操作。
  9. 所有插件都需要一个标准的 WordPress README 文件。 请参考 WordPress 插件 README 文件标准 中的示例。
  10. 所有插件都需要一个变更日志文件。 请参考 变更日志文档 中的示例，了解变更日志文件以及不同类型的变更日志条目。
  11. 遵循我们插件头部注释的约定. 请参考我们的 WordPress 插件头部注释示例，并遵循其中列出的约定，包括：Author:、Author URI:、Developer:、Developer URI、WC requires at least:、WC tested up to: 和 Plugin URI:。
  12. 使其可扩展: 使用 WordPress 的动作和过滤器，允许进行修改/自定义。 如果您的插件生成前端输出，我们建议使用模板引擎，以便用户可以在其主题的 WooCommerce 文件夹中创建自定义模板文件，以覆盖插件的模板文件。 更多信息，请查看 Pippin 关于 使用动作和过滤器编写可扩展插件 的文章。
  13. 避免使用外部库. 通常不建议使用整个外部库，因为这可能会使产品存在安全漏洞。 如果绝对需要使用外部库，开发人员应仔细考虑所使用的代码，并承担代码的所有权和责任。 尽量只包含库中严格必要的部分，或者使用 WordPress 友好的版本，或者自行构建版本。 例如，如果需要使用文本编辑器，例如 TinyMCE，我们建议使用 WordPress 友好的版本 TinyMCE Advanced。
  14. 避免使用第三方系统: 允许从已记录的服务加载代码，但通信必须是安全的。 在插件中执行外部代码是不允许的。 禁止使用第三方 CDN 为与服务无关的 JavaScript 和 CSS 提供服务。 不应使用 iframe 连接管理页面。
  15. 删除未使用的代码. 使用版本控制时，没有理由留下注释掉的代码；它会让人感到不便。 删除它，如果需要，稍后可以重新添加。
  16. 使用注释 来描述您的代码的功能。 如果您有一个函数，该函数的作用是什么？ 您的代码中应该为大多数甚至所有函数都添加注释。 某人/您可能需要修改插件，而注释对于此非常有用。 我们建议使用类似于 WooCommerce 的 PHP 文档块。
  17. 避免使用“上帝对象”. 上帝对象 是指那些知道或执行过多事情的对象。 面向对象编程的目的是将一个大问题分解成更小的部分。 当函数执行过多操作时，很难理解其逻辑，这会使修复错误变得更加困难。 不要使用大型函数，而是将其分解成更小的部分。
  18. 分离业务逻辑和表示逻辑. 这是一个很好的实践，将业务逻辑（即插件的工作方式）与 表示逻辑（即插件的外观）分开。 两个独立的逻辑更容易维护和替换。 例如，可以有两个不同的类：一个用于显示最终结果，另一个用于管理页面设置。
  19. 使用瞬态对象存储外部信息. 如果您通过 API 提供服务，最好存储这些信息，以便将来的查询可以更快地完成，并且减轻对您服务的负载。 可以使用 WordPress 瞬态对象 来存储数据一段时间。
  20. 记录可以用于调试的数据, 但需要满足两个条件：允许任何日志记录作为“可选”功能，并使用 WC_Logger 类。 用户可以在其系统状态页面上查看日志。 了解 如何将链接添加到您的扩展中的已记录数据。
  21. 使用 WP_DEBUG 模式打开，以便在屏幕上显示所有 PHP 警告。 这将标记诸如确保在检查值之前设置变量之类的问题。
  22. 将 质量洞察工具包 (QIT) 集成到您的开发工作流程中: QIT 允许您同时测试您的扩展程序与 PHP、WooCommerce 和 WordPress 的新版本以及其他活动扩展程序。 此外，该工具包还包括一个 命令行界面 (CLI) 工具，允许您运行和查看针对开发构建的测试。 这有助于在发布新版本之前捕获错误。
  23. 切勿在您的扩展程序中使用内部 WooCommerce 代码. 命名空间为 Automattic\WooCommerce\Internal 的类以及带有 @internal 注释的代码仅供 WooCommerce 核心使用。 不保证内部代码的向后兼容性：它可能会在任何未来的版本中更改、重命名或删除。 在您的扩展程序中使用内部代码可能会导致在更新 WooCommerce 时出现问题。 请参阅 内部命名空间文档 了解详细信息。