PHP 8.2：它對 WordPress、插件和開發人員意味著什麼？

PHP 8.2.0 於 2022 年 12 月 8 日首次亮相。作為一項重大更新，它帶來了性能改進、更簡單的語法和更高的類型安全性，並將null 、 false和true作為獨立類型。 可能挑戰 WordPress 開發人員的最大變化之一是引入了只讀類，它不允許使用動態屬性。

動態屬性已被棄用，並將在 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 代碼如何在通往 PHP 8.2 的過程中顯著縮減為更簡單、更精簡和整體更優雅的代碼塊。

正如 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 的黑客通訊。 “維護編程被廣泛視為清潔工作，”阿特伍德寫道。 這讓我想起了藝術家 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開發/維護的特殊藝術？

“這是一種平衡行為。”

保護和保護 WordPress 的最佳 WordPress 安全插件現在優惠 35%！

WordPress 目前為超過 40% 的網站提供支持，因此它很容易成為懷有惡意的黑客的目標。 iThemes Security Pro 插件消除了 WordPress 安全性的猜測，使保護和保護您的 WordPress 網站變得容易。 這就像擁有一名全職安全專家，不斷為您監控和保護您的 WordPress 網站。

立即節省 35%！

丹·克勞斯

Dan Knauss 是 StellarWP 的技術內容通才。 自 1990 年代後期以來，他一直是一名作家、教師和自由職業者，從事開源工作，自 2004 年以來一直從事 WordPress。