产品更新指南和最佳实践

---

• 最佳实践
• 简而言 yǎnyin
• 为什么定期更新很重要
• 建议
• Marketplace 期望
• 推荐的更新频率
• 如何部署更新
• 上传新版本
• 格式化更新日志
• 常见错误
• 查看测试结果
• 编程方式上传新版本
• 生成应用程序密码
• 部署您的产品
• 检查部署状态
• 状态响应
• 通过自定义端到端测试最大化兼容性和可靠性
• 需要帮助？

---

为了维护一个高质量且具有竞争力的 Marketplace，我们鼓励所有供应商定期更新他们的产品。 持续的更新可以确保与 WooCommerce 和 WordPress 最新版本的兼容性，提高安全性、性能，并为客户提供持续的价值。

最佳实践

简而言 yǎnyin

• 至少每 6 个月更新一次您的产品。
• 与 WooCommerce 核心发布日历 保持一致。
• 使用诸如 质量洞察工具包 (QIT) 和您的 供应商仪表盘 等工具。
• 检查 功能请求门户 以获取产品创意。
• 定期更新 = 更好的客户信任度和续订率。

为什么定期更新很重要

• 兼容性: 确保您的产品与最新的 WooCommerce 和 WordPress 版本无缝协作。
• 安全性: 修复漏洞，并确保客户网站的安全。
• 性能: 提高速度、可靠性和效率。
• 客户信任: 建立对您的品牌和产品持久性的信心。 定期更新的产品通常具有更高的续订率。 每次更新都是提醒客户保持订阅价值的信号。
• 减少支持负担: 通过主动解决问题，减少支持工单的数量。

建议

1. 监控 WooCommerce 发布日历: 预测可能影响您产品的更改。
2. 收集客户反馈: 利用评论、支持工单和功能请求来改进产品，添加新功能，并解决社区提出的改进建议。
3. 使用语义版本控制: 示例：v2.1.0 用于新增功能，v3.0.0 用于重大更改。
4. 彻底测试: 确保更新稳定且尽可能具有向后兼容性。 考虑将 质量洞察工具 (QIT) 集成到您的工作流程中，以自动检测潜在问题。
5. 透明地记录更改: 维护清晰、面向客户的变更日志，如有必要，更新文档和产品页面。

Marketplace 期望

未能跟上 WooCommerce 核心版本或未至少每六个月更新一次的产品将被 标记为从 WooCommerce Marketplace 中移除。

推荐的更新频率

• 主要版本: 至少每季度，以与 WooCommerce 核心版本 保持一致。
• 安全修复: 视情况而定，并应尽快进行。
• 次要改进: 每月或在功能和修复准备就绪时。
• 文档: 确保变更日志和用户指南与每个版本保持同步。

如何部署更新

上传新版本

在上传您扩展的新版本之前，重要的是确保它通过所有 QIT 质量标准。 您可以通过点击 质量洞察 菜单选项，从您的供应商仪表盘运行这些检查。

了解更多关于 QIT 测试以及如何运行它们.

在您的扩展通过所有 QIT 检查后，您可以上传更新的版本。

点击 版本 选项卡。 您将看到您之前上传的所有版本，以及每个版本的主要变化说明。

点击 添加版本 按钮，然后：

1. 选择您想要上传的 .zip 文件，从您的计算机中选择。
2. 添加版本号。
3. 点击 提交新版本。

提交后，我们将对上传的文件运行以下测试：

• 端到端 (E2E)
• 激活
• 安全
• Woo API
• PHP 兼容性
• 恶意软件

所有供应商管理员将在整个过程中收到邮件通知，包括：

• 确认: 当提交新版本时，供应商管理员将收到一封电子邮件，确认该版本已排队。 无需采取任何操作。
• 已拒绝: 如果某个版本未能通过任何自动测试，供应商管理员将收到一封包含具体错误的电子邮件。 开发者应尝试解决该错误，并在准备好时提交新版本。
• 已发布: 如果某个版本通过了自动测试，它将自动部署并对客户可用。 无需采取任何操作。

激活、安全和恶意软件测试的通过是新产品版本部署的必要条件。

格式化更新日志

了解更多关于更新日志格式和条目类型.

常见错误

如果上传失败，您应该首先检查以下几个常见错误：

• 文件名: WooCommerce.com 查找您 .zip 文件的特定名称以及其中的主文件夹名称。 当您尝试上传产品时，您将看到预期的名称：

• 存在更新日志: 必须存在一个名为 changelog.txt 的文件，用作记录版本之间的更改。
• 无效的更新日志: 提供的 changelog.txt 文件不符合预期的格式。
• 版本头信息不匹配: 扩展头信息中的版本号与上传过程中提供版本号不匹配。
• 版本号不匹配: 扩展头信息中的版本号和 changelog.txt 中的版本号不匹配。

查看测试结果

自动化测试的结果将显示在 提交测试 表格中，可以通过点击相应的 查看 链接来查看，如以下图片所示：

编程方式上传新版本

要以编程方式部署扩展，必须是扩展的更新，而不是新的提交。 这种方法是另一种替代方案，可以避免登录到供应商仪表盘，并使用用户界面 (UI) 执行相同的操作。

生成应用程序密码

1. 确保您已登录到 WooCommerce 供应商仪表盘。
2. 创建应用程序密码。

:::note 为了提高安全性，此应用程序密码仅限于部署端点，不能用于代表用户执行任何其他操作。 :::

部署您的产品

向以下 URL 发送 POST 请求，以部署您的产品，使用以下命令：

curl -X POST https://woocommerce.com/wp-json/wc/submission/runner/v1/product/deploy \
  -F "file=@/path/to/zip" \
  -F "product_id=<product_id>" \
  -F "username=<username>" \
  -F "password=<app_password>" \
  -F "version=<product_version>"

将 <product_id>, <username>, <app_password> 和 <product_version> 替换为您的实际产品 ID、用户名、应用程序密码和产品版本。

检查部署状态

要检查部署状态，请使用以下命令：

curl -X POST https://woocommerce.com/wp-json/wc/submission/runner/v1/product/deploy/status \
  -F "product_id=<product_id>" \
  -F "username=<username>" \
  -F "password=<app_password>"

状态响应

当您查询部署状态时，响应将提供有关进度的详细信息，包括各种测试运行的状态。

以下是响应的示例：

{
  "status": "queued",
  "version": "1.0.0",
  "test_runs": {
    "12345": {
      "test_run_id": "12345",
      "status": "success",
      "test_type": "activation",
      "result_url": "https://qit.woo.com/?qit_results=12345"
    },
    "67890": {
      "test_run_id": "67890",
      "status": "success",
      "test_type": "api",
      "result_url": "https://qit.woo.com/?qit_results=67890"
    }
  }
}

注意: 响应中可能包含其他测试运行对象，每个已执行的测试类型对应一个对象。

通过自定义端到端测试最大化兼容性和可靠性

我们强烈鼓励您为基于 QIT 的 自定义端到端测试框架 构建的扩展贡献端到端测试。通过与我们分享这些测试，您在确保不同 WordPress 和 WooCommerce 版本、各种 PHP 环境以及其他流行的扩展之间的真正兼容性方面发挥着至关重要的作用。

我们的自定义端到端测试框架配备了 Docker 化的开发环境和易于使用的命令工具，使您能够设计和执行全面的测试，这些测试使用 Playwright，并且针对您的扩展的独特功能进行定制。

这项举措不仅有助于在潜在的兼容性问题影响用户之前进行缓解，还提高了我们市场中产品的整体可靠性。参与此过程不仅有助于构建一个强大的生态系统，还可以提升您扩展的质量和可靠性声誉。

请查看我们的 QIT 自定义测试文档，以开始利用自定义测试的力量，以确保您的扩展在真实场景中能够无缝运行，并在竞争激烈的市场中脱颖而出。

需要帮助？

如果您需要关于更新计划、QIT 帮助或部署问题的支持，请随时联系 Marketplace 团队。

让我们共同努力，使 WooCommerce.com Marketplace 保持创新、安全和可靠，惠及所有人！