将 Gutenberg 的实验性 API 合并到 WordPress 核心中的做法可能很快就会结束。 一个新的 提议由 Automattic 赞助的贡献者 Adam Zielinski 发布，呼吁贡献者在将 API 合并到核心之前稳定它们。
多年来，从 Gutenberg 插件中合并了大约 280 个实验性 API，Zielinski 在 票 他在 4 月开始讨论这个问题。 在平衡快速移动的驱动力与迭代编辑器与 WordPress 对向后兼容性的承诺之间，实验性 API 的数量变得难以为继，现在正在积极重新考虑将它们合并到核心中的做法。
正式地，实验性 API 被标记为阻止第三方使用，因为它们预计会改变。 在实践中，为块编辑器构建的人无论如何都在使用它们，因为它们是核心，并且他们希望扩展这些 API 启用的功能。
“插件和主题作者被迫依赖 __experimental 功能，这些功能可能随时以向后不兼容的方式被删除或更改，”Zielinski 说，这与过去几年许多开发人员对该项目的沮丧和担忧相呼应。 “这是一个严重的维护负担。 每个新的 Gutenberg/WordPress 版本都意味着潜在的重大变化。”
WordPress 核心提交者 Peter Wilson 对这张票发表了评论，称他赞成将实验性 API 限制在最前沿的产品上。 开车回家需要这种改变，他 引用 这些核心实验性 API 对生态系统产生了许多负面影响：
- 核心提交者不愿意使用某些库特性来简化核心任务，因为他们不信任可靠性
- 开发人员不再升级 WP 客户端站点。 作为多年来一直努力保持向后兼容性的核心提交者，这让我感到失望。 作为安全团队成员，这非常令人担忧
- 开发人员决定在主题和插件中包含包的副本，而不是依赖 wp.* 全局变量。 从安全角度来看，这再次让我感到担忧，但它也大大增加了 JavaScript 有效负载，而不是保持向后兼容性
- 关于次要版本的向后兼容性中断的报告：“您不会期望 5.9.1 版本会破坏块编辑器之外我们网站中的一堆图像的响应能力”
- 开发人员考虑从不使用核心块，因为它们太不稳定：“我停止使用/扩展核心块，因为它们变化太多，我一直在使用 ACF 块，所以我至少知道我可以制作不会休息。 诚然 UI 不如核心方块好，但我会在任何时候破坏方块时保持稳定性。”
Gutenberg 插件旨在用作功能插件，其中预计会破坏向后兼容性，而贡献者会在将功能合并到核心之前对其进行润色。 回到这种方法的根源，减少编辑器的实验性，是这个提议的核心。
“版本之间的不稳定性已经开始疏远一些大块编辑器最大的外部拥护者，”威尔逊说。
保持这种程度的不稳定性可能会阻止人们在 WordPress 上进行构建，从而将他们推向以不同方式管理的其他更直接的项目。 依赖实验性 API 的需要可能会阻止开发人员构建更多产品，从而减缓块编辑器的采用。
“作为目前使用许多 __experimental API 的插件作者，我希望看到这些 API 稳定下来，”WP Engine 赞助的贡献者 Nick Diego 说。 “大多数提供关键功能，但构建依赖于 __experimental API 的产品总是有点令人不安。 只要这个过程非常透明，广为人知，并且我们为插件/主题作者提供了如何迁移到稳定版本的指南，那么我喜欢这个举措。”
经过几个月的讨论，Zielinski 将贡献者的担忧提炼到 Make WordPress Core 博客上提出的行动计划中。
该提案表明，大多数已经合并到核心中的现有实验性 API 将获得一个稳定的别名。
“它将保持向后兼容性，并且不会显着影响捆绑包的大小，”Zielinski 说。 “有些人需要不同的治疗； 让我们逐案讨论。” 他还建议贡献者考虑是否需要删除已经在核心中的现有实验性 API。 他预计不会出现很多这种情况，但建议使用联系插件作者、使用软弃用和发布核心帖子的既定做法。
“我在这里还看到了两件事：在 API 设计期间使用和滥用实验性 API（通常在 Gutenberg 插件中使用和测试）以及在满足设计标准时缺乏稳定它们的勤奋过程，”古腾堡首席建筑师马蒂亚斯文图拉 评论 在原票上。 “那些被认为是事实上的公众是那些已经以稳定的形式存在于许多版本中的那些，尽管它们有命名法。”
为了保持 WordPress 兑现其向后兼容性承诺的能力，该提案建议将实验性 API 限制在 Gutenberg 插件中，并且永远不要合并到核心中。 在稳定功能依赖于实验性 API 的情况下，Zielinski 确定了一个简单的答案：
“那么它实际上并不稳定。 让我们先稳定依赖关系。”
这本质上是一种新的前进方式，应该会增加对 WordPress 的 API 和更新的稳定性和信心，但它确实有一些缺点。
用户和贡献者可以预期 Gutenberg 功能可能会更慢地合并到核心中，因为当它们在主要版本中达到黄金时间分发时，他们不能依赖实验性 API。 Zielinski 还指出，一旦这些 API 交付并在数百万个 WordPress 网站上使用，贡献者也可能难以重构这些 API。
到目前为止，该提案已经获得了压倒性的积极支持，因为许多人认为这些 API 在仍处于试验阶段的时候，根本就不应该成为核心。
“我非常赞成这种方法，”WordPress 开发人员 Mark Root-Wiley 说。 “我构建了自定义主题并有一些简单的插件。 对于这两者，我发现自己经常被迫处理实验性 API，并且当核心功能被放入只能通过实验性 API 关闭、调整或扩展时，很难跟上它们的更新。”
WordPress 撰稿人 Dovid Levine 评论了该提案：“恢复这种核心稳定性将大大有助于重新获得一些开发者的善意。”
评论的截止日期 提议 是 9 月 7 日，这将在三周前结束讨论 WordPress 6.1 测试版 1 是期待。 这让贡献者有时间在下一个主要版本之前更深入地审核实验性 API，如果他们就将它们限制为 Gutenberg 插件达成共识。