47 lines
No EOL
8.5 KiB
Markdown
47 lines
No EOL
8.5 KiB
Markdown
---
|
||
post_title: WooCommerce extension development best practices
|
||
sidebar_label: Best practices
|
||
sidebar_position: 3
|
||
---
|
||
|
||
# WooCommerce 扩展开发最佳实践
|
||
|
||
想创建一个插件来扩展 WooCommerce 吗？ 您来对地方了。
|
||
|
||
WooCommerce 扩展与普通的 WordPress 插件相同。 更多信息，请访问 [撰写插件](https://developer.wordpress.org/plugins/)。
|
||
|
||
您的 WooCommerce 扩展应该：
|
||
|
||
- 遵循所有 WordPress 插件的编码标准，以及 [最佳实践指南](https://developer.wordpress.org/plugins/plugin-basics/best-practices/)，以确保在 WordPress 系统中与其他 WordPress 插件和谐共存。
|
||
- 具有单一的核心功能，并尽可能地使用 WooCommerce 的功能。
|
||
- 不做任何恶意、非法或不诚实的事情，例如，通过第三方系统插入垃圾链接或可执行代码，除非这些行为是服务的一部分或明确允许在服务的服务条款中。
|
||
- 不应破坏或覆盖核心 Marketplace 的连接，例如，扩展程序不能创建带有品牌名称的顶级菜单项，也不能引入自己的遥测数据。
|
||
- 遵循 WooCommerce 的 [兼容性和互操作性指南](https://woocommerce.com/document/marketplace-overview/#section-9)。
|
||
|
||
商家每天都会使用 WooCommerce 扩展，他们应该在使用过程中获得统一且愉快的体验，而不会因为广告而干扰他们的 WP 管理界面或商店。
|
||
|
||
## 最佳实践
|
||
|
||
1. **检查 WooCommerce 是否已启用**. 大多数 WooCommerce 插件只有在 WooCommerce 已经启用时才需要运行。 [了解如何检查 WooCommerce 是否已启用](/docs/extensions/core-concepts/check-if-woo-is-active)。
|
||
2. **主插件文件应采用插件的名称**. 例如：一个目录名为 `plugin-name` 的插件，其主文件应命名为 `plugin-name.php`。
|
||
3. **文本域名应与您的插件目录名称匹配**. 例如：一个目录名为 `plugin-name` 的插件，其文本域名应为 `plugin-name`。 请勿使用下划线。
|
||
4. **国际化**: 遵循 [WordPress 开发者国际化指南](https://codex.wordpress.org/I18n_for_WordPress_Developers)。
|
||
5. **本地化**: 插件代码中的所有文本字符串应使用英语。 这是 WordPress 的默认语言环境，英语始终应该是第一种语言。 如果您的插件面向特定市场（例如西班牙或意大利），请在您的插件包中包含适用于这些语言的翻译文件。 了解更多信息，请查看 [使用 Makepot 翻译您的插件](https://codex.wordpress.org/I18n_for_WordPress_Developers#Translating_Plugins_and_Themes)。
|
||
6. **遵循 WordPress PHP 指南**. WordPress 有一套 [指南](http://make.wordpress.org/core/handbook/coding-standards/php/)，旨在保持所有 WordPress 代码的一致性和易读性。 这包括引号、缩进、花括号样式、简短的 PHP 标签、Yoda 条件、命名约定等等。 请仔细阅读这些指南。
|
||
7. **尽量避免创建自定义数据库表**. 尽可能使用 WordPress [文章类型](http://codex.wordpress.org/Post_Types#Custom_Post_Types)、[分类法](http://codex.wordpress.org/Taxonomies) 和 [选项](http://codex.wordpress.org/Creating_Options_Pages)。 更多信息，请查看我们的 [数据存储入门指南](/docs/best-practices/data-management/data-storage)。
|
||
8. **防止数据泄露**，确保您没有提供直接访问 PHP 文件的途径。 [了解如何操作](/docs/best-practices/security/prevent-data-leaks)。
|
||
9. **所有插件都需要一个标准的 WordPress README 文件**。 请参考 [WordPress 插件 README 文件标准](https://wordpress.org/plugins/readme.txt) 中的示例。
|
||
10. **所有插件都需要一个变更日志文件**。 请参考 [变更日志文档](/docs/extensions/core-concepts/changelog-txt) 中的示例，了解变更日志文件以及不同类型的变更日志条目。
|
||
11. **遵循我们插件头部注释的约定**. 请参考我们的 [WordPress 插件头部注释示例](/docs/extensions/core-concepts/example-header-plugin-comment)，并遵循其中列出的约定，包括：`Author:`、`Author URI:`、`Developer:`、`Developer URI`、`WC requires at least:`、`WC tested up to:` 和 `Plugin URI:`。
|
||
12. **使其可扩展**: 使用 WordPress 的动作和过滤器，允许进行修改/自定义。 如果您的插件生成前端输出，我们建议使用模板引擎，以便用户可以在其主题的 WooCommerce 文件夹中创建自定义模板文件，以覆盖插件的模板文件。 更多信息，请查看 Pippin 关于 [使用动作和过滤器编写可扩展插件](http://code.tutsplus.com/tutorials/writing-extensible-plugins-with-actions-and-filters--wp-26759) 的文章。
|
||
13. **避免使用外部库**. 通常不建议使用整个外部库，因为这可能会使产品存在安全漏洞。 如果绝对需要使用外部库，开发人员应仔细考虑所使用的代码，并承担代码的所有权和责任。 尽量只包含库中严格必要的部分，或者使用 WordPress 友好的版本，或者自行构建版本。 例如，如果需要使用文本编辑器，例如 TinyMCE，我们建议使用 WordPress 友好的版本 TinyMCE Advanced。
|
||
14. **避免使用第三方系统**: 允许从已记录的服务加载代码，但通信必须是安全的。 在插件中执行外部代码是不允许的。 禁止使用第三方 CDN 为与服务无关的 JavaScript 和 CSS 提供服务。 不应使用 iframe 连接管理页面。
|
||
15. **删除未使用的代码**. 使用版本控制时，没有理由留下注释掉的代码；它会让人感到不便。 删除它，如果需要，稍后可以重新添加。
|
||
16. **使用注释** 来描述您的代码的功能。 如果您有一个函数，该函数的作用是什么？ 您的代码中应该为大多数甚至所有函数都添加注释。 某人/您可能需要修改插件，而注释对于此非常有用。 我们建议使用类似于 [WooCommerce](https://github.com/woocommerce/woocommerce/) 的 [PHP 文档块](http://en.wikipedia.org/wiki/PHPDoc)。
|
||
17. **避免使用“上帝对象”**. [上帝对象](http://en.wikipedia.org/wiki/God_object) 是指那些知道或执行过多事情的对象。 面向对象编程的目的是将一个大问题分解成更小的部分。 当函数执行过多操作时，很难理解其逻辑，这会使修复错误变得更加困难。 不要使用大型函数，而是将其分解成更小的部分。
|
||
18. **分离业务逻辑和表示逻辑**. 这是一个很好的实践，将业务逻辑（即插件的工作方式）与 [表示逻辑](http://en.wikipedia.org/wiki/Presentation_logic)（即插件的外观）分开。 两个独立的逻辑更容易维护和替换。 例如，可以有两个不同的类：一个用于显示最终结果，另一个用于管理页面设置。
|
||
19. **使用瞬态对象存储外部信息**. 如果您通过 API 提供服务，最好存储这些信息，以便将来的查询可以更快地完成，并且减轻对您服务的负载。 可以使用 [WordPress 瞬态对象](http://codex.wordpress.org/Transients_API) 来存储数据一段时间。
|
||
20. **记录可以用于调试的数据**, 但需要满足两个条件：允许任何日志记录作为“可选”功能，并使用 [WC_Logger](https://woocommerce.com/wc-apidocs/class-WC_Logger.html) 类。 用户可以在其系统状态页面上查看日志。 了解 [如何将链接添加到您的扩展中的已记录数据](/docs/code-snippets/link-to-logged-data)。
|
||
21. **使用 [WP_DEBUG](http://codex.wordpress.org/Debugging_in_WordPress) 模式打开**，以便在屏幕上显示所有 PHP 警告。 这将标记诸如确保在检查值之前设置变量之类的问题。
|
||
22. **将 [质量洞察工具包 (QIT)](https://qit.woo.com/docs/) 集成到您的开发工作流程中**: QIT 允许您同时测试您的扩展程序与 PHP、WooCommerce 和 WordPress 的新版本以及其他活动扩展程序。 此外，该工具包还包括一个 [命令行界面 (CLI) 工具](https://qit.woo.com/docs/installation-setup/cli-installation)，允许您运行和查看针对开发构建的测试。 这有助于在发布新版本之前捕获错误。
|
||
23. **切勿在您的扩展程序中使用内部 WooCommerce 代码**. 命名空间为 `Automattic\WooCommerce\Internal` 的类以及带有 `@internal` 注释的代码仅供 WooCommerce 核心使用。 **不保证内部代码的向后兼容性**：它可能会在任何未来的版本中更改、重命名或删除。 在您的扩展程序中使用内部代码可能会导致在更新 WooCommerce 时出现问题。 请参阅 [内部命名空间文档](https://github.com/woocommerce/woocommerce/blob/trunk/plugins/woocommerce/src/Internal/README.md) 了解详细信息。 |
