PHP 8.2.0 于 2022 年 12 月 8 日首次亮相。作為一項(xiàng)重大更新，它帶來了性能改進(jìn)、更簡單的語法和更高的類型安全性，并將null、false和true作為獨(dú)立類型。可能挑戰(zhàn) WordPress 開發(fā)人員的最大變化之一是引入了只讀類，它不允許使用動(dòng)態(tài)屬性（Dynamic properties）。
動(dòng)態(tài)屬性已被棄用，并將在 PHP 9 或可能的 PHP 10 中產(chǎn)生致命錯(cuò)誤。雖然可能會(huì)很痛苦——尤其是對(duì)于 WordPress 核心——棄用是一個(gè)關(guān)鍵特性，也是 PHP 送給開發(fā)人員的禮物。
讓我們看一下 PHP 的最新發(fā)展，以及 WordPress 開發(fā)人員如何保持向后兼容性，同時(shí)在新功能對(duì)最終用戶最有利的時(shí)候利用它們。
跟上 WordPress 中的 PHP 開發(fā)
由于 WordPress 核心保持顯著的向后兼容性，在不支持舊版本時(shí)沒有計(jì)劃的生命周期結(jié)束日期，因此 WordPress 企業(yè)需要確定他們自己的產(chǎn)品或服務(wù)生命周期以及他們將支持的 PHP版本。
與最低需要 PHP 7.4 的 WooCommerce 相比，WordPress 核心目前只推薦 PHP 7.4 或更高版本。它“也適用于”PHP 5.6.20，該版本在 2018 年底達(dá)到了生命周期結(jié)束日期。WordPress 項(xiàng)目注意到這一點(diǎn)并警告說，使用不受支持的 PHP 版本“可能會(huì)使您的網(wǎng)站面臨安全漏洞”。（WordPress.org 要求）
幸運(yùn)的是，目前只有 5.1% 的 WordPress 網(wǎng)站使用 PHP 5.6，而且只有 2% 使用更舊的版本。20% 使用 PHP 7.0 到 7.3，最大的一組 (56.7%) 使用 PHP 7.4。（WordPress.org 統(tǒng)計(jì)數(shù)據(jù)）
不幸的是，PHP 7.4 剛剛在 2022 年 11 月底達(dá)到了 EOL 日期。PHP 8.0 在 2023 年的大部分時(shí)間里提供官方安全支持的時(shí)間還不到一年。當(dāng)前受到積極支持的版本 PHP 8.1 將在2024 年的年底過時(shí)，PHP 8.2，剛剛發(fā)布了第一個(gè)穩(wěn)定版本，將在 2025 年 12 月之前提供安全支持。
這是一個(gè)快速的發(fā)布周期，WordPress 生態(tài)系統(tǒng)努力跟上它也就不足為奇了。超過一半的網(wǎng)絡(luò)在 WordPress 上運(yùn)行，這是一艘不能快速轉(zhuǎn)向的大船。這更像是一種平衡行為，而不是奔向最前沿的競(jìng)賽。然而，跳轉(zhuǎn)到 PHP 8 有很多好處，它具有強(qiáng)大的性能增強(qiáng)功能，例如運(yùn)行時(shí)的即時(shí) (JIT) PHP 編譯，可以更快地執(zhí)行并減少內(nèi)存使用。
向后兼容性與穩(wěn)定性、前瞻性思維與創(chuàng)新之間的權(quán)衡
在迎合盡可能廣泛的用戶群體和使用 PHP 保持流行之間的權(quán)衡一直是 WordPress 開發(fā)人員、主機(jī)和產(chǎn)品公司的兩難選擇。擁有長期客戶和舊站點(diǎn)的機(jī)構(gòu)和自由職業(yè)者面臨著同樣的問題：更新最低要求可能會(huì)迫使現(xiàn)有客戶對(duì)其站點(diǎn)進(jìn)行重大更改或看到它們崩潰。
一方面，與 PHP 保持同步的好處是提高了安全性和性能，并為開發(fā)人員提供了最新的編程概念和功能。另一方面，延遲最低要求的 PHP 的主要好處是一個(gè)快樂（盡管自滿）和廣泛的客戶群。這是一種“現(xiàn)在付錢或以后付錢”的情況。在某些時(shí)候，你必須撕下創(chuàng)可貼。
有關(guān)用戶環(huán)境的良好數(shù)據(jù)和遙測(cè)有助于確定提高最低 PHP 版本要求的最少中斷時(shí)間。大多數(shù)插件開發(fā)人員使用自己的工具關(guān)注這些數(shù)字，因?yàn)樗皇?WordPress.org 插件存儲(chǔ)庫的活動(dòng)安裝數(shù)據(jù)的一部分。不可避免地，任何影響許多人的潛在重大變化肯定會(huì)導(dǎo)致大量支持票。
優(yōu)先考慮向后兼容性也涉及大量維護(hù)工作。支持非常龐大和多樣化的用戶群對(duì)最終用戶來說非常好，但這意味著開發(fā)人員必須讓他們的代碼在許多不同的環(huán)境中工作。“我喜歡在添加新功能時(shí)支持舊的 PHP 版本，”——從來沒有開發(fā)人員說過！
他們不僅要擔(dān)心遺留的 PHP，還有遺留數(shù)據(jù)庫和 WordPress 堆棧中的許多其他變體。當(dāng)存在大量具有過時(shí)元素的 WordPress 服務(wù)器環(huán)境時(shí)，邊緣案例會(huì)突然出現(xiàn)，甚至?xí)寣＜腋械嚼Щ蟆?/p>
提高最低 PHP 要求的最佳時(shí)機(jī)
iThemes?Security Pro?7.2 版本是一個(gè)很好的例子，它提高了 WordPress 產(chǎn)品的最低 PHP 要求，以便為現(xiàn)有客戶提供創(chuàng)新和穩(wěn)定性。
從 7.2 版本發(fā)布開始，iThemes Security Pro 需要 PHP 7.3 或更高版本，最高支持 8.1。決定更新 iThemes Security Pro 的 PHP 要求是為了實(shí)施 WebAuthn 框架。實(shí)施需要需要 PHP 7.3+ 的庫來管理加密和公鑰。iThemes Security Pro 7.2 中引入的2FA?、密碼和生物識(shí)別登錄功能是這一決定的直接結(jié)果。在其明文密碼被破解的時(shí)候，iThemes 安全團(tuán)隊(duì)首次將無密碼登錄引入 WordPress，作為主要的用戶身份驗(yàn)證體驗(yàn)。
可以通過重寫 WebAuthn 庫以與舊版本的 PHP 兼容來構(gòu)建這些功能。當(dāng)然，這將需要更多的工作并創(chuàng)建額外的代碼來維護(hù)。明智的做法是以適度的速度跟上 PHP 社區(qū)的步伐，采用需要 PHP 7.3 或更高版本的依賴項(xiàng)。他們的大多數(shù)用戶已經(jīng)在那里。這就是 iThemes 安全開發(fā)團(tuán)隊(duì)決定提高新用戶和現(xiàn)有用戶的最低 PHP 要求的原因。
對(duì)于大量投資古騰堡塊編輯器的 WordPress 產(chǎn)品，如 GiveWP，管理變更可能更具挑戰(zhàn)性。WordPress 核心的穩(wěn)定性和緩慢的變化速度可能會(huì)讓后端 PHP 開發(fā)人員感到沮喪，但它允許前端 JavaScript/React 開發(fā)人員推動(dòng)平臺(tái)向前發(fā)展。
GiveWP 的開發(fā)經(jīng)理 Jason Adams 指出，它們不必向后兼容，因?yàn)殡S著站點(diǎn)編輯器的發(fā)展，它們可以跨版本遷移用戶。然而，“沒有 PHP 遷移這樣的事情，”他評(píng)論道。最終，他們將不得不適應(yīng) PHP 9 架構(gòu)并遠(yuǎn)離 PHP 8.2 中新棄用的功能。
WordPress 生態(tài)系統(tǒng)中的每個(gè)產(chǎn)品都沒有單一的“正確時(shí)間”來更新最低 PHP 要求。“這不是你可以從哲學(xué)上解決的問題，”亞當(dāng)斯告訴我。這實(shí)際上取決于基于有多少用戶將受到更改的不利影響而做出的判斷。如果 90% 或更多是在 PHP 7.2 或 7.4 上，將最低要求提高到該級(jí)別是可行的。
Adams 說，這些數(shù)字可能會(huì)因產(chǎn)品的特定用戶群而有很大差異。技術(shù)熟練的客戶使用的產(chǎn)品往往更接近當(dāng)前支持的 PHP 版本。像 GiveWP 這樣的產(chǎn)品，許多非營利組織都在使用它，需要更加重視向后兼容性。另一種方法是讓遺留代碼及其用戶在一個(gè)長期版本中分支，該版本將受到支持但不會(huì)看到添加的新功能。當(dāng)用戶準(zhǔn)備好進(jìn)行升級(jí)時(shí)，他們可以遷移到為將來的 PHP 兼容性而構(gòu)建的新的主要版本。
棄用通知推動(dòng)開發(fā)向前發(fā)展
WordPress.com 剛剛推出了 PHP 8.2作為其商業(yè)和電子商務(wù)計(jì)劃的一個(gè)選項(xiàng)，并激活了托管功能，并且在 WordPress.org 生態(tài)系統(tǒng)中，合理設(shè)計(jì)的舊代碼不太可能在下一個(gè)主要 PHP 版本中崩潰或變得不安全發(fā)布。盡管 WordPress.org 核心代碼庫官方僅提供對(duì) PHP 8.0 的“測(cè)試版”支持，但它通常可以與最新版本的 PHP 正常工作，支持良好的插件也是如此。他們不會(huì)拋出致命錯(cuò)誤或解析錯(cuò)誤。在調(diào)試打開的情況下，您甚至不應(yīng)該看到很多警告。您可能會(huì)看到很多已棄用的函數(shù)通知，它們還不是錯(cuò)誤。
快速 PHP 發(fā)布周期的挫折與開發(fā)人員陷入雜草中有很大關(guān)系重構(gòu)他們的代碼并追趕 PHP 已棄用的方面。這項(xiàng)關(guān)鍵工作可能會(huì)讓他們用更少的時(shí)間來探索和創(chuàng)新最新 PHP 版本帶來的新概念和功能。
還有另一種方式來看待這種情況。處理 PHP 的棄用功能實(shí)際上是前瞻性的，并迫使開發(fā)人員在不斷發(fā)展的語言的下一次迭代中變得流暢。如果沒有這種強(qiáng)制性的練習(xí)，現(xiàn)有的知識(shí)將更容易養(yǎng)成舊習(xí)慣，這些舊習(xí)慣一旦過時(shí)就會(huì)變成壞習(xí)慣。
棄用通知指出現(xiàn)在有效但會(huì)在未來版本的 PHP 中失效的內(nèi)容。如果您是開發(fā)人員，這對(duì)您有好處，正如 Brent Roose 解釋的那樣。如果開發(fā)人員注意這些通知，他們將有足夠的時(shí)間來處理任何已棄用的代碼。而且它不應(yīng)該成為次要版本更新的障礙。
iThemes 安全首席開發(fā)人員和 WordPress 核心提交者 Timothy Jacobs 表示，有棄用警告是件好事。他們推動(dòng)開發(fā)人員擁抱“更正確”和“不那么脆弱”的代碼，這些代碼將越來越安全、高性能、防錯(cuò)，并且能夠更好地應(yīng)對(duì)邊緣情況。在這個(gè)視圖中，E_DEPRECATED 通知填滿您的錯(cuò)誤日志“就像一個(gè)預(yù)警系統(tǒng)，表明將來會(huì)發(fā)生故障，但現(xiàn)在并沒有發(fā)生故障。”
在 PHP 8.2 之后不使用動(dòng)態(tài)屬性
Nikita Popov關(guān)于在 PHP 9 中逐步淘汰動(dòng)態(tài)屬性的基本原理是 PHP 朝著更具彈性的代碼和編程約定進(jìn)化的一個(gè)很好的例子：
進(jìn)行此更改的動(dòng)機(jī)是雙重的：防止在常見情況下出現(xiàn)錯(cuò)誤（由于拼寫錯(cuò)誤或重命名），并明確有意使用。核心問題是從一個(gè)不存在的屬性中讀取會(huì)發(fā)出一個(gè)診斷，使問題立即顯現(xiàn)出來，而寫入一個(gè)不存在的屬性是完全無聲的。PHP 沒有任何跡象表明程序員犯了錯(cuò)誤。
布倫特·羅斯 (Brent Roose) 關(guān)于從 PHP 5.6 到 8.2 的演變的兩分鐘視頻是 PHP 從 2014 年到現(xiàn)在沿著這些路線演變的精彩而簡單的視覺說明。使用簡單的數(shù)據(jù)傳輸對(duì)象示例，Roose 展示了 PHP 5.6 版本如何大幅縮減為更簡單、更精簡且總體上更優(yōu)雅的代碼塊。
正如 Roose 在處理動(dòng)態(tài)屬性（在 PHP 8.2 中已棄用）的技巧中指出的那樣，在棄用警告變成致命錯(cuò)誤之前，開發(fā)人員應(yīng)該有足夠的跑道來更新他們現(xiàn)有的代碼。然而，這條跑道將很快消失，而 WordPress 是一個(gè)特例。Tonya Mork 在 Trac 中有一個(gè)被接受的提案，用于處理 WordPress 核心中的未知?jiǎng)討B(tài)屬性棄用。她和 Juliette Reinders Folmer 擔(dān)心 WordPress 開發(fā)人員沒有足夠的時(shí)間來重構(gòu)他們的代碼，更不用說維護(hù)一個(gè)已有 20 年歷史的項(xiàng)目的向前兼容性的特殊挑戰(zhàn)了。Mork、Reinders Folmer 和 Sergey Biryukov 基本上是這項(xiàng)艱巨任務(wù)的無名英雄。
在討論P(yáng)HP 8.2 中的動(dòng)態(tài)屬性和魔法方法時(shí)，Mork 和 Reinders Folmer 指出，WordPress 在 PHP 3 和 4 中的根源使其保持在一個(gè)穩(wěn)固的過程編程世界中，而 PHP 作為一種面向?qū)ο蟮恼Z言繼續(xù)發(fā)展。核心開發(fā)人員需要找到一種方法來維護(hù)當(dāng)今 PHP 中遺留代碼的行為，而不破壞向后兼容性，“并且仍然使代碼更好、更安全，并減輕 PHP 8.2 動(dòng)態(tài)屬性的棄用，”正如 Reinders Folmer 所說。“[WordPress 核心] 沒有 [向后兼容性] 違反規(guī)則，我們實(shí)際上讓自己的生活變得非常困難，”她在視頻中指出。
“這是有充分理由的，”Mork 回應(yīng)道——“它是為了用戶。用戶有信心他們可以按下那個(gè)按鈕并升級(jí)，并且我們已經(jīng)考慮了向后兼容性，我們已經(jīng)優(yōu)先考慮它。它是我們的基石……因此用戶可以放心升級(jí)。”
所有的發(fā)展都是維護(hù)……
為了在 WordPress 核心中保持向后兼容性，嘗試向后移植“現(xiàn)代”PHP 以與 PHP 的兩個(gè)先前主要版本一起工作是一個(gè)獨(dú)特的挑戰(zhàn)。插件開發(fā)人員可以更輕松地以可以利用新功能的方式更新他們的代碼，例如 PHP 8.2 的只讀類和動(dòng)態(tài)屬性棄用。大部分這項(xiàng)工作在很大程度上也是一種維護(hù)形式。
在架構(gòu)上，PHP 8+ 的變化將重點(diǎn)放在編程概念上，例如不變性。根據(jù) Jacobs 的說法，不可變數(shù)據(jù)結(jié)構(gòu)“并不能從本質(zhì)上解決安全問題”，但它們確實(shí)可以幫助開發(fā)人員的代碼更不易出錯(cuò)且更正確：
我不會(huì)說不可變數(shù)據(jù)結(jié)構(gòu)天生安全，而可變數(shù)據(jù)結(jié)構(gòu)不安全。相反，不可變數(shù)據(jù)結(jié)構(gòu)有助于消除可能導(dǎo)致安全問題的編程錯(cuò)誤。通過減少我們的代碼可以存在的不同狀態(tài)的數(shù)量，我們可以降低代碼的復(fù)雜性，從而減少出錯(cuò)的機(jī)會(huì)。
將代碼維護(hù)為受支持的 PHP 版本標(biāo)準(zhǔn)的最佳理由是為了降低安全風(fēng)險(xiǎn)。在 Adams 看來，PHP 8.2 帶來了有用的便利和“護(hù)欄”，但很少能激發(fā)程序員的興趣或被視為游戲規(guī)則的改變者。#[\SensitiveParameter]屬性之類的東西可能更具有實(shí)際意義，因?yàn)樗试S從經(jīng)常轉(zhuǎn)到第三方服務(wù)的堆棧跟蹤中過濾掉敏感數(shù)據(jù)。在 PHP 8 中引入的屬性是 Adams 挑選的最后一項(xiàng)創(chuàng)新，這項(xiàng)創(chuàng)新引起了他的注意，因?yàn)樗梢詫?shí)現(xiàn)以前無法做到的事情：“從元視角描述某些東西 [如類、變量、方法等]。”
利用 PHP 8.0 到 8.2 和未來版本中的新功能是開發(fā)人員創(chuàng)造力大放異彩的地方，但簡單地支持這些版本，這樣插件和 WordPress 核心就不會(huì)破壞它們，既實(shí)用又重要。
……所有維護(hù)都是藝術(shù)
Jeff Atwood 有一篇古老但出色的博客文章，標(biāo)題為“維護(hù)編程的崇高藝術(shù)”，我最近閱讀了這篇文章，這要?dú)w功于 Kale Davis 的 Hacker Newsletter。“維護(hù)編程被廣泛視為清潔工作，”他寫道。這讓我想起了藝術(shù)家Mirele Laderman Ukeles，他的“維護(hù)藝術(shù)宣言”一直讓我印象深刻，因?yàn)樗c編程和 Web 開發(fā)非常相關(guān)：
兩個(gè)基本系統(tǒng)：開發(fā)和維護(hù)。每次革命的酸球：革命后，星期一早上誰去撿垃圾？[…] 開發(fā)系統(tǒng)是部分反饋系統(tǒng)，具有很大的變化空間。維護(hù)系統(tǒng)是直接反饋系統(tǒng)，幾乎沒有改變的余地。
1969 年，Laderman Ukeles 是一位年輕的藝術(shù)家和新媽媽，當(dāng)時(shí)她撰寫了宣言并宣稱維護(hù)就是藝術(shù)。她對(duì)如何將前沿藝術(shù)作品和高地位勞動(dòng)與使它們成為可能的工作區(qū)分開來感到沮喪：養(yǎng)育子女、教授藝術(shù)技能和傳統(tǒng)，或者只是舉辦一場(chǎng)藝術(shù)展。她以自己作為博物館看門人的身份做了一個(gè)令人難忘的展覽。然后，她（正在進(jìn)行的）職業(yè)生涯的大部分時(shí)間都是作為紐約市衛(wèi)生局的駐場(chǎng)藝術(shù)家度過的。她在該職位上的第一個(gè)項(xiàng)目是親自感謝所有 8,500 名環(huán)衛(wèi)工人“讓紐約保持活力”。
阿特伍德對(duì)編程也有類似的看法。他引用了軟件工程領(lǐng)域的幾位重要人物的話說，貶低維護(hù)工作是完全錯(cuò)誤的。Robert L. Glass 認(rèn)為“維護(hù)是一項(xiàng)重大的智力挑戰(zhàn)，也是一種解決方案，而不是一個(gè)問題”，因此對(duì)于最熟練的人來說，它應(yīng)該被視為一項(xiàng)重要任務(wù)。Joel Spolsky很久以前就寫道，開發(fā)人員很懶惰，他們“總是想扔掉代碼并重新開始”的原因是“閱讀代碼比編寫代碼更難”。
在與 Andy Hunt 的對(duì)話中，Dave Thomas 爭(zhēng)辯說：“所有編程都是維護(hù)編程，因?yàn)槟愫苌倬帉懺即a。…… 您大部分時(shí)間都處于維護(hù)模式。所以你不妨硬著頭皮說，“我從第一天開始就在維護(hù)。” 適用于維護(hù)的紀(jì)律應(yīng)該適用于全球。” Hunt 表示同意，“當(dāng)您第一次輸入代碼時(shí)，只有前 10 分鐘才是原始代碼。而已。”
Atwood 最終傾向于這種觀點(diǎn)，但與我從 Jason Adams 和 Timothy Jacobs 那里聽到的常見 WordPress 開發(fā)人員觀點(diǎn)相呼應(yīng)。WordPress開發(fā)/維護(hù)的特殊藝術(shù)？
“這是一種平衡行為。”
