PHP 8.2 和 WordPress 兼容性问题

作者：WP 网站构建指南

PHP 8.2.0 于 2022 年 12 月 8 日首次亮相。作为重大更新，它带来了性能改进和更简单的语法。 PHP 8.2 引入了更多类型安全功能，如独立类型 null、false 和 true。给 WordPress 开发人员带来挑战的最大变化之一是添加了 只读 类，该类不允许使用动态属性。

动态属性已被弃用，并会在 PHP 9 或可能的 PHP 10 中导致致命错误。虽然这可能会很痛苦（尤其是对于 WordPress 核心而言），但摊销是一项核心功能，也是 PHP 送给开发人员的礼物。

让我们来看看PHP和WordPress的最新发展。 WordPress 开发人员如何保持向后兼容性，同时利用有利于最终用户的新功能？这是两个开源项目之间关系的一个关键主题。

WordPress 核心保持了显着的向后兼容性，当不再支持旧版本时，没有计划的生命周期结束日期。由于向后兼容性非常重要，因此 WordPress 公司必须定义自己的产品或服务生命周期。他们支持哪些 PHP 版本？

与WooCommerce 相比，至少需要 PHP 7.4，WordPress 核心目前仅建议 PHP 7.4 或更高版本。它还与 PHP 5.6.20“兼容”，该版本已于 2018 年底结束生命周期。 WordPress 项目注意到了这一点，并警告使用不受支持的 PHP 版本“可能会使您的网站面临漏洞”。 （http://WordPress.org 要求）

幸运的是，目前只有 5.1% 的 WordPress 网站使用 PHP 5.6，只有 2% 使用旧版本。 20% 使用 PHP 7.0 到 7.3，其中最大群体 (56.7%) 使用 PHP 7.4。 （http://WordPress.org 统计）

PHP 7.4 已经结束了一年多的生命周期，并且已经到了 2023 年的大部分时间。目前积极支持的 PHP 8.1 版本将于今年年底弃用。 2024 PHP 8.2 刚刚发布了第一个稳定版本，提供安全支持直至 2025 年 12 月。

这是一个快速的发布周期，WordPress 生态系统必须跟上它也就不足为奇了。大约一半的互联网运行在 WordPress 上，这是一艘无法快速调转的大船。这更多的是一种平衡行为，而不是争先恐后。 PHP 8 有很多优点。有一些强大的性能改进，例如运行时的即时 (JIT) PHP 编译，从而实现更快的执行速度和更低的内存使用量。

向后兼容性和稳定性、前瞻性思维和创新之间的权衡

我们应该服务尽可能广泛的用户群还是保持 PHP 的流行？这个问题一直是 WordPress 开发者、托管和产品公司面临的困境。没有单一的正确答案。所有的决定都是妥协。

拥有长期客户和旧网站的代理机构和自由职业者也面临着同样的问题。他们应该更新 PHP 最低要求吗？这可能会迫使现有客户对其网站进行重大更改或导致网站崩溃。

一方面，跟上 PHP 的步伐可以提高安全性和性能。最新的编程概念和功能对于向 WordPress 插件添加新功能的开发人员来说非常有价值。另一方面，推出最低要求的 PHP 版本将取悦广泛的客户群。然而，稳定在某些时候可能会变得自满和过时。

这是现在付款或稍后付款的情况。最后，您需要满足并更新 PHP 的最低要求。

遥测可以告诉您何时面对。

软件产品的每一次重大变更都会导致大量的支持请求。有关用户环境的良好数据和遥测可以帮助确定提高最低 PHP 版本要求的最小干扰程度。这就是为什么插件所有者需要了解用户的 PHP 版本部署。

http://WordPress.org 跟踪每个 WordPress 站点使用的 PHP 版本。 WordPress 插件的情况并非如此。开发人员必须使用自己的工具来收集这些数字。

优先考虑向后兼容性需要大量维护。支持非常庞大且多样化的用户群对于最终用户来说非常有用，但这意味着开发人员必须使他们的代码在许多不同的环境中工作。“我喜欢支持旧版本的 PHP，同时添加新功能”，没有开发人员说过！

他们不仅需要担心旧版 PHP，还需要担心旧版数据库和 WordPress 堆栈的许多其他变体。当大型 WordPress 服务器环境中包含过时的元素时，可能会出现边缘情况，甚至会让专家感到困惑。

提高 PHP 最低要求的最佳时机

iThemes Security Pro 7.2 版本是提高 WordPress 产品 PHP 最低要求的一个很好的例子，以便为现有客户提供更新和稳定性。

案例研究：iThemes Security Pro

从版本 7.2 开始，iThemes Security Pro 需要 PHP 7.3 或更高版本，最高支持版本 8.1。 iThemes Security Pro 团队决定更新他们的 PHP 要求以实施 WebAuthn 框架。该实现需要 PHP 7.3+ 库来进行加密和公钥管理。 iThemes Security Pro 7.2 中引入的 2FA、密码和生物识别登录功能就是这一决定的直接结果。在密码遭到黑客攻击的时候，iThemes 安全团队首次在 WordPress 中引入无密码登录作为主要的用户身份验证体验。

通过重写 WebAuthn 库以与旧版本的 PHP 兼容，可以将这些新功能内置到 iThemes Security Pro 中。当然，这需要更多的工作并创建额外的代码来维护。通过引入需要 PHP 7.3 或更高版本的依赖项来跟上 PHP 社区的步伐是明智的。他们的大多数用户已经在那里。因此，iThemes 安全开发团队决定提高新用户和现有用户的最低 PHP 要求。

案例研究：GiveWP

对于在古腾堡块编辑器（如 GiveWP）上投入大量资金的 WordPress 产品，变更管理可能会更加困难。 WordPress 核心的稳定性和缓慢的变化速度可能会让后端 PHP 开发人员感到沮丧，但它允许前端 JavaScript/React 开发人员推动平台向前发展。 GiveWP 的开发经理 Jason Adams 指出，它们不需要向后兼容，因为随着网站编辑器的发展，它们可以在版本之间迁移用户。然而，“不存在 PHP 迁移这样的事情，”他评论道。最后，他们必须适应 PHP 9 架构并放弃 PHP 8.2 新弃用的功能。

在 WordPress 生态系统中，没有合适的时间来更新每个产品的 PHP 最低要求。 “这不是一个可以从哲学上解决的问题，”亚当斯说。这实际上取决于审判的时间。这会对多少用户产生负面影响？如果 90% 或更多使用 PHP 7.2 或 7.4，则将最低要求提高到该水平是可行的。

Adams 表示，根据产品的特定用户群，这些数字可能会有很大差异。技术成熟的客户通常使用更接近当前支持的 PHP 版本的产品。像 GiveWP 这样被许多非营利组织使用的产品需要更认真地考虑向后兼容性。另一种选择是在受支持但不添加新功能的长期版本中使用遗留代码。当用户准备好升级时，他们可以升级到专为未来 PHP 兼容性而设计的新主要版本。

折旧通知推动开发

http://WordPress.com 刚刚在其业务和电子商务计划中推出了 PHP 8.2，并在 http://WordPress.org 生态系统中激活了托管功能，在该生态系统中，设计的遗留代码会被破坏或变成当主要的 PHP 版本发布时，接下来不太可能出现不安全的情况。尽管 WordPress.org 核心代码库仅正式提供对 PHP 8.0 的测试版支持，但它通常可以很好地与最新版本的 PHP 配合使用，支持良好的插件也是如此。它们不会导致致命错误或解析错误。打开调试后，您甚至不会看到很多警告。您可能会看到许多已弃用的功能通知，但它们还不是错误。

对快速 PHP 发布周期的挫败感与开发人员陷入重构代码和寻找过时 PHP 功能的修复有很大关系。这项关键工作可以让他们花更少的时间研究和更新最新 PHP 版本附带的概念和功能。

PHP 8.2 后已弃用动态属性

Nikita Popov 在 PHP 9 中逐步淘汰动态属性的原因是 PHP 如何转向更具弹性的代码和编程实践的一个很好的例子：

此更改的动机是双重的：防止常见情况下的错误（由于拼写错误或重命名）并阐明预期用途。主要问题是，读取不存在的属性可以进行诊断，使问题立即显现出来，而写入不存在的属性则完全无声。此时，PHP 并不知道程序员犯了错误。

优雅代码的不断演变之美

Brent Roose 关于 PHP 5.6 到 8.2 演变的 2 分钟视频以精彩而简单的视觉方式解释了 PHP 从 2014 年至今的演变。 Roose 使用一个简单的数据传输对象示例，展示了如何在 PHP 8.2 的过程中将 PHP 5.6 代码简化为更简单且通常更优雅的代码片段。

正如 Roose 在处理动态属性的提示（在 PHP 8.2 中已弃用）中指出的那样，在弃用警告变成致命错误之前，开发人员应该有足够的时间来更新现有代码。不过，这个轨迹很快就会消失，WordPress 是一个特例。 Tonya Mork 的一项提案被 Traci 接受，旨在解决 WordPress 核心中未知动态属性的折旧问题。他和 Juliette Reinders Folmer 担心 WordPress 开发人员没有足够的时间重新编写代码。对于一个已有 20 年历史的项目来说，保持向前和向后兼容性所面临的独特挑战不容忽视。莫克、雷德斯·福尔默和谢尔盖·比尔尤科夫基本上是这项艰巨任务的无名英雄。

WordPress 核心如何跟上 PHP 的步伐并保持向后兼容性

在讨论 PHP 8.2 的动态功能和神奇方法时，Mork 和 Reinders Folmer 指出，WordPress 植根于 PHP 3 和 4，使其在 PHP 的世界中根深蒂固。与过程式编程相比，PHP 不断发展成为一种面向对象的语言。正如 Reinders Folmer 所说，核心开发人员必须找到一种方法来保留现代 PHP 中的遗留代码行为，同时又不破坏向后兼容性，“并且仍然使代码更好、更安全，并减轻 PHP 8.2 动态功能的弃用”。 。 “[WordPress Core] 违反了规则，因为它没有 [向后兼容性]，而我们实际上让我们的生活变得非常困难，”他在视频中指出。

“这是有充分理由的，”莫克回答道。 “这是为了用户。用户有信心他们可以按下按钮并进行更新，我们已经考虑了向后兼容性，我们已经优先考虑了这一点。”这是我们让用户放心升级的基石。 “

所有开发都是维护......

为了保持 WordPress 核心的向后兼容性，向后移植“现代”PHP 以与之前的两个主要 PHP 版本一起使用是一个独特的挑战。插件开发人员可以利用 PHP 8.2 readonly 类和动态属性弃用等新功能更轻松地更新代码。这项工作的大部分内容也主要是

在架构上，PHP 8+ 中的变化集中在诸如不变性之类的编程概念上。根据 Jacobs 的说法，不可变的数据结构“本质上并不能解决安全问题”，但它确实可以帮助开发人员使他们的代码更不容易出错并且更正确：

我不会说不可变的数据结构本质上是安全的并且可变数据结构则不然。相反，不可变的数据结构有助于消除可能导致编程错误的问题。通过减少代码可以存在的不同状态的数量，我们可以降低代码的复杂性，从而减少出错的机会。

正确的代码可能更安全

在积极支持下维护代码 PHP 版本标准的最佳论点是降低安全风险。 Adams 表示，PHP 8.2 提供了有用的“保障措施”，但很少让程序员兴奋或被视为游戏规则的改变者。诸如 之类的东西 #[\SensitiveParameter] 属性可能更实用，因为它允许从经常发送到第三方服务的堆栈跟踪中过滤敏感数据。 PHP 8 中引入的属性是 Adams 的最后一个创新，它引起了他的注意，因为它允许以前无法完成的事情：“在元视角中描述某些东西（例如类、变量、方法等）”。

PHP 8.0 – 利用 8.2 和未来版本中的新功能是开发人员发挥创造力的地方，但简单地支持这些版本以便插件和 WordPress 核心不会破坏它们是实用且重要的。

...所有维护都是一门艺术

Jeff Atwood 有一篇古老但很棒的博客文章，标题为“维护编程的崇高艺术”，我最近通过 Kale Davis 的黑客通讯读到了这篇文章。“维护编程被广泛认为是清理工作， “阿特伍德写道。这让我想起了艺术家 Mirele Laderman Ukele，他的《维护艺术宣言》在编程和 Web 开发方面似乎一直与我非常相关：

“谁在周一早上捡垃圾？”

1969 年，Laderman Ukeles 是一位年轻的艺术家，也是一位新妈妈，当时她写下了宣言，宣称“关爱就是艺术”。他对我们将尖端艺术作品与使它们成为可能的高地位劳动力的作品分开的方式感到沮丧。养育孩子、教书或者举办艺术展览都是艺术家所做的事情，但不被视为他们工作的一部分。为了解释这一点，拉德曼·尤克莱斯（Laderman Ukeles）举办了一场幽灵般的展览，重点展示了他作为艺术博物馆馆长的角色。然后，他在纽约市卫生部担任驻场艺术家，度过了他（正在进行的）职业生涯的大部分时间。他上任后的第一个项目就是亲自感谢所有 8,500 名环卫工人，正是他们让纽约市充满活力。

Atwood 对编程也有类似的看法。他引用了软件工程领域几位知名人士的话说，诋毁维护是完全错误的。罗伯特·L·格拉斯 (Robert L. Glass) 认为，“维护是一项重大的智力挑战，是一种解决方案，而不是一个问题”，因此应该被视为最熟练技术人员的一项重要任务。 Joel Spolsky 很早以前就写道，开发人员很懒，他们“总是想扔掉代码并重新开始”的原因是“阅读代码比编写代码更难”。

“所有编程都是维护编程”

在与 Andy Hunt 的对话中，Dave Thomas 表示，“所有编程都是维护编程，因为你很少编写原始代码。 ...你大部分时间都花在写作上。它处于维护模式。所以你不妨硬着头皮说：“我从第一天起就一直在做维护。适用于维护的纪律应该是通用的。”Hunt 表示同意：“当你第一次编写代码时，前 10 分钟只是原始代码。就是这样。”

Atwood 最终倾向于这种观点，但与我从 Jason Adams 和 Timothy Jacobs 那里听到的常见 WordPress 开发人员观点相呼应。

WordPress 开发/维护的特殊艺术？“这是一种平衡行为。”