將一個WordPress站點、外掛或主題升級到新的PHP版本是一項經常出現的任務。但是，如何儘可能有效地做到這一點？你怎麼知道你不會忽略任何東西？是否有一個路線圖？
在這篇文章中，我們將解決這些問題（以及更多），並看看為你的WordPress網站、外掛或主題順利過渡到PHP 8.x所涉及的內容。
PHP 8.x – 有何變化
關於這些變化的概述，我們推薦下面的文章：
讀完這些文章後，你將完全瞭解到PHP 8.x的變化以及你需要做什麼來使你的PHP專案順利執行。
如果你不確定什麼是最好的開始，沒問題。我們將在本文中儘可能全面地向你解釋如何切換到PHP 8.x。
切換到PHP 8.x：如何開始
切換到 PHP 8.x 聽起來很簡單，技術上也是如此。許多主機允許你在管理面板中指定你的網站要使用哪個版本的PHP。
但在這之前，有一些事情你需要確定一下。根據你的知識和經驗水平，我們建議如下。
- 如果你已經用標準的主題和外掛建立了自己的WordPress網站，而沒有太多的PHP知識，請聘請一個開發人員或機構來調查你的網站是否適合執行在PHP 8.x上。你是否在尋找一個可以幫助你的第三方？那麼請看我們的合作伙伴頁面，上面列出了幾個值得信賴的公司可以幫助你。
- 如果你的WordPress站點是由外部機構、開發商或代理公司建立的，請聯絡他們詢問你的站點是否能執行在PHP 8.x上。
- 如果你已經建立了你的WordPress站點–例如用你自己的定製主題，或自行開發的外掛–我們在下面為你提供了一個路線圖。
如果你的網站屬於前兩類中的一類，我們當然邀請你閱讀文章的其餘部分，但我們不建議你自己開始測試網站的PHP 8相容性。把它留給專業人士吧。
無論你選擇什麼，我們都建議你不要只是把你的實時站點切換到PHP 8，然後 “看看它是否工作”。你是否對你的網站會是什麼樣子感到好奇，並迫不及待地想看到它在 PHP 8 上執行？那就在一個暫存環境中開始測試。一個好的主機將允許你輕鬆地建立一個暫存環境。
如果你在暫存環境中沒有看到任何問題，這並不一定意味著實際上沒有任何問題。下面的路線圖將告訴你原因。
PHP 8.x相容性測試
測試：好軟體的關鍵詞。即使是WordPress網站及其元件，如主題、外掛和WordPress核心，測試也是確保不發生你不希望發生的事情的手段。
一個軟體開發專案主要由測試組成。在這篇文章中，我們特別看一下可以幫助你順利過渡到PHP 8.x的測試。
在這篇博文中討論了以下型別的測試：
讓我們更仔細地看一下我們可以進行的不同型別的測試。
Static Analysis (or Static Testing)
作為一個PHP開發者，你可以採取的第一步是用各種工具對你的程式碼進行靜態分析。靜態分析是在不執行程式碼的情況下分析軟體的過程。通過靜態分析，可以發現錯誤，發現與PHP 8.x的相容性問題，執行編碼標準（例如，WordPress編碼標準），甚至修改和清理程式碼也是可能的。
Tools for Static Analysis
你可以用各種工具進行靜態分析，如：
在寫這篇文章的時候，並不是所有的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開始被保留），等等。
來自PHPCompatibility GitHub頁面的螢幕截圖
Psalm 和 PHPStan 是很好的補充，可以通過執行與變數型別相關的額外檢查來幫助你。這些工具的缺點是需要大量的配置才能在 PHP 8.0 和 8.1 上獲得報告。即使它們是成功的，也會有許多誤報。假陽性是指由於靜態分析的侷限性而錯誤地給出的通知。
要正確解釋這兩個工具的結果，需要健全的知識，但這些知識可以幫助你識別PHPCompatibility無法發現的其他不相容情況。如果你想了解更多關於Psalm和PHPStan的資訊，請看它們的文件。
總結：
- 用PHPCompatibility, Psalm, PHPStan進行靜態分析
- 解決所有合法問題
Juliette專家的建議
在測試時，在你的 php.ini / wp-config.php 檔案中，將 error_reporting 設定為 -1。這是因為E_ALL，取決於PHP版本，並不包含所有內容。
只有從8.0開始，E_ALL才包含所有內容。另外，開啟 log_errors，在日誌檔案中回看通知。
不要在實時網站上開啟錯誤日誌，因為這可能導致延遲，因為它需要將資料寫入檔案。因此，在一個暫存環境中做這個，並確保你知道發生了什麼/失誤。
單元測試
過程中的下一步是單元測試。單元測試是一種單獨測試程式碼片段的方法。在單元測試中，將為每個單元開發特定的目標測試。這將涉及到執行不同的場景。最好是將每個場景與其他場景分開測試，這樣測試就可以相互獨立。
當然，光有單元測試是不夠的。它們還需要被執行。單元測試最好使用CI（持續整合）工具，如Jenkins、GitHub Actions或Travis進行自動化。
來自GitHub Actions的一個例子
支援多版本的PHP
作為一個外掛構建者，如果你想支援多個PHP版本，請確保CI中的測試是針對你支援的所有PHP版本執行的。
當然，你也可以只支援較新的版本，這個選擇完全取決於你。
Juliette專家建議
在 GitHub Actions 上，已經可以針對 PHP 8.2 進行測試，這將確保及時得到需要考慮的 PHP 新變化的警告。
用多個版本的 PHP 進行測試需要使用多個 PHPUnit 版本，這取決於 PHP 版本。由於 PHPUnit 多年來引入了一些影響測試編寫方式的變化，這部分可能比較棘手。
為了解決這個問題，你可以使用PHPUnit Polyfills（由Juliette編寫並由Yoast贊助）。這可以讓你編寫官方不支援PHPUnit 9的測試（因此可以在PHP 8.x上執行）。然後Polyfills使你的測試在PHPUnit 4.x到9.x以及PHP 5.4到PHP 8.1（截至目前）中執行。
現在你已經執行了測試，下一步是確保測試中發現的問題被修復。
程式碼覆蓋率
執行這些測試是發現跨版本不相容的最可靠方法。
在這樣做的時候，請注意你的測試的程式碼覆蓋率：
- 假設你有一個函式A，併為它寫了一個測試，函式A呼叫函式B、C和D作為函式中邏輯的一部分。
- 對函式A的測試是為了測試函式A的邏輯，但在測試中也會呼叫函式B、C和D。對於函式B、C和D，你通常只測試 “快樂的路徑”–一切順利的情況–因此，這些函式也還沒有完全測試，儘管這些函式中的（部分）程式碼在函式A的測試中被執行。
- 對於你的每一個測試，指出哪些程式碼是具體被測試的。這樣，B、C和D就不會被 “計算” 在程式碼覆蓋率的計算中，這使你可以看到你的程式碼有哪一部分被測試所覆蓋。
通常情況下，開發人員編寫和測試–有時甚至是在不知不覺中–是為了 “快樂的路徑”。在這些情況下，測試當意外的資料被傳遞給一個函式時會發生什麼也是必要的。只用預期值/型別進行測試是不夠的。
上面這句話的第二部分經常被遺忘，而它也許比第一部分更重要。如果你傳遞一個不正確的型別，會發生什麼？你會得到一個錯誤資訊嗎？還是變數與函式一起繼續正常地投遞？如果向函式傳遞了一個意想不到的值會怎樣？
一定要用意外的變數、型別和值來測試你的函式。只有這樣才能依靠你的測試來發現新的PHP版本可能引起的問題。
PHP正在變得更加嚴格
在如何處理 PHP 自己的函式的 “型別 “以及像動態屬性這樣的東西方面，PHP 正在變得更加精確（嚴格）。這些變化通常是為了幫助開發人員提供無錯誤的程式碼（好吧，就是錯誤少的程式碼）。但這對基於 “舊 “的PHP原則編寫的現有程式碼來說，是一個很大的升級障礙。
由於這種在 PHP 中尋求更有幫助的錯誤資訊的驅動力，你可以看到使現有的程式碼適合新的 PHP 版本需要越來越多的時間。使在 PHP 5.6 上執行的程式碼適用於 PHP 7.0，與升級程式碼使其適用於 PHP 8.1 相比，在大多數情況下只需花費很小的時間。儘管PHP 7.0是一個 “大 “版本，而PHP 8.1是一個 “小 “版本。
在很多情況下，測試仍然是確定需要修改什麼以支援新版本的唯一可靠方法。
單元測試可以通過各種工具進行，包括：
這些工具中的許多都是基於或結合PHPUnit而建立的。
歸根結底，使用什麼工具並不重要。最重要的是你要測試，並讓測試在新的PHP版本上執行。這一步有時會很麻煩，但幸運的是，正如前面提到的，有一些工具可以做到這一點，比如PHPUnit Polyfills。
整合測試
整合測試是在靜態分析和單元測試之後，我們要進行的下一步工作。整合測試是在更大的範圍內測試真實情況，而不僅僅是一個 “程式碼單元”。這包括與活動（測試）資料庫的測試或與外部API的測試，僅舉兩個例子。
所以，當你在WordPress的背景下測試一個外掛或主題的程式碼，並使用一個真實的版本，根據定義，這些是整合測試。
WP Test Utils（同樣由Juliette編寫，由Yoast贊助）是一個優秀的整合測試工具。WP Test Utils提供了編寫整合和單元測試的工具，其中WordPress是用Brainmonkey和Mockery “模擬 “出來的，其中常用的WordPress函式是 “假的”，這樣你就在測試你自己的程式碼而不是WordPress的程式碼。
GitHub上的WP測試工具
與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一起測試的，沒有其他活躍的外掛。而且，即使在這些測試中使用了其他的外掛，也有可能不是所有你使用的外掛都是測試的一部分，所以對這樣的相容性宣告要多加註意。
例如，一個WordPress網站有3個外掛（A、B和C）。例如，外掛B有可能通過一個過濾器返回一個不正確的變數型別，而外掛C使用同樣的過濾器，想要與之合作。這可能會導致一個致命的錯誤，因為該型別不再是預期的。外掛C就會被看作是錯誤資訊的罪魁禍首，儘管外掛B才是真正的罪犯。
外掛的互操作性-不相容性在單獨測試時是不可能發現的。活躍的外掛越多，就越有可能出錯。例如，將頁面請求從一個實時網站傳遞到一個暫存環境（啟用錯誤記錄），以發現實際出錯的地方，這將是非常有益的。
對於這種型別的問題，網站所有者通常只會看到最後執行的程式碼有錯誤的資訊（在這種情況下，來自外掛C），儘管外掛C不一定是問題的原因。
在大多數情況下，涉及到大量的人工工作，並且需要大量的精力來檢測和修復這些問題。這可以通過端到端測試來實現自動化，但我們在WordPress中並沒有看到這種情況。
測試使用的外掛的可用性
對於開發者和開發團隊。只有在有測試的情況下才接受程式碼。這樣，你可以確保減少人工測試，從而節省大量的時間。
如果你想購買一個商業外掛或主題，請質疑其測試策略。這樣，我們共同在WordPress社羣的開發者/開發團隊中建立起意識，讓測試在議程上佔據更高的位置，而我們都會受益。
測試經常被視為–不公平地–是一種成本，而實際上，它可以省錢。編寫測試所需的額外投資以大大減少錯誤報告和減少修復錯誤的時間的形式得到回報。此外，通過自動化軟體測試，擴充套件和修改可以更快完成，因為測試可以迅速確認現有功能繼續工作。
Juliette專家建議
當你想開始寫新的程式碼時：
- 首先寫出一個函式應該做什麼，用什麼邏輯。把它寫成註釋或一系列的註釋。
- 編寫測試。試著把邊緣情況也考慮進去。
- 然後才寫程式碼。
在你在評論中描述的原始邏輯中，有一半會消失，因為它已經被程式碼所取代。留下其餘的評論，因為如果你有一段時間沒有看你的程式碼，它們可以幫助你以後再次理解邏輯。
WordPress主機和PHP 8.x的作用
對於普通的網站所有者來說，來自你的主機的指導是非常可取的。請考慮以下幾點：
- 為客戶提供WordPress Core、外掛和/或主題（在某些情況下）不相容PHP跨版本的文件和更新
- 測試的選項（如暫存環境）。
- 報告錯誤和聯絡支援的方法
這對虛擬主機也有好處，因為當問題出現時，網站所有者通常會聯絡主機尋求幫助。在切換到 PHP 8.0 或 8.1 的情況下，網站所有者要對潛在的問題負責，所有者有越多的資訊來為切換做適當的準備，就越好。
作為虛擬主機，向客戶提供 PHP 8.0 或 8.1 是一件事，但在這樣做的時候，他們必須確保在客戶中建立起意識，讓他們意識到問題可能會浮現。建議在暫存環境中用與實時不同的版本測試你的網站。
WordPress的最小PHP版本
目前有超過15%的網站使用PHP7.0或更低的版本。這可以在WordPress的官方統計中看到。大約83%的WordPress網站目前使用PHP 7.4或更低的版本。請注意，任何低於或等於7.4版本的東西目前都不再被PHP支援。使用報廢的PHP版本會導致問題，因為安全更新已經不再發布。
為了避免問題，重要的是WordPress的站長們知道並瞭解能讓他們的網站安全執行的最小PHP版本。就他們而言，網站所有者可以自己修改PHP版本或要求他們的主機將網站更新到一個較新的PHP版本。在極端情況下，你可以切換到支援這些較新版本的主機。
因為WordPress只需要7.4的最低版本，所以很多主機商和網站所有者沒有足夠的動力去更新他們的網站。而這是儘管PHP7.4在2022年11月達到了它的壽命終點。
如果WordPress真的提高了最低PHP版本，這可能意味著許多網站將不再相容更新到最新的WordPress版本。然而，在相當長的一段時間內，安全更新將繼續為那些過時的版本釋出。
小結
要為網站切換到 PHP 8.0 或更高版本，您或您的開發人員必須執行幾個步驟。重要的步驟包括：
- 靜態分析
- 單元測試
- 整合測試
- 手動測試
當轉換到 PHP 8.x 時，要確保所有的東西都已經過正確的測試。這是保證你的網站在較新的PHP版本上正確、快速、安全地執行的唯一方法。
評論留言