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 ？
与最低需要 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 已达到其生命周期的终点
向后兼容性与稳定性、前瞻性思维与创新之间的权衡
遥测可以告诉您何时“面对”
提高最低 PHP 要求的最佳时机
案例研究：iThemes Security Pro
案例研究：GiveWP
弃用通知推动开发向前发展
在 PHP 8.2 之后不使用动态属性
不断发展的优雅代码之美
WordPress Core 如何跟上 PHP 的步伐并保持向后兼容性
所有的发展都是维护……
更正确的代码可能更安全
……所有维护都是艺术
“星期一早上谁来收垃圾？”
“所有编程都是维护编程”
PHP 7.4 已达到其生命周期的终点
不幸的是，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 保持同步可以提高安全性和性能。最新的编程概念和功能可能对开发人员向 WordPress 插件添加新功能很有价值。另一方面，延迟最低要求的 PHP 版本将取悦广泛的客户群。然而，稳定性在某些时候会变得自满和过时。
这是一种“现在付钱或以后付钱”的情况。最终，您必须面对并更新最低 PHP 要求。
遥测可以告诉您何时“面对”
对软件产品的任何重大更改都会导致大量支持请求。有关用户环境的良好数据和遥测有助于确定提高最低 PHP 版本要求的中断时间最少。这就是为什么插件所有者需要了解其用户的 PHP 版本采用情况。
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 社区的步伐，采用需要 PHP 7.3 或更高版本的依赖项。他们的大多数用户已经在那里。这就是 iThemes 安全开发团队决定提高新用户和现有用户的最低 PHP 要求的原因。
案例研究：GiveWP
对于大量投资于古腾堡块编辑器的 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 8.2 之后不使用动态属性
Nikita Popov在 PHP 9 中逐步淘汰动态属性的原因很好地说明了 PHP 朝着更具弹性的代码和编程约定发展的方向：
进行此更改的动机是双重的：防止在常见情况下出现错误（由于拼写错误或重命名），并明确有意使用。核心问题是，从不存在的属性中读取会发出诊断，使问题立即显现出来，而写入不存在的属性则完全没有提示。这时 PHP 没有任何提示表明程序员犯了错误。
不断发展的优雅代码之美
Brent Roose 关于从 PHP 5.6 到 8.2 的演变的两分钟视频是对 PHP 从 2014 年到现在的发展历程的精彩而简单的直观说明。使用简单的数据传输对象示例，Roose 展示了 PHP 5.6 代码如何在通往 PHP 8.2 的过程中缩减为更简单、整体更优雅的代码块。
正如 Roose 在处理动态属性（在 PHP 8.2 中已弃用）的技巧中指出的那样，在弃用警告变成致命错误之前，开发人员应该有足够的时间来更新他们现有的代码。然而，这条跑道将很快消失，而 WordPress 是一个特例。Tonya Mork 在 Trac 中有一个被接受的提案，用于处理WordPress 核心中的未知动态属性弃用。她和 Juliette Reinders Folmer 担心 WordPress 开发人员没有足够的时间来重构他们的代码。不能忽视为一个已有 20 年历史的项目保持向前和向后兼容性的特殊挑战。Mork、Reinders Folmer 和 Sergey Biryukov 基本上是这项艰巨任务的无名英雄。
WordPress Core 如何跟上 PHP 的步伐并保持向后兼容性
在讨论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 的readonly类和动态属性弃用。大部分这项工作在很大程度上也是一种维护形式。
在架构上，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 是一位年轻的艺术家和新妈妈，当时她撰写了宣言并宣称维护就是艺术。她对我们将尖端艺术作品和高地位劳动与使它们成为可能的工作分开的方式感到沮丧。育儿、教学或只是举办艺术展是艺术家所做的事情，但这些事情并未被视为其工作的一部分。为了指出这一点，Laderman Ukeles 做了一个令人难忘的展览，以她作为艺术博物馆看门人的身份为主题。然后，她（正在进行的）职业生涯的大部分时间都是作为纽约市卫生局的驻场艺术家度过的。她在该职位上的第一个项目是亲自感谢所有 8,500 名环卫工人“让纽约保持活力”。
阿特伍德对编程也有类似的看法。他引用了软件工程领域的几位重要人物的话说，贬低维护工作是完全错误的。Robert L. Glass 认为“维护是一项重大的智力挑战，也是一种解决方案，而不是一个问题”，因此对于最熟练的人来说，它应该被视为一项重要任务。Joel Spolsky很久以前就写道，开发人员很懒惰，他们“总是想扔掉代码并重新开始”的原因是“阅读代码比编写代码更难”。
“所有编程都是维护编程”
在与 Andy Hunt 的对话中，Dave Thomas 争辩说：“所有编程都是维护编程，因为你很少编写原始代码。…… 您大部分时间都处于维护模式。所以你不妨硬着头皮说，“我从第一天开始就在维护。” 适用于维护的纪律应该适用于全球。” Hunt 表示同意，“当您第一次输入代码时，只有前 10 分钟才是原始代码。就是这样。”
Atwood 最终倾向于这种观点，但与我从 Jason Adams 和 Timothy Jacobs 那里听到的常见 WordPress 开发人员观点相呼应。
WordPress开发/维护的特殊艺术？“这是一种平衡选择。”
希望本文有助于您了解PHP 8.2和WordPress的兼容性问题，您也许还想看看最新的WordPress 6.2 “Dolphy 海豚”。
点击阅读PHP 8.2：它对 WordPress、插件和开发者意味着什么？原文
