成功的 Drupal 7 到 9 遷移背後的科學（以及其中一些失敗的原因）

還記得貴公司的每個人都喜歡（或至少容忍）您被迫遷移到新系統的偉大網站嗎？ 而你信任的團隊可能會比他們咀嚼的更多？ 曾經可能是一個完美的外觀和功能的網站，現在變成了一堆奇怪的問題、性能不佳，或者有時，一個幾乎無法使用的網站。

如果這聽起來很熟悉，並且在將 Drupal 7（或 6）站點升級到 Drupal 9（或 8）後遇到了奇怪的問題，請閱讀本文直到最後。 我們將探討站點所有者在將 Drupal 7（或 6）升級到 Drupal 9（或 8）後面臨的常見問題以及如何解決這些問題。 這不會涵蓋我們在進行遷移救援時看到的所有問題，但至少應該讓您達到晚上可以入睡的程度。

Drupal 7 到 9 升級 - 基本挑戰

您可能會問自己的第一個問題是：“為什麼？” 從平台的角度來看，從 Drupal 7 升級到 Drupal 9（Drupal 8 現已被淘汰）似乎不應該那麼難。

好吧，Drupal 8 改變了一切。 它進行了全面的架構大修，因此 CMS 可以更具可持續性、相關性並且從長遠來看更容易掌握。 它採用了現代技術和框架，如面向對象編程、Symfony、Twig、最新的 PHP 版本等等，還允許 Drupal 社區通過提供更廣泛的技能來幫助構建 Drupal，從而呈指數級增長。 這意味著，現在更容易找到專家來構建和維護您的 Drupal 網站。 好消息是，在初始遷移之後升級到任何未來版本的 Drupal（如 Drupal 8 到 Drupal 9）都非常容易，並且不需要重建。

但是回到手頭的問題，許多組織仍在從Drupal 7 遷移到 9 ，這確實涉及網站的完全重建。 重建本身足夠複雜，無需維護當前的內容結構，它可以讓最有經驗的開發人員適應。 在大多數情況下，大型網站需要更多關注，因為它們往往有多個貢獻和自定義模塊，沒有直接的升級路徑。 所有這些共同為錯誤打開了無限的機會。

對於沒有嘗試過此類遷移的團隊，通常情況下，第一個 Drupal 7 到 9 遷移錯誤是缺乏準備。 成功遷移 Drupal 的第一步也是最重要的一步是進行徹底的遷移審計，以分析當前網站結構的每一個細節。 該報告不僅可以幫助您評估遷移的影響，還可以讓您深入了解需要改進的領域。 下一個最重要的步驟是決定是否允許專門的 Drupal 開發合作夥伴（日復一日地使用 Drupal 的人）進行遷移。 就像您更喜歡心臟外科醫生而不是整形外科醫生進行搭橋手術一樣； 擁有一家專注於 Drupal 的專業公司來構建您的 Drupal 網站將導致成功遷移。

常見的 Drupal 7 到 9 遷移挑戰

在從 Drupal 6/7 遷移到 8/9 之後，最常見的挫折來源之一是在處理問題時不知道從哪裡開始。 無論有沒有編碼技能，你如何找出真正的問題所在？ 簡單 - 檢查您的錯誤日誌。 我知道，聽起來您正在打開另一罐蠕蟲試圖理解日誌所說的內容，但我們將引導您了解下面的常見問題。

讓我們直接深入探討 Drupal 站點所有者在從 Drupal 7 遷移到 Drupal 9 後面臨的一些最常見問題。

網站幾乎沒有啟動/損壞

1. 服務器問題：如果您沒有足夠的權限訪問您的服務器，您的服務器可能會受到威脅。 深入了解錯誤日誌將幫助您了解問題的根源。 如果是服務器問題，請確保您有足夠的權限訪問您的服務器。 如果您遇到空間短缺問題，請聯繫您的託管服務提供商以增加您的內存限制。 如果這沒有幫助，請向他們提出一張票，並提及您的服務器問題。
2. 自定義代碼：如果您的 Drupal 6/7 網站比預期的更複雜，那麼可能不是在遷移之前評估自定義代碼並正確映射它們，而是執行簡單的提升和轉換。 如果您在頁面加載時觸發了自定義條件，並且沒有找到與之關聯的自定義代碼，那麼您最終會得到一個損壞的頁面。 首先要做的是檢查您是否在遷移審核中正確評估了網站（如果您這樣做了），以檢查自定義模塊和代碼。 如果問題是由於自定義條件造成的並且缺少代碼，您將需要 Drupal 開發人員來創建自定義代碼實現。 理想情況下，應該在遷移任何內容之前創建自定義代碼。
3. Core/Contrib 模塊：有時您可能會在已經有解決方案/補丁的核心或貢獻模塊上遇到已知問題。 一些研究可以幫助確定這一點。 找到並應用補丁，你應該很高興。
4. 過時的 PHP 版本/庫：您的新 Drupal 站點可能仍在運行舊版本的 PHP 或您的代碼所依賴的庫。 確保您的網站實現了最新版本的 PHP 和其他庫。 還要檢查是否滿足所有系統要求和配置。

無法編輯頁面（權限問題）

1. 500 錯誤：如果您因為遇到 500 內部服務器錯誤而無法編輯頁面，這可能是由於各種原因（配置錯誤、代碼錯誤、索引錯誤、聚合等）。 但是，更常見的原因之一是它可能是由於字段格式之間的不匹配或缺少字段。 例如，如果您的 Drupal 7 站點中的日期字段未以正確的格式遷移，或者該值未轉換為 Drupal 9 格式，則會引發錯誤。 另一個例子是，如果在 Drupal 7 中您一直使用圖像字段，但在 Drupal 9 中，您使用的是媒體字段。 解決此問題的最佳方法是糾正遷移腳本以正確存儲數據。 如果只有幾個字段要編輯，您還可以創建掛鉤更新。
2. 403 錯誤：通常，403 錯誤是因為權限轉移不正確。 檢查權限是否設置正確。 如果您使用一個模塊來管理您的用戶，請檢查它在 Drupal 9 中是否可用。有時，您可能有掛鉤或事件訂閱者限制對某些用戶的訪問。 檢查這些條件並確保它也在您的新安裝中實施。
3. 權限頁面沒有響應：您的 Drupal 站點可能正在實施一些自定義代碼來處理權限。 如果此代碼未在新的 Drupal 9 站點中實現，您可能無法查看或編輯（或兩者）權限頁面。 有時，我們會看到在沒有正確遷移其角色和用戶配置文件的情況下批量遷移用戶的情況。 作為標準做法，在遷移權限之前，開發人員應創建自定義權限並將其分配給人員/權限中的角色。

糟糕的網站性能

1. 不必要的模塊：模塊是您的 Drupal 站點的構建塊，因此您也需要遷移它們。 但有時我們會看到過時的不必要的 Drupal 7 模塊移至 Drupal 9，這可能會導致各種問題。 特別是因為它們會影響您的網站。 以下是您的某些模塊不需要遷移的一些原因：
   • 該模塊（或其功能）已移至 Drupal Core。 例如，媒體貢獻模塊在 Drupal 8.5 中移至核心，這消除了使用貢獻模塊的需要。
   • 它的功能很簡單，可以插入到另一個自定義模塊中。 例如，如果 node::postSave 模塊僅用於一種或兩種內容類型，以便在創建節點後選擇用戶應該去哪裡，則可以將代碼移至自定義模塊。
   • 模塊的要求需要重新評估。 有時，可用性的微小變化可以極大地提高網站性能。 例如，除非內容營銷團隊龐大且分散，否則所有網站都不需要內容審核模塊。 Drupal 的核心編輯工作流功能（草稿、發布）足以滿足大多數不需要復雜/詳細工作流的業務需求。
   • 有時，子模塊與模塊一起安裝，但很少/從不使用。 應刪除此類子模塊。
2. 複製相同的架構：雖然簡單地舉起手來轉移並從遷移中撣去灰塵會更容易，但它幾乎從來都不是一個好方法。 特別是如果較舊的（Drupal 6/7）架構混亂且不夠健壯。 業務邏輯/需求的變化也可能需要完全重新架構。 徹底的現場審核將準確告訴您需要保留哪些模塊以及可以安全刪除哪些模塊。

第三方集成不再有效

1. 過時的 API 版本：如果您的網站連接到不同的第三方工具，如 Salesforce、Marketo、Mailchimp 等，執行不當的遷移可能會影響這些集成的工作方式。 通常是您在 Drupal 集成模塊中調用的 API 是舊版本。 唯一的解決方法是集成應該用最新版本的第三方 API 編寫。
2. 集成模塊問題：您需要檢查第三方 API 是否在集成模塊中被正確調用。 參數是否正確傳遞？ 檢查它們是如何設置和檢索的。 檢查該集成模塊的問題隊列。 可能有需要應用的可用補丁。 需要進行適當的測試以確保 API 已正確移植到 Drupal 9。

其他常見問題和修復

1. 模塊安裝：始終使用 composer 安裝模塊。 這將避免由於無效/不可用依賴項導致的錯誤。
2. 遷移源不匹配：無論您的遷移源是什麼（CSV、數據庫、JSON、XML），請確保源字段與目標字段匹配。 如果您使用 CSV 作為源，請記住導入順序 - 映射內容類型的優先級很重要。
3. 圖片路徑：很多時候，用戶直接在 CKEditor 內容中添加圖片。 這些圖像在遷移時並不總是轉到指定的路徑，因為它們的位置通常與其他媒體文件所在的位置不同。 精心計劃的遷移應該解決這個問題。
4. SEO：疏忽的 Drupal 7 到 9 遷移會以多種方式影響您網站的 SEO。 最重要的問題之一是鏈接斷開。 確保保留現有的 URL 結構和導航，因為任何更改都可能導致大量斷開的鏈接。 需要進行完整的 SEO 審核，以確保道路上沒有顛簸。
5. Drupal 7 風格：經常會出現 Drupal 7 到 Drupal 9 的遷移問題（尤其是性能問題），因為開發人員使用與 Drupal 7 相同的編碼風格，而不是適應 Drupal 8 帶來的變化。示例， （a）你殺死的方式頁面緩存在 Drupal 8 中非常不同。 (b) Drupal 8 具有內置的配置管理，但它通常沒有以正確的方式實現或在每個環境中都沒有得到很好的維護。 (c)我們還遇到了 Drupal 8 項目仍在實施過程代碼樣式的實例。