Juliet Reedus Fulmer 发布提案以允许 WordPress按固定时间表删除对旧 PHP 版本的支持。在 WordPress 联合创始人兼项目负责人 Matt Mullenweg 伸出手讨论解决方案后，她写了这份提案。这是他上周关闭 Train Ticket 的时候，试图放弃对 PHP 5.6 的支持，并将今年下一个主要 WordPress 版本的最低版本提高到 7.1。
此提案提出了 WordPress 社区中许多人可能支持的立场。这是通往平台未来 PHP 支持的清晰、透明的路径。
在他的提案中，Vollmer 基本上列出了两个路线图。第一个路线图确定 WordPress 将在哪个阶段放弃对特定 PHP 版本的支持。该平台将在每年 12 月停止对超过五年的 PHP 次要版本的支持。这将与任何即将发布的 WordPress 主要版本同步。以下时间表列出了每年支持的最低 PHP 版本：
- 2020 年 12 月 – PHP 7.1
- 2021 年 12 月 – PHP 7.2
- 2022 年 12 月 – PHP 7.3
- 2023 年 12 月 – PHP 7.4
- 2024 年 12 月 – PHP 8.0
提案编号。第二部分创建向后移植安全更新的滚动计划到 WordPress。目前，WordPress 从 3.7 分支一路发布安全更新。如果采纳，Folmer 的提议将只支持 WordPress 发布的前四年。
此更改意味着当 WordPress 5.6 于 2020 年 12 月发布时，WordPress 项目将致力于向后移植安全修复程序，最早可追溯到 2016 年 12 月发布的 WordPress 4.7。
Folmer 还建议将 PHP 升级通知从 Site Health 项目反向移植到当前支持的旧版 WordPress。此措施将在用户跳转到较新版本的 WordPress 之前通知用户 PHP 版本问题。
将最小 PHP 支持推向未来和向后移植安全修复的重叠为用户提供了一个巨大的窗口，可能长达九年，以继续使用他们当前使用的 PHP 的任何版本。九年来，日新月异的技术仿佛是网络的一生，这在一些人的帖子评论中引起了争论。然而，这是一个行动计划，WordPress 社区对 PHP 支持并没有太大的兴趣。开发人员无疑会为日期和版本讨价还价，但这仅次于实际可预测的时间表。
欢迎使用 Project Bump 的固定版本。它让每个人都在同一页面上，从开发人员到最终用户，再到网络主机。如果我们要在不重新讨论相同论点的情况下继续前进，这种透明度是必要的。
等待查看特定 PHP 版本的使用率何时下降到特定百分比以下的系统只会让事情变得混乱。结果通常是冗长的争论，不会动弹不得。双方选择自己的数据。扎根于四面八方。每一方都有很多优势。最终，每个人都希望拥有相同的东西——推动整个项目向前发展并使用最新的工具。然而，他们总是不同意我们是如何到达那里的。最终，最低 PHP 版本受到挑战，社区为下一轮做准备。那些想要更快进步的人和那些不想让用户落后的人之间一直在进行斗争。
事实是，没有人在这些观点上是完全正确的。没有可遵循的路线图。除了“以前有人做过”之外，我们没有其他指导原则。
WordPress 需要设定明确的期望。
这不仅仅是最低 PHP 版本的问题——许多人想要整个项目的更详细的路线图。然而，对 PHP 的最低支持是我们可能需要解决的一个问题领域，Folmer 已经开辟了一条道路。我们只需要跟随它。
喜欢这样：
喜欢正在加载...
资源
