WordPress 和 PHP 8 – 兼容性和優勢！

大多數技術極客都對 PHP 8.0 感到興奮，當然，這次的變化是巨大的。 每個人都將花費一些時間來了解 PHP 8 的兼容性、配置、優勢等，其中彈出的最大問題之一是——“WordPress 是否已經與 PHP 8 兼容，如果不兼容，那麼需要採取什麼行動。”

好吧，一旦 PHP 8 發布，我們的專家時間就投入到最深層次的測試中，結果可以震驚任何人！ 是的，我們現在什麼都知道，並且很高興炫耀我們的品酒報告和結果。

我們不僅會展示所有的變化，還會就是否應該更新到 PHP 8 給您一個純粹的建議。

PHP 8 中有如此多的重大變化：但是為什麼呢？

PHP 8 是 PHP 的一次巨大更新，通常的做法是從最近的次要版本範圍中刪除主要版本中的負面影響。 對於備受關注的 PHP 8，在之前的 7.* 版本中減少了幾個重大更改。

因此，對於多年來認真更新的項目，修復其貶損的 API，升級應該不難。 說實話，與以前的 PHP 版本相比，PHP 7.* 版本已經觀察到了更多的棄用。

我們會說 PHP 5.6 到 PHP 7 是一個非常簡單的遷移，但是從 7.x 到 8 可能會有些痛苦，尤其是對於包括 WordPress 在內的舊代碼庫，以及幾個可用的插件。

當然，對於類型良好的代碼庫或具有最新 PHP 版本的最新代碼庫，不會出現大問題。 然而，現實情況是 WordPress 並不是這樣的代碼庫。

WordPress 是否已經與 PHP 8 兼容？

老實說，也許 WordPress 已經與 PHP 8 兼容，但密封這些詞是不可能的。 WordPress 的目標是始終與最新版本的 PHP 兼容。 但是，我們已經深入分析了本指南後面的最大問題。

我們已經完成了一項了不起的工作，為使用可用策略找到的大多數兼容性問題找到了完美的修復程序。 我們肯定會更深入地研究那裡的一切以及它們存在的問題。

即將發生哪些性能變化？

PHP 8 帶來的主要潛在令人興奮的特性是 JIT（即時）編譯和調試。 眾所周知，PHP 是一種解釋型語言，這意味著它在運行時會被翻譯成機器代碼。

JIT 跟踪經常使用的代碼，並致力於優化機器代碼翻譯以使其可重用。 現在，這可以為給定功能帶來巨大的性能改進。

JIT 包含在各種語言中，例如 JavaScript，歷史上已經引發了新應用程序的爆炸式增長。 例如，在 Web 的早期，運行在 JS 中的虛擬機是無法想像的。 過去需要在服務器上安裝模塊的一些任務將使用核心 PHP 庫變得實用。

目前，像 WordPress 這樣的 Web 應用程序的實際性能提升是最小的。 除此之外，開發人員或普通 WordPress 用戶需要很長時間才能獲得這一新功能的優勢。

還有其他幾個新功能可以為開發人員的生活帶來便利； 在可預見的未來，它們不太可能在 WP 主題和插件中使用，因為大多數會破壞與幾個 WordPress 網站仍在使用的 PHP 早期版本的兼容性。

如何為您的 WordPress 網站更新 PHP？

在本指南中，我們將描述如何方便地將 PHP 更新到最新版本，最重要的是，不會破壞您的 WordPress 網站。

如果您渴望知道路徑，那麼只需檢查您當前的 PHP 版本，然後將 WordPress 更新到最新版本。 之後，安裝“one.com PHP 掃描程序”並運行掃描以修復潛在問題。 此外，將 PHP 更新到最新版本，並驗證您的站點是否按預期運行。

讓我們展示整個過程。

第 1 步：檢查您當前的 PHP 版本

一開始，您必須檢查當前正在使用的 PHP 版本。 您可以從phpinfo 頁面獲取您網站當前 PHP 版本的信息。

如果您在 cPanel 上運行，您可以從文章如何查看和更改 cPanel 中的 PHP 版本中查看 PHP 版本。

如果您使用的是 PHP 7.3 或更高版本，那麼一切都很好。 對於那些擁有 PHP 7.2 的用戶，需要進行更新。 請珍惜第2步。

第 2 步：將 WordPress 更新到最新版本

如果您真的想避免任何故障，請確保將 WordPress 核心以及所有插件和主題更新到最新版本。

1. 登錄到您的WordPress 管理員並單擊儀表板>更新。
2. 檢查您是否安裝了最新版本的 WordPress，以及所有主題和插件是否都是最新的。 立即將您的 WordPress 更新到最新版本。

第 3 步：安裝“one.com PHP 掃描程序”。

1. 在您的WordPress 管理員中，點擊one.com >插件。
2. 找到one.com PHP 掃描程序並點擊立即安裝。
3. 現在，單擊激活，然後轉到下一步。

第 4 步：運行掃描並修復潛在問題

1. 在左側的菜單中，點擊PHP 掃描器。
2. 點擊PHP 7.4 版，然後點擊“所有主題和插件”，然後點擊開始掃描。
3. 掃描完成後，您可以繼續。
4. 你可以得到三個結果：

–兼容= 這意味著一切都很好！

–警告= 這意味著它應該可以工作，但可能會給即將發布的 PHP 版本帶來問題。

–錯誤= 不太好，更新後肯定會出問題。

通過將其更新到最新版本或將其替換為提供相同功能的替代插件來修復任何讀取錯誤的主題或插件。

提示：我們建議您只使用那些插件，這些插件使用定期更新的插件，不會帶來與最新版本 WordPress 的兼容性問題。 除此之外，刪除任何不需要的插件以提高網站性能是一個很好的做法。

第 5 步：將 PHP 更新到 8.0 版本

您現在已準備好更新 PHP。 我們建議同時打開 PHP 錯誤消息。 如果代碼有問題，您會看到錯誤消息，告訴您是什麼原因造成的，以及它的確切位置。

1. 在控制面板中，返回PHP 和數據庫設置。
2. 向下滾動到PHP 錯誤消息。
3. 將錯誤消息設置為On後單擊更新。
4. 在此下方，更改版本並點擊更新。

第 6 步：驗證您的網站是否按預期運行。

現在，您已經更新了 PHP 版本，至少需要 20 分鐘才能應用更改。 如果您的網站有很多訪問者，則時間範圍可能會延長到幾個小時。 這就是我們建議在接下來的 24 小時內至少檢查幾次您的網站的原因。

如果您的網站不符合您的預期，那麼最有可能的問題是您的主題或任何插件。 要找出究竟是什麼導致了問題：

1. 暫時切換到默認的 WordPress 主題，我們會說“二十七”。
2. 選擇所有已安裝的插件並完全停用它們。
3. 再次啟用主題和所有插件，每次都檢查您的網站是否仍在運行。 您可以通過這種方式抓住罪魁禍首。

如果我們從技術上講，那麼當前的 WordPress 夜間版與備受討論的 PHP 8 的兼容性與我們在新版本的 PHP 彈出之前的 WordPress 版本中所居住的水平相似。

我們的測試與 WordPress 核心中的任何 PHP 兼容性修復一樣大，修復也非常細緻。 但是，如果您不遵循本指南，您將無法理解兼容性挑戰並從 PHP 8 中獲得最大收益。

PHP 8 中包含的大量重大更改和各種更改，除了在跨版本工具中增加了一些複雜性之外，無疑使這種兼容性挑戰成為了我們以前使用 PHP 以前版本所經歷的更大的野獸。 本報告旨在解釋同一案例。

WordPress 和 PHP8 兼容性挑戰

我們將向您展示一些您可以部署的策略，以使現有代碼庫與 PHP 8 兼容。

• 靜態分析工具，例如 PHPCompatibility 來檢測語法問題。
• 自動測試以檢測運行時問題。
• 手動測試以檢測運行時問題。

根據您的測試套件的覆蓋範圍以及語法更改和運行時的比例，這些策略很好地用於修復代碼庫與新版本 PHP（目前正在討論 PHP 8）的兼容性。

確實，在 PHP 8 和 WordPress 的情況下，還有一些額外的挑戰使得很難依賴這些策略來確保 WordPress 與 PHP 8 的完美兼容性。下面我們將報告我們已經部署的策略對於 WordPress 並分享結果。

靜態分析工具

由於 PHP 8.0 中的一些更改的性質，使用靜態分析可以檢測到的問題是有限的。 在那些情況下，靜態分析看起來超越了它們的傳統潛力併計劃跟踪變量和常量的值以及運行時類型，這種掃描的結果肯定會容易出現誤報。

除此之外，PHP Compatibility 是唯一一款用於查找 PHP 跨版本兼容性相關問題的靜態分析工具。

除了 PHP 兼容性之外，其他靜態分析工具還報告了更大範圍的問題。 珍惜結果以檢測與 PHP 跨版本兼容性相關且實際上正確的問題非常耗時，並且需要深入的工具相關知識，尤其是關於將它們配置為最小噪音的知識。

同時，這些工具一直處於不穩定狀態，試圖繼續 PHP 版本的變化並更新可能的掃描。 因此，我們可以期待這些工具在未來檢測到更多問題。

因此，與目前已經存在並且可以進一步發現的東西無關，這些工具很有可能在（不遠的）將來仍然會發現更多問題。

使用 PHPCompatibility 掃描 WordPress

“__destruct() 將不再在 __construct() 中的 die() 之後被調用”是 PHPCompatibility 發現的另一個 PHP 8 問題。 掃描儀可以完美地檢測到這一點。 但是，經過進一步分析，發現在這種情況下沒有問題。

除此之外，PHPCompatibility 在“插件/主題編輯器”使用的代碼中檢測到問題。 涉及代碼的分析已確定代碼中存在潛在的疏忽。 在編輯器中，WordPress 期待對代碼做最少的分析； 但是，它沒有考慮 PHP 5.3+ 代碼。

在考慮到 PHP8 中的相關變化的同時，這種疏忽現在變得更加複雜，難以解決。 我們使用 PHPCompatibility 對開發版本進行了掃描，正如我們預期的那樣，結果與我們使用之前的 PHP 更新獲得的結果大不相同。 掃描儀檢測到的問題由外部維護。

使用 Exakat 掃描 WordPress

談到 10 月 16 日發生的最新公開掃描，基於 WP 主幹， Exakat 總共報告了 149.567 個問題。

PHP 8 兼容性報告向我們展示了總共 93 個問題。 但是，它是不完整的，因為與 PHP 8 相關的分析編號未包含在報告中。

雖然我們預計這些報告會包含大量誤報，因為 WordPress 不使用類型聲明，因此類型是從找到的代碼和 docblocks 中顯示的類型推斷出來的，但仍應單獨檢查這些問題。

無論發現的問題中只有 1% 是正確的，但仍然會下降到大約 450 個錯誤，這仍然需要處理。 除此之外，從誤報中剔除真實問題需要大量時間。

使用 PHPStan 掃描 WordPress

使用PHPStan 進行掃描需要完全定制的規則集才能獲得遠程可用的結果，但事實證明它們充滿了一些誤報，導致輸出無法使用。

注意：我們並不是在批評 PHPStan 工具，但這很大程度上是因為 WordPress 幾乎不使用類型聲明，而另一方面，PHPStan 主要傾向於使用現代代碼的項目，不是嗎？

包含最基本配置的初始掃描將產生 20.000 多個問題。 使用上述高度定制的規則集進行掃描，專門針對 PHP 8 相關問題，仍然會在級別 5 產生 580 個問題，在級別 7 產生額外的 2.150 個潛在問題。這些可能包含一些誤報，但會產生更多 380 個問題在第 8 級有類似的警告。

最近打開了一個Trac 票證，以解決基於未知配置的一系列問題，但完全針對您傳遞的參數類型不匹配（級別 5）。 PR 草案可用於解決這些問題。

對該 PR 的初步評估表明，大多數提議的修復都會將變量類型轉換為預期的類型並隱藏問題，而不是通過正確檢查來實際修復它們。 如果這些更改沒有伴隨嚴格的單元測試，這會導致應用程序出現意外行為。 除此之外，tit 可能會導致難度增加，同時肯定會進一步調試錯誤。

目前，尚不確定建議的修復是否有必要，或者是否應將已識別的問題視為誤報。

測試

由於 PHP8 中存在問題的交換的性質，靜態分析可以走這麼遠。 手動審查和測試軟件被證明是一項艱苦的工作，當有很多事情需要注意時，人類也很容易忽視一些事情。

現在，談到最終用戶執行的測試，它們被證明是相對無用的，因為這通常會導致測試“快樂路徑”。 如果我們想獲得更可靠的結果，那麼我們需要全面的探索性和回歸測試。

擁有高質量的自動化測試並在 PHP 8 上運行這些測試比什麼都重要。 這將完美地表明預期的 PHP 8.0 問題。

大多數技術極客都對 PHP 8.0 感到興奮，當然，這次的變化是巨大的。 每個人都將花費一些時間來了解 PHP 8 的兼容性、配置、優勢等，其中彈出的最大問題之一是——“WordPress 是否已經與 PHP 8 兼容，如果不兼容，那麼需要採取哪些措施是需要的。”

好吧，一旦 PHP 8 發布，我們的專家時間就投入到最深層次的測試中，結果可能會讓任何人感到震驚！ 是的，我們現在什麼都知道了，並且很高興炫耀我們的報告和測試結果。

現在讓我們繼續在 PHP 8 上運行自動化測試。

在 PHP 8 上運行自動化測試

PHPUnit 9.3 是第一個與 PHP 8.0 正式兼容的 PHPUnit 版本，於 2020 年 8 月發布。好吧，在 PHP 上運行自動化測試套件很困難，因為事實上的單元測試工具。

讓一個在 PHP 8 上運行的自動化測試套件將我們帶入下一個兔子洞，作為在 PHP 世界中執行單元測試的事實上的工具； PHPUnit 通常每年都會發布一個大版本，每個主要版本都支持以前的 PHP 版本。 它引入了重大更改，但由於 PHPUnit 9.3 正式兼容 PHP 8.0，正如我們上面提到的，無需擔心！

我們知道，WordPress 至少仍然支持 PHP 5.6。 為了在 PHP 8.0 上運行測試，任何與 WordPress 相關的測試套件都需要與 PHPUnit 5 到 PHPUnit 9 完全兼容。 實現這些工具以使測試套件兼容仍然需要花費精力和時間。

讓測試在 PHP8 上運行 WordPress Core

WP Core 的測試目前正在通過並針對 PHP 8 運行。這些測試是在 PHPUnit 7.5 的 composer 安裝版本上進行的。 儘管 PHPUnit 9.3 是與 PHP 8 正式兼容的最古老的 PHPUnit 版本。

最後一個問題已通過將選定數量的文件/類從 PHPUnit 9.3 複製到 WordPress 測試套件來解決，不包括 Composer 自動加載生成中的 PHPUnit 的本機類，支持在 WordPress 測試套件中使用 PHPUnit 9.3 的副本。 這是可行的，但是，現在，我們將其稱為 hacky 解決方案，除了當前可能需要的維護外，它在未來可能不可持續。

為了測試的質量，一開始肯定很低，在大多數情況下都使用鬆散的類型檢查。

更深入地講，解決此問題的 Trac 票證於 2016 年開放。考慮到 PHP 中更嚴格的類型遵守，此票證已恢復。 已經進行了大量工作來緩解這種情況。

在我們編寫時，大約有 800 個實例（676 個 assertEquals() 添加到 96 個 assertNotEquals()）。 仍在使用鬆散的類型檢查——從 8000 多個實例減少。

部分地，在比較對象時，剩餘的鬆散類型斷言是合法的； 在某種程度上，這些當然需要解決。 但是，它目前會導致測試失敗。 最後這些強調了測試中的缺點，但更多的是，在被測試的代碼中。

測試主題和插件

只有一小部分可用的插件是專業開發的，並且更受歡迎，並且已經進行了自動化測試。 一般來說，這是令人擔憂的，因為一個普通的 WordPress 網站肯定會運行近 19 或 20 個插件。 相當多的網站推出了更多插件！ 對主題進行自動化測試就更罕見了。

讓這些測試套件在 PHP 8 上運行是一項挑戰。而且在獲得有關插件和主題與 PHP 8 兼容性的見解之前也是如此。

但是，所擁有的插件/主題大多是可以預期最少 PHP 8.0 問題的插件/主題。 我們驚呼是因為這樣的主題/插件使用了專業的開發模型。

更大的擔憂是沒有測試的大量測試和主題，因為在使用 PHP 8 運行時這些更容易出現問題。

對於確實有測試的主題和插件，主要有兩種類型的測試，它們可能有也可能沒有到位：

• 單元測試。 “嘲笑” WP 以允許測試插件代碼的獨立測試。 使用了像BrainMonkey和Mockery這樣的流行框架。
• 集成測試。 現在，集成測試是在我們運行測試套件之前 WordPress 本身加載的地方，它將使用 WPcore 代碼並與 WP 測試套件集成。

集成測試

我們知道 WordPress 已決定堅持使用 PHPUnit 7.5。 這意味著什麼？

好吧，對於主題和插件的集成測試，這些也將跳轉到 PHPUnit 7.5（最大）。

主題和插件要么必須複製 WP Core 中的 hack 以使其集成測試完美運行，要么必須使用WP Core 中的文件。 但是，他們將不得不創建一個自定義自動加載器，因為無法使用相同的 Composer 自動加載生成黑客。

如果無論如何都需要阻止加載 PHPUnit 原生文件，則必須確保在 Composer 自動加載文件之前引導此類自定義自動加載器。

單元測試

對於在 Mockery 或 BrainMonkey 幫助下的單元測試，PHPUnit > 8 是必需的，因為可用於 PHPUnit 7.x 的 Mockery 框架與 PHP 8.0 不兼容。 因此，這些測試套件的可比性對於 PHPUnit 5 到 9 是強制性的，這無疑增加了另一個挑戰。

如何？

當使用兩種測試套件時，需要不同版本的 PHPUnit 來運行每個測試套件。 為了加劇這種情況，插件通常會有一個提交的 composer.lock 文件，以確保它們的運行時依賴項處於它們可以依賴的給定版本，並且與 PHP 5.6 完全兼容。

在某些時候，最後一部分是通過在 composer.json 文件中具有平台 php 5.6 類型的配置來強制執行的。 這也意味著他們的開發依賴項 BrainMonkey、Mockery、PHPUnit也將鎖定在與 PHP 5.6 兼容的版本。 現在，這肯定會阻止在 PHP 8.0 上運行測試。

除了更新 composer.lock 文件和 composer.json 之外，您還可以通過即時刪除平台來克服這個問題。 但是，這使得在 PHP 8.0 上運行測試對開發人員來說更加複雜，無論是在 CI 中還是在本地。

PHP 8 兼容性在大型 WordPress 網站上看起來有些棘手

通過調查 PHP 8 中的一系列重大更改，我們可以確認這很容易在網站上造成巨大的破壞，而破壞的原因尚不清楚。 在某些時候，錯誤會發生在一個地方，但由不同地方的主題或插件生成，這肯定會使這些問題很難調試。

accuwebhosting.com無疑是一個積極維護的 WordPress 網站，並且有專門的專業開發人員團隊為其提供支持。 絕大多數 WordPress 網站都沒有這樣的奢侈，並且減輕這些網站上的兼容性問題肯定是具有挑戰性的。

開發者需要多久更新一次？

PHP 每個版本的生命週期為 2 年，並且在這個時代修復了 bug。 再增加一年，在此期間修補安全問題。 PHP 7.4 於 2019 年 11 月到來。它是 PHP 7 的最終版本。這意味著 PHP 7.4 中的錯誤將被修復到 2021 年 11 月。安全問題將被修補到 2022 年 11 月。它將達到其“生命終結”在那個時間點。

因此，硬性截止日期是 2022 年 11 月：此時所有 PHP 代碼都需要與 PHP 8 兼容，否則就有被困在潛在易受攻擊的 PHP 版本上的危險。

結論

PHP 8 將包含許多重大更改。 我們已經在我們的報告中描述了這些變化的一個很好的範圍，我們的專家認為除了更廣泛的 WordPress 生態系統之外，這些變化將對 WordPress 產生更劇烈的影響。 那些通常必須處理成為問題的警告。 並且引入了幾個錯誤，這可能很難處理。 您可以在運行時檢測到更高百分比的這些更改。

解決所有這些兼容性問題是一項艱鉅的任務。 為此，您需要使用各種策略，從靜態分析到自動化測試。 它需要大量的時間+精力。

您應該有權使用工具來完美地執行所有操作。 對於必須支持各種 PHP 版本的項目，如 WordPress，在處理各種版本的分析工具時引入了一些額外的複雜性，正如我們上面討論的那樣。

當然，由於 PHP 5 和 8 之間的運行時和語法差異如此之大，這變得相當困難。

在 WordPress 上使用 PHP 8 好不好？ 其實不是這裡的論據。 這裡唯一的結論是——這樣做變得非常具有挑戰性。

此外，我們還考慮了覆蓋問題和 WordPress 的 PHP 依賴關係。 如果您想可靠地檢測兼容性，那麼高測試覆蓋率證明是必要的。 談到 PHP 8，它甚至更重要，因為兼容性問題的數量比平時要多。 其中很大一部分可以僅在運行時檢測到。

那麼，我們有什麼建議呢？

如果檢測到問題，則需要進行大量調試以找到問題的根源，無論是 WordPress、主題、插件，還是與 PHP 兼容性直接相關。

依賴項幾乎沒有測試覆蓋率並且很低。 因此，很難驚呼什麼是真正意義上的 WordPress 與 PHP 8 的核心兼容性。

由於 PHP 8 如此專注於嚴格類型，WP 的類型不安全可擴展性系統變得更加容易受到問題的影響，可能導致插件在其他插件或 WP 本身中產生類型錯誤。

我們通過對上個月的錯誤數據進行分析來對此進行測試。 作為一個巨大的網站，我們認為它可能會強烈表明我們可以預期的各種問題。 當然，我們發現幾個警告會演變成 PHP 8 的錯誤。

我們更願意在這裡做一個最後的說明。 WordPress 並不是唯一可用的遺留代碼庫。 它也不是唯一一個支持大量 PHP 版本的項目。 本文中的信息也可能適用於其他項目。

Accuweb的這篇文章的主要目的是告知並概述與 WP 中的 PHP 8 兼容性相關的挑戰和問題。 我們非常希望它能完美地達到這個目的。