PHP 8.2.0 于 2022 年 12 月 8 日首次亮相。作为一项重大更新，它带来了性能改进、更简单的语法和更高的类型安全性，并将null、false和true作为独立类型。可能挑战 WordPress 开发人员的最大变化之一是引入了只读类，它不允许使用动态属性（Dynamic properties）。
动态属性已被弃用，并将在 PHP 9 或可能的 PHP 10 中产生致命错误。虽然可能会很痛苦——尤其是对于 WordPress 核心——弃用是一个关键特性，也是 PHP 送给开发人员的礼物。
让我们看一下 PHP 的最新发展，以及 WordPress 开发人员如何保持向后兼容性，同时在新功能对最终用户最有利的时候利用它们。
跟上 WordPress 中的 PHP 开发
由于 WordPress 核心保持显着的向后兼容性，在不支持旧版本时没有计划的生命周期结束日期，因此 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 日期。PHP 8.0 在 2023 年的大部分时间里提供官方安全支持的时间还不到一年。当前受到积极支持的版本 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，作为主要的用户身份验证体验。
可以通过重写 WebAuthn 库以与旧版本的 PHP 兼容来构建这些功能。当然，这将需要更多的工作并创建额外的代码来维护。明智的做法是以适度的速度跟上 PHP 社区的步伐，采用需要 PHP 7.3 或更高版本的依赖项。他们的大多数用户已经在那里。这就是 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 年历史的项目的向前兼容性的特殊挑战了。Mork、Reinders Folmer 和 Sergey Biryukov 基本上是这项艰巨任务的无名英雄。
在讨论PHP 8.2 中的动态属性和魔法方法时，Mork 和 Reinders Folmer 指出，WordPress 在 PHP 3 和 4 中的根源使其保持在一个稳固的过程编程世界中，而 PHP 作为一种面向对象的语言继续发展。核心开发人员需要找到一种方法来维护当今 PHP 中遗留代码的行为，而不破坏向后兼容性，“并且仍然使代码更好、更安全，并减轻 PHP 8.2 动态属性的弃用，”正如 Reinders Folmer 所说。“[WordPress 核心] 没有 [向后兼容性] 违反规则，我们实际上让自己的生活变得非常困难，”她在视频中指出。
“这是有充分理由的，”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 的 Hacker Newsletter。“维护编程被广泛视为清洁工作，”他写道。这让我想起了艺术家Mirele Laderman Ukeles，他的“维护艺术宣言”一直让我印象深刻，因为它与编程和 Web 开发非常相关：
两个基本系统：开发和维护。每次革命的酸球：革命后，星期一早上谁去捡垃圾？[…] 开发系统是部分反馈系统，具有很大的变化空间。维护系统是直接反馈系统，几乎没有改变的余地。
1969 年，Laderman Ukeles 是一位年轻的艺术家和新妈妈，当时她撰写了宣言并宣称维护就是艺术。她对如何将前沿艺术作品和高地位劳动与使它们成为可能的工作区分开来感到沮丧：养育子女、教授艺术技能和传统，或者只是举办一场艺术展。她以自己作为博物馆看门人的身份做了一个令人难忘的展览。然后，她（正在进行的）职业生涯的大部分时间都是作为纽约市卫生局的驻场艺术家度过的。她在该职位上的第一个项目是亲自感谢所有 8,500 名环卫工人“让纽约保持活力”。
阿特伍德对编程也有类似的看法。他引用了软件工程领域的几位重要人物的话说，贬低维护工作是完全错误的。Robert L. Glass 认为“维护是一项重大的智力挑战，也是一种解决方案，而不是一个问题”，因此对于最熟练的人来说，它应该被视为一项重要任务。Joel Spolsky很久以前就写道，开发人员很懒惰，他们“总是想扔掉代码并重新开始”的原因是“阅读代码比编写代码更难”。
在与 Andy Hunt 的对话中，Dave Thomas 争辩说：“所有编程都是维护编程，因为你很少编写原始代码。…… 您大部分时间都处于维护模式。所以你不妨硬着头皮说，“我从第一天开始就在维护。” 适用于维护的纪律应该适用于全球。” Hunt 表示同意，“当您第一次输入代码时，只有前 10 分钟才是原始代码。而已。”
Atwood 最终倾向于这种观点，但与我从 Jason Adams 和 Timothy Jacobs 那里听到的常见 WordPress 开发人员观点相呼应。WordPress开发/维护的特殊艺术？
“这是一种平衡行为。”
