PHP 8.2 弃用动态属性，这对 WordPress、插件和开发人员意味着什么？

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

动态属性已被弃用，并且会在 PHP 9 或可能的 PHP 10 中抛出致命错误 。虽然这可能会很痛苦 - 特别是对于 WordPress 核心 - 弃用是一个关键功能，也是 PHP 给开发人员的礼物。

让我们看一下 PHP 的最新发展，以及 WordPress 开发人员如何保持向后兼容性，同时在新功能对最终用户最有利时利用新功能。 Php 8 2 发布

及时了解 WordPress 中的 PHP 开发

WordPress 公司必须确定自己的产品或服务生命周期以及他们将支持的 PHP 版本。

与至少需要 PHP 7.4 的 WooCommerce 不同，WordPress 核心目前仅建议 PHP 7.4 或更高版本。它还适用于 PHP 5.6.20，该版本已于 2018 年底到期。 WordPress 项目注意到了这一点，并警告使用不受支持的 PHP 版本“可能会使您的网站面临安全漏洞”。 （需要 WordPress.org）

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

不幸的是，PHP 7.4 刚刚在 2022 年 11 月底结束了其 EOL 日期。在 2023 年的大部分时间里，PHP 8.0 将在不到一年的时间内获得官方安全支持。目前积极支持的版本 PHP 8.1 将于 2024 年底弃用，而刚刚发布第一个稳定版本的 PHP 8.2 将在 2025 年 12 月之前提供安全支持。

这是一个快速的发布周期，而且没有任何问题。令人惊讶的是 WordPress 生态系统正在努力跟上它的步伐。由于超过一半的网络都在 WordPress 上运行，因此它是一艘无法快速调转的大船。这更多的是一种平衡行为，而不是争先恐后。然而，跃迁到 PHP 8 有很多好处，它提供了强大的性能改进，例如运行时的即时 (JIT) PHP 编译，可以加快执行速度并减少内存消耗。

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

迎合尽可能广泛的用户群和保持 PHP 的流行之间的权衡一直是 WordPress 开发人员、托管和产品公司面临的难题困境。拥有长期客户和旧网站的机构和自由职业者面临着同样的问题：更新最低要求可能会迫使现有客户对其网站进行重大更改或导致网站瘫痪。

一方面，使用 PHP 的好处是提高安全性和性能，并为开发人员提供最新的编程概念和功能。另一方面，推迟 PHP 最低要求的主要好处是快乐（尽管自满）和广泛的客户群。这是“现在付款或稍后付款”。在某些时候，你必须撕掉补丁。

有关用户环境的良好数据和遥测可以帮助确定提高最低 PHP 版本要求所需的最短停机时间。大多数插件开发人员使用自己的工具来关注这些数字，因为它不是 WordPress.org 插件存储库的活动安装数据的一部分。任何影响很多人的潜在重大变化都不可避免地会导致大量支持选票。

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

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

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

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

从版本 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 的明文密码被破解之际，首次将无密码登录引入 WordPress 作为主要的用户身份验证体验。

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

对于在古腾堡块编辑器上投入巨资的 WordPress 产品（例如 GiveWP），管理更改可能更具挑战性。 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 兼容性而构建的新主要版本。

弃用通知推动开发前进

WordPress.com 刚刚推出了 PHP 8.2 作为其业务和电子商务计划的一个选项，启用了托管功能，并且在 WordPress.org 生态系统中，精心设计的遗留代码更少在下一个 PHP 主要版本中发布时可能会损坏或变得不安全。尽管 WordPress.org 核心代码库官方仅提供对 PHP 8.0 的“测试版”支持，但它通常可以与最新版本的 PHP 配合良好，支持良好的插件也是如此。它们不会抛出致命错误或解析错误。打开调试后，您甚至不会看到很多警告。您可能会看到许多已弃用的功能消息，但它们还不是错误。

快速 PHP 发布周期带来的挫败感与开发人员陷入困境、重构代码并追赶 PHP 过时的方面有很大关系。这项关键工作可以让他们花更少的时间探索和创新最新 PHP 版本的新概念和功能。

还有另一种看待这种情况的方式。处理 PHP 中已弃用的功能实际上是积极主动的，并迫使开发人员熟练掌握不断发展的语言的下一次迭代。如果没有这种强迫性的练习，现有的知识很容易养成旧习惯，一旦过时就会变成坏习惯。

弃用通知表示现在有效但在 PHP 的未来版本中不再可用的内容。正如 Brent Roose 所解释的，如果您是一名开发人员，这对您有好处。如果开发人员关注这些消息，他们将有足够的时间来处理任何过时的代码。而且它不应该成为小版本更新的障碍。

iThemes 安全首席开发人员兼 WordPress 核心提交者 Timothy Jacobs 表示，拥有弃用警告是一件好事。它们促使开发人员接受“更正确”和“不那么疯狂”的代码，这些代码将变得越来越安全、高性能、防错，并且能够更好地处理边缘情况。在此视图中，E_DEPRECATED 消息填充您的错误日志，“作为早期警告系统，表明将来会发生错误，但现在不会发生。”

PHP 8.2 之后不再使用动态属性

Nikita Popov 在 PHP 9 中弃用动态属性的基本原理是 PHP 向更具弹性的编码和编程约定发展的一个很好的例子：

进行此更改的动机是双重的：防止常见情况下发生错误（由于拼写错误或重命名），并明确预期用途。核心问题是，读取不存在的属性会发出诊断，使问题立即显现出来，而写入不存在的属性则完全无声。 PHP 没有给出任何迹象表明程序员犯了错误。

Brent Roose 关于 PHP 5.6 到 8.2 演变的两分钟视频是 PHP 从 2014 年至今朝这个方向演变的精彩而简单的视觉说明。 Roose 使用一个简单的数据传输对象示例，展示了 PHP 5.6 版本如何显着简化为更简单、更精简且通常更优雅的代码块。

正如 Roose 在处理动态属性的提示（在 PHP 8.2 中已弃用）中指出的那样，开发人员应该有足够的自由度来更新现有代码，以免弃用警告变成致命错误。然而，这条跑道很快就会消失，WordPress 是一个特例。 Tonya Mork 在 Trac 中有一项已被接受的提案，用于处理 WordPress 核心中的未知动态属性打印。她和 Juliette Reinders Folmer 担心 WordPress 开发人员没有足够的时间来重构他们的代码，更不用说维护一个 20 年历史的项目的前向兼容性所面临的独特挑战了。莫克、雷德斯·福尔默和谢尔盖·比留科夫基本上是这项艰巨任务的无名英雄。

在讨论 PHP 8.2 中的动态属性和魔术方法时，Mork 和 Reinders Folmer 指出 WordPress 植根于 PHP 3 和 4，使其牢牢地处于过程编程的世界中，而 PHP 作为面向对象的语言继续发展。正如 Reinders Folmer 所说，核心开发人员必须找到一种方法来维护当今 PHP 中遗留代码的行为，同时又不破坏向后兼容性，“并且仍然使代码更好、更安全，并减轻 PHP 8.2 动态功能的弃用”。 “[WordPress Core] 没有[向后兼容性]，从而违反了规则，实际上我们的生活变得非常困难，”她在视频中指出。

“这是有充分理由的，”Mork 回答道 - “这是为了用户。用户相信他们可以按下按钮并升级，我们已经考虑了向后兼容性，我们已将其作为优先事项。这是我们的基石...让用户可以放心升级。”

所有开发都是维护...

为了保持 WordPress 核心内的向后兼容性，尝试向后移植“现代”PHP 来使用。使用 PHP 的两个先前主要版本提出了独特的挑战。插件开发人员可以利用新功能（例如 PHP 8.2 的只读类和动态属性的弃用）更轻松地更新其代码。这项工作的大部分也是维护的一种形式。

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

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

将代码维护为受支持的 PHP 版本标准的最佳原因是降低安全风险。在 Adams 看来，PHP 8.2 带来了有用的便利和“保障”，但很少让程序员兴奋或被认为是游戏规则改变者。像 #[\SensitiveParameter] 属性这样的属性可能更方便，因为它允许从经常进入第三方服务的堆栈跟踪中过滤敏感数据。 PHP 8 中引入的属性是 Adams 指出的最后一项引起他注意的创新，因为它实现了以前无法完成的事情：“从元角度描述某些内容 [例如类、变量、方法等] 。”

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

...所有维护都是艺术

Jeff Atwood 有一篇古老但优秀的博客文章，标题为“维护编程的崇高艺术”，感谢 Kale Davis 的黑客通讯，我最近读到了这篇文章。 “维护编程被广泛视为一项清洁工作，”他写道。这让我想起了艺术家 Mirele Laderman Ukeles，他的《维护艺术宣言》一直让我印象深刻，因为它与编程和 Web 开发非常相关：

两个基本系统：开发和维护。每次革命的酸球：谁在革命后的周一早上捡垃圾？ […]开发系统是部分反馈系统，有很大的改变空间。维护系统是一个直接反馈系统，几乎没有变化的空间。

1969 年，年轻的艺术家兼新妈妈 Laderman Ukeles 撰写了宣言，宣称维护是艺术。她对如何将尖端艺术作品与高地位作品结合起来的愿景对与使这一切成为可能的工作分离感到沮丧：抚养孩子、教授艺术技能和传统，或者只是组织艺术展览。她以博物馆看门人的身份举办了一场令人难忘的展览。然后，她（正在进行的）职业生涯的大部分时间都作为纽约市卫生局的驻场艺术家度过。她担任该职位的第一个项目是亲自感谢所有“让纽约保持活力”的所有 8,500 名环卫工人。贬低维护工作是错误的。罗伯特·L·格拉斯 (Robert L. Glass) 认为“维护是一项伟大的智力工作。一个挑战，但也是一个解决方案，不是问题”，因此对于最熟练的人来说，这应该被视为一项重要任务。Joel Spolsky 写得太长了，因为开发人员很懒，“总是想要扔掉代码并重新开始的原因”是“阅读代码更难”

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

Atwood 最终倾向于这种观点，但也呼应了我从 Jason Adams 和 Timothy Jacobs 那里听到的常见 WordPress 开发者观点。 WordPress 开发/维护的特殊艺术？

“这是一种平衡行为。 ”