分四步切換到 PHP 8.x——Juliette Reinders Folmer 訪談
已發表: 2023-03-04將 WordPress 站點、插件或主題升級到新版本的 PHP 是一項定期執行的任務。 但是如何盡可能高效地做到這一點呢？ 你怎麼知道你不會忽略任何事情？ 有路線圖嗎？
在本文中，我們將解決這些問題（以及更多問題），並了解為您的 WordPress 網站、插件或主題平穩過渡到 PHP 8.x 所涉及的內容，包括路線圖。
我們將根據對 PHP 專家 Juliette Reinders Folmer 的採訪來進行此操作。 她將日常生活的大部分時間都投入到編程和與之相關的一切中，主要關注開源項目，包括 WordPress。
你也準備好順利切換了嗎？ 對我們的分步計劃感到好奇嗎？ 那麼讓我們開始吧！
PHP 8.x——改變了什麼
有關更改的概述，我們推薦以下文章：
- PHP 8.0 和 PHP 8.1 的發行說明
- PHP 8.0 和 PHP 8.1 遷移指南
- WordPress 和 PHP 8.0 以及當前狀態
- PHP 8.0 和 PHP 8.1 的新特性
閱讀這些文章後，您將完全了解 PHP 8.x 中發生的變化以及您需要做些什麼才能讓您的 PHP 項目順利運行。
如果您不確定最好的開始方式是什麼，沒問題。 在與 Juliette 的對話中，我們詳細討論了這一點，我們將在本文中盡可能完整地向您解釋如何切換到 PHP 8.x。
我們還將在信息框中說明如何在 MyKinsta 中執行各種操作，MyKinsta 是我們為您的所有 WordPress 網站、應用程序和數據庫提供的專有控制面板。
切換到 PHP 8.x：如何開始
切換到 PHP 8.x 聽起來很簡單，從技術上講確實如此。 許多主機允許您在管理面板中指定要為您的網站使用的 PHP 版本。 在 Kinsta，只需在 MyKinsta 儀表板中單擊一下即可切換 PHP 版本。
但在此之前，您需要確定一些事項。 根據您的知識和經驗水平，我們建議如下：
- 如果您使用標準主題和插件構建了自己的 WordPress 網站，但對 PHP 了解不多，請聘請開發人員或機構調查您的網站是否適合在 PHP 8.x 上運行。 您是否正在尋找可以幫助您解決此問題的第三方？ 然後查看我們的合作夥伴頁面，其中列出了幾家可以為您提供幫助的值得信賴的公司。
- 如果您的 WordPress 網站是由外部方、開發人員或代理機構構建的，請聯繫他們詢問您的網站是否可以在 PHP 8.x 上運行。
- 如果您已經構建了您的 WordPress 網站——例如，使用您自己的自定義主題或自行開發的插件——我們在下面為您提供了路線圖。
如果您的站點屬於前兩個類別之一，我們當然會邀請您通讀本文的其餘部分，但我們不建議您開始自行測試站點的 PHP 8 兼容性。 交給專業人士吧。
無論您選擇什麼，我們都建議您不要只是將您的實時網站切換到 PHP 8 並“看看它是否有效”。 您是否對您的網站的外觀感到好奇，並且迫不及待地想看到它在 PHP 8 上運行？ 然後開始在暫存環境中進行測試。 一個好的主機可以讓你輕鬆搭建一個暫存環境。
在暫存環境中，您可以激活 PHP 8.x 並查看此更新是否適用於您的站點。 也可以使用您站點的本地副本。 使用我們免費的 DevKinsta 開發工具，您可以輕鬆地從 MyKinsta 儀表板導入您的網站，之後您可以將 PHP 版本更改為 8.0 或 8.1。
如果您在暫存環境中沒有看到任何問題，並不一定意味著實際上沒有任何問題。 下面的路線圖將告訴您原因。
PHP 8.x 兼容性測試：路線圖
測試：好軟件的關鍵詞。 即使對於 WordPress 網站及其組件（如主題、插件和 WordPress 核心），測試也是確保您不想發生的事情不會發生的手段。
軟件開發項目主要由測試組成。 在本文中，我們將專門研究可幫助您順利過渡到 PHP 8.x 的測試。 在我們關於 DevOps 工具的文章中，您會找到一個包含您可以使用的工具集合的部分。
這篇博文討論了以下類型的測試：
讓我們更仔細地看看我們可以執行的不同類型的測試。
靜態分析（或靜態測試）
作為 PHP 開發人員，您可以採取的第一步是使用各種工具對您的代碼執行靜態分析。 靜態分析是在不執行代碼的情況下分析軟件的過程。 通過靜態分析，可以檢測錯誤、檢測 PHP 8.x 兼容性問題、執行編碼標準（例如 WordPress 編碼標準），甚至可以修改和清理代碼。
靜態分析工具
您可以使用各種工具執行靜態分析，例如：
- PHP兼容性
- 詩篇
- PHP斯坦
在撰寫本文時，並非所有 PHP 8.1 檢查都在最新的 PHPCompatibility 版本中得到支持。 PHP 8.1 檢查可以在開發版本中進行，因此請確保在使用 PHPCompatibility 分析項目並查看存在哪些錯誤/建議時（暫時）使用這些檢查。
PHP 8.1 檢查將很快在新的主要版本中發布。 如果您想了解最新信息，並且您有 GitHub 帳戶，請打開 PHPCompatibility 的 GitHub 存儲庫並導航至Watch -> Custom -> Releases ，您可以在其中選擇在發布新版本時收到通知。
PHPCompatibility 僅測試特定版本（或版本範圍）的 PHP 的兼容性，易於設置。 如果您在 PHPCompatibility 中運行 testVersion，例如 8.0+（8.0 及更高版本），您將獲得最佳結果。
您應該留意已棄用或已刪除的函數、已更改的函數參數默認值、是否使用不帶括號的 concat、是否使用 match 作為函數名稱（因為自 PHP 8.0 以來它已被保留）等。
Psalm 和 PHPStan 是很好的補充，可以通過執行與變量類型相關的額外檢查來幫助您。 這些工具的缺點是需要大量配置才能獲取有關 PHP 8.0 和 8.1 的報告。 即使他們成功了，您也可能會遇到許多誤報。 誤報是由於靜態分析的局限性而錯誤給出的通知。
正確解釋這兩個工具的結果需要紮實的知識，但這些知識可以幫助您識別 PHPCompatibility 無法發現的其他不兼容性。 如果您想了解更多信息，請查看 Psalm 和 PHPStan 的文檔。
概括：
- 使用 PHPCompatibility、Psalm、PHPStan 執行靜態分析
- 解決所有合法問題
單元測試
該過程的下一步是單元測試。 單元測試是一種單獨測試代碼片段的方法。 在單元測試中，將為每個單元開發特定的目標測試。 這將涉及運行不同的場景。 優選地，每個場景都與其他場景分開測試，以便測試彼此獨立。
當然，只有單元測試是不夠的。 它們也需要運行。 單元測試最好使用 CI（持續集成）工具（例如 Jenkins、GitHub Actions 或 Travis）實現自動化。
支持多個版本的 PHP
作為插件構建器，如果你想支持多個 PHP 版本，請確保 CI 中的測試針對你支持的所有 PHP 版本運行。
當然，你也可以只支持較新的版本，選擇完全取決於你。
使用多個 PHP 版本進行測試需要您使用多個 PHPUnit 版本，具體取決於 PHP 版本。 由於 PHPUnit 多年來引入了一些影響測試編寫方式的更改，因此這部分可能很棘手。
要解決這個問題，您可以使用 PHPUnit Polyfills（由 Juliette 編寫並由 Yoast 贊助）。 這使您可以編寫 PHPUnit 9 官方不支持的測試（因此可以在 PHP 8.x 上運行）。 然後，Polyfill 使您的測試在 PHPUnit 4.x 到 9.x 以及 PHP 5.4 到 PHP 8.1 中工作（截至目前）。[/notice]
現在您已經運行了測試，下一步是確保修復測試中發現的問題。
代碼覆蓋率
運行這些測試是發現跨版本不兼容性的最可靠方法。
這樣做時，請注意測試的代碼覆蓋率：
- 假設您有一個函數 A 並為它編寫了測試，並且函數 A 調用函數 B、C 和 D 作為函數中邏輯的一部分。
- 函數A的測試是為了測試函數A的邏輯而寫的，但是在測試的時候也會調用函數B、C、D。 對於函數 B、C 和 D，您通常只測試“快樂路徑”——一切順利的情況——因此，這些函數也還沒有完全測試，儘管這些函數中的（部分）代碼是在功能 A 的測試期間執行。
- 對於您的每個測試，請指出具體測試的代碼。 你可以通過給每個測試一個@covers 來做到這一點。這樣，B、C 和 D 就不會被“計算”在代碼覆蓋率計算中，這樣你就可以看到你的代碼的哪一部分被測試覆蓋了。
開發人員經常編寫和測試——有時甚至是在不知不覺中——為了“快樂之路”。 在這些情況下，還需要測試將意外數據傳遞給函數時會發生什麼。 僅使用預期值/類型進行測試是不夠的。
上面引述的第二部分經常被遺忘，而它可能比第一部分更重要。 如果傳遞的類型不正確會怎樣？ 你收到錯誤信息了嗎？ 還是帶有函數的變量繼續正常運行？ 如果將意外值傳遞給函數怎麼辦？
請務必使用意外變量、類型和值測試您的函數。 只有這樣，您才能依靠您的測試來發現新的 PHP 版本可能導致的問題。
PHP 越來越嚴格
PHP 在處理 PHP 自身函數的“類型”以及動態屬性等方面變得更加精確（嚴格）。 這些更改通常旨在幫助開發人員交付無錯誤代碼（嗯，錯誤更少的代碼）。 但這可能會給基於 PHP“舊”原則編寫的現有代碼帶來相當大的升級障礙。
由於在 PHP 中需要更多有用的錯誤消息，您可以看到使現有代碼適合新的 PHP 版本需要越來越多的時間。 與升級代碼以使其適用於 PHP 8.1 相比，在大多數情況下，使適用於 PHP 5.6 的代碼適用於 PHP 7.0 只花費了一小部分時間。 儘管事實上 PHP 7.0 是“主要”版本，而 PHP 8.1 是“次要”版本。
在許多情況下，測試仍然是確定需要修改哪些內容以支持新版本的唯一可靠方法。
可以使用各種工具進行單元測試，包括：
- PHP單元
- 嘲諷
- 行為，
- 故事播放器
許多這些工具都是基於 PHPUnit 構建的，或者與 PHPUnit 結合使用。
最終，使用什麼工具並不重要。 最重要的是您進行測試，並讓測試在新的 PHP 版本上運行。 這個步驟有時會非常棘手，但幸運的是，如前所述，有用於此的工具，例如 PHPUnit Polyfills。
集成測試
集成測試是我們將在靜態分析和單元測試之後執行的下一步。 集成測試是在更大的上下文中測試現實生活情況，而不僅僅是“代碼單元”。 這些包括使用活動（測試）數據庫進行測試或使用外部 API 進行測試，僅舉兩個示例。
因此，當您在 WordPress 上下文中測試插件或主題的代碼並使用真實版本時，根據定義，這些都是集成測試。
WP Test Utils（同樣由 Juliette 編寫並由 Yoast 贊助）是一個優秀的集成測試工具。 WP Test Utils 提供編寫集成和單元測試的工具，其中使用 Brainmonkey 和 Mockery“模擬”WordPress，其中“偽造”常用的 WordPress 功能，以便您測試自己的代碼而不是 WordPress 代碼。
與 WordPress 的集成測試是一個更棘手的故事，因為它涉及與 WordPress 和 WordPress 的測試套件的集成。 根據插件或主題支持的 WordPress 版本，您必須考慮 WordPress 本身支持哪些 PHPUnit 版本以在不同的 PHP 版本上運行測試。
例如，WordPress 5.6 到 5.8 使用 PHPUnit 5 到 7 來測試 PHP 5.6 到 PHP 8.0，但從 WordPress 5.9 開始，WordPress 本身也使用 PHPUnit Polyfills 以獲得更廣泛的支持。 WP Test Utils 充當克服所有這些差異的橋樑。
想詳細了解如何針對多個不同版本的 WordPress（包括 WordPress 5.9 及更高版本）運行集成測試？ 然後在 WordPress 的網站上閱讀它。
手動測試
現在您已經完成了單元測試和集成測試並修復了您發現的所有問題，是時候進行手動測試了。 您的站點正在運行，並且您自己的代碼正在運行，但您還使用了插件 A、B 和 C。您知道這些插件是否兼容嗎？
例如，與插件的作者核實一下，看看他們是否表明它與 PHP 8.x 兼容。 當然，接下來的問題是如何測試插件。 這裡的答案通常是：孤立地。 該插件的功能通常在沒有其他活動插件的情況下單獨與 WordPress 一起進行測試。 即使在這些測試中使用了其他插件，也有可能並非您使用的所有插件都在測試中，因此對這樣的兼容性聲明持保留態度。
例如，具有 3 個插件（A、B 和 C）的 WordPress 站點。 例如，插件 B 可能通過過濾器返回錯誤的變量類型，而使用相同過濾器的插件 C 想要使用該過濾器。 這可能會導致致命錯誤，因為類型不再是預期的類型。 插件 C 然後被視為錯誤消息的罪魁禍首，即使插件 B 才是真正的罪魁禍首。
插件互操作性——在孤立測試時不可能發現不兼容性。 插件越活躍，出錯的可能性就越大。 例如，將頁面請求從實時網站傳遞到暫存環境（啟用錯誤日誌記錄）以發現實際出了什麼問題是非常有益的。
對於此類問題，網站所有者通常只會看到一條消息，指出上次執行的代碼（在本例中，來自插件 C）有錯誤，即使插件 C 不一定是問題的原因。
在大多數情況下，涉及大量手動、人工工作，並且需要大量的肘部潤滑脂來檢測和修復這些問題。 這可以使用端到端測試自動進行，但我們沒有看到這種情況在 WordPress 中發生太多。
測試使用插件的可用性
對於開發人員和開發團隊：僅在測試可用時才接受代碼。 通過這種方式，您可以確保需要更少的手動測試，從而節省大量時間。
如果您想購買商業插件或主題，請質疑其測試策略。 這樣，我們就可以在 WordPress 社區的開發人員/開發團隊中共同提高意識，將測試提上議事日程，我們都將從中受益。
測試通常被不公平地視為一種成本，而實際上它可以節省資金。 編寫測試所需的額外投資以大大減少錯誤報告和修復錯誤所花費的時間的形式得到回報。 此外，通過自動化軟件測試，可以更快地完成擴展和修改，因為測試可以快速確認現有功能是否繼續工作。
WordPress 主機和 PHP 8.x 的作用
對於普通站點所有者，非常需要來自主機的指導。 考慮以下：
- 針對 WordPress 核心、插件和/或主題（在某些情況下）與 PHP 跨版本不兼容的客戶的文檔和更新
- 測試選項（例如使用暫存環境）
- 錯誤報告和聯繫支持的方法
這也有利於網絡主機，因為網站所有者經常在出現問題時聯繫主機尋求幫助。 在切換到 PHP 8.0 或 8.1 的情況下，站點所有者應對潛在問題負責，並且所有者為正確準備切換所需的信息越多越好。
將 PHP 8.0 或 8.1 作為 Web 主機提供給客戶是一回事，但在這樣做時，他們必須確保在客戶中建立意識，以便他們意識到可能會出現問題。 建議在與實時版本不同的臨時環境中測試您的站點。 （在 Kinsta 默認情況下可以選擇 PHP 版本。）
WordPress 的最低 PHP 版本
目前，超過 15% 的網站使用 PHP 7.0 或更低版本。 這可以在官方的 WordPress 統計數據中看到。 大約 83% 的 WordPress 網站目前使用 PHP 7.4 或更低版本。 請注意，PHP 目前不再支持任何低於或等於 7.4 的版本。 使用生命週期結束的 PHP 版本可能會導致問題，因為不再發布安全更新。
為避免出現問題，重要的是 WordPress 網站所有者了解並告知允許其網站安全運行的最低 PHP 版本。 就他們而言，站點所有者可以自己修改 PHP 版本（可以在 Kinsta 上修改所有軟件包）或要求他們的主機將站點更新為較新的 PHP 版本。 在極端情況下，您可以切換到支持這些較新版本的主機。
因為WordPress只要求7.4的最低版本，所以很多主機和站主更新站點的動力不足。 儘管事實上 PHP 7.4 已於 2022 年 11 月結束。
如果 WordPress 確實增加了最低 PHP 版本，這可能意味著許多網站將不再與最新 WordPress 版本的更新兼容。 但是，在相當長的一段時間內，將繼續為那些過時的版本發布安全更新。
概括
要為您的網站切換到 PHP 8.0 或更高版本，您或您的開發人員必須執行幾個步驟。 重要步驟包括：
- 靜態分析
- 單元測試
- 集成測試
- 手動測試
切換到 PHP 8.x 時，請確保所有內容都經過正確測試。 這是保證您的站點在較新的 PHP 版本上正常、快速和安全運行的唯一方法。
我們非常感謝 Juliette 參與本文以及她在提到的工具上所做的所有工作！
朱麗葉的照片，由 Jip Moors 拍攝並經許可使用。