如何使用 MU-Migration 簡化 WordPress 多站點遷移

將獨立的 WordPress 站點遷移到站點網絡（或“多站點”）環境是一項乏味且棘手的工作，反之亦然。 WordPress 導入器適用於更小、更簡單的網站，但仍有改進的餘地。 它導出內容，但不導出站點配置數據，例如小部件和定制器配置、插件和站點設置。 Importer 還難以處理大量內容。 在本文中，您將學習如何使用 MU-Migration（一個 WP-CLI 插件）來簡化此類遷移。

了解多站點

WordPress 多站點允許您在同一個 WordPress 安裝中運行多個網站。 它通常被稱為“多站點網絡”。 WordPress.com 可能是多站點網絡的最大示例，在同一個 WordPress 實例中運行數千個站點。

WordPress 多站點非常適合多種用例，其中一些包括：

• 您的客戶可能有多個屬性，將其所有站點整合到一個獨特的 WordPress 安裝中，共享一個域（但不限於此）可能是有意義的。

• 設置完成後，這是一個簡單而直接的過程，可以啟動新站點並利用網絡中已有的主題和插件

深入了解多站點的工作原理超出了本文的範圍，但您可以查看以下鏈接：

• “創建一個網絡”，Codex，WordPress.org

• “WordPress 多站點：實用功能和方法”，Smashing Magazine 的 Kevin Leary

了解挑戰

單個站點和 WordPress 多站點的結構之間的差異是相當合理的。 對於多站點，每個子站點都有自己的一組數據庫表，但在所有站點之間共享的用戶表 ( wp_user ) 除外。 這在 WordPress 中的工作方式是每個子站點的表集都將站點的 ID 添加到每個表名（ wp_X_posts 、 wp_X_postmeta 、 wp_X_options ）。

這種數據庫結構本身已經引入了一些複雜性。 例如，您如何將子站點從多站點遷移到單個安裝？ 顯然，您不能只將數據庫導出和導入到單個安裝中——表名不同！ 您需要重命名導出的.sql文件中的表，或者在導入表後使用ALTER TABLE SQL查詢重命名這些表。 相反的方式也是如此：如果您將單個站點導入多站點，則表前綴也必須更新。 聽起來工作量太大了，對吧？

多站點中的用戶表是全局的，這意味著您不能只從單個站點導入用戶表，因為它會完全覆蓋多站點全局用戶表。 如果您進行相反的操作，從 WordPress 中提取子站點並導入到單個站點，您將攜帶網絡的所有用戶，即使是那些不屬於正在遷移的子站點的用戶。 此外，如果將一個子站點從一個多站點遷移到另一個，導出用戶的表是完全不可行的。

最好的解決方案是單獨導出用戶，但它引入了另一個問題：當用戶被導入時，他們會得到不同的 ID。 為了解決這個問題，需要跟踪新用戶的id，創建一個映射表，並使用映射表來更新WordPress中所有對用戶ID的引用！ 再次，太多的工作，對吧？

這些只是處理此類遷移時可能面臨的挑戰的兩個示例。 還有很多其他的小事情也需要處理，比如將上傳文件夾移動到正確的位置，遷移數據庫中引用站點 ID 的記錄等。

滿足 MU-遷移

MU-Migration 是我在處理多個客戶端遷移時創建的 WP-CLI 插件，後來由 10up 開源。 它旨在簡化將站點從單個 WordPress 站點移動到多站點實例（反之亦然）的過程。 它本質上將所有內容導出到一個 ZIP 包中，然後可用於在所需的 WordPress 安裝中導入站點。

它通過將站點的內容和可選的主題、插件和上傳文件夾導出到一個 zip 包中來工作，該壓縮包可以輕鬆導入到另一個 WordPress 安裝中。 使用 MU-Migration 時，您無需擔心遷移的底層技術細節。 它會簡單地為您處理所有這些，因此您可以專注於重要的事情：為您的客戶提供成功的遷移。

安裝 WP-CLI 和 MU-Migration

為了使用 MU-Migration，您首先需要安裝 WP-CLI，這是官方的 WordPress 命令行工具。 安裝 WP-CLI 就像在您的服務器上運行以下命令一樣簡單：

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

運行這些步驟後，只要您在 WordPress 根目錄中，您就可以通過在任何 WordPress 安裝中鍵入wp來執行 WP-CLI。

例如，在您的 WordPress 安裝文件夾中，嘗試運行以下命令：

 $ wp theme status

這是一個簡單的命令，將列出所有可用的主題，突出顯示當前處於活動狀態的主題。

最後，要安裝 MU-Migration，您可以利用package install命令。 使用以下命令下載並安裝 MU-Migration 作為 WP-CLI 插件。

 $ wp package install 10up/mu-migration

運行簡單的遷移

MU-Migration 的使用非常簡單。 對於我們的第一個場景，我們要將單個 WordPress 站點移動到 WordPress 多站點安裝中。

導出單個站點

我們將從導出單個站點開始。 為此，我們需要使用export all命令：

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

上面的命令會將整個站點導出到 ZIP 包中，標誌--themes 、 --plugins和--uploads是可選的，並且將分別在導出中包含當前主題、所有插件和上傳文件夾。 根據您網站的大小，完成該過程可能需要一些時間，但對於大多數網站，導出過程不應超過幾分鐘。

完成後，它將創建一個名為single-site.zip的文件，其中包含所有站點的數據、主​​題和插件以及上傳目錄。 下一步是將其移動到 WordPress 多站點所在的服務器。 您可以使用首選的 SFTP 客戶端或更強大的解決方案，例如rsync 。

將單個站點導入多站點

使用多站點服務器中的導出文件，您需要做的就是使用 WordPress 多站點目錄中的導入命令； 不用說，WP-CLI 和 MU-Migration 都需要安裝在目標服務器上。

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

上面的命令將獲取single-site.zip文件，將其解壓縮並將所有內容導入多站點。 它將在您的網絡中創建一個新的子站點。 --new_url參數是可選的； 它將指示 MU-Migration 執行搜索和替換，以便將所有出現的導出站點的站點 URL 替換為指定的站點。 當遷移包括 URL 的更改或者您在本地導入，甚至在暫存環境中導入時，此參數非常方便。

導入過程通常需要更長的時間，並且取決於您要導入的站點的大小，但不要擔心，MU-Migration 會在遷移運行時讓您隨時更新。 該過程完成後，MU-Migration 將通知您導入站點的最終 URL。 強烈建議刷新服務器上運行的所有緩存層，特別是 Memcache 或 Redis。

重新運行遷移

在進行遷移時，通常先進行試運行，目的是在運行最終遷移之前進行測試，這通常意味著在目標多站點安裝中進行另一個導出和重新導入。 但是，請注意，在我們的第一個遷移示例中，MU-Migration 在網絡中創建了一個新的子站點，以便在其上導入單個站點。 再次運行完全相同的命令將導致創建另一個子站點，這與我們所期望的不完全一樣。

幸運的是，可以指定一個blog_id ，它告訴 MU-Migration 用指定的blog_id覆蓋子站點。 例如，假設之前的導入命令創建了一個 ID 為2的子站點，並且您想要重新運行遷移。 您可以執行以下操作：

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

如果您不知道blog_id ，您可以通過網絡管理設置或運行$ wp site list來獲取它。

從多站點安裝中提取子站點

MU-Migration 還支持從多站點安裝中提取子站點並將其導入另一個多站點或單個站點。

對於這兩種情況，我們將從多站點安裝而不是從單個站點運行導出命令； 這意味著我們需要一種方法來指定要導出的子站點。 為此，我們只需將--blog_id參數傳遞給導出命令：

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

在這個例子中，我們導出一個 ID 等於 3 的子站點； 這將創建一個 ZIP 文件，可以將其導入另一個多站點或單個站點。 導入到單站點和多站點的命令完全相同，MU-Migration 會檢測它是否在多站點上運行並自動調整。 附帶說明，當導入另一個多站點實例時，您還可以指定--blog_id參數來覆蓋現有子站點。

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

運行大型遷移的提示

雖然前面的示例非常適合中小型遷移，但將大型站點遷移到多站點或從多站點遷移可能需要相當長的時間。 在本節中，我將分享一些在進行類似企業的遷移時學到的一些經驗教訓。

創建遷移計劃

數據遷移通常是必要的，但它是許多項目中被忽視的部分。 遷移可能既麻煩又復雜，但如果計劃得當，它可能是無痛的。 創建遷移計劃應該是任何遷移項目的第一步。

典型的遷移計劃包括以下內容：

• 遷移對任何生產編輯過程的影響（即內容凍結、不同的遷移要求）。

• 遷移預計運行多長時間？

• 如何恢復備份？ 如何處理失敗的遷移？

• 導出過程將如何影響站點的性能？ 許多站點無法在高峰期進行數據庫導出。

作為一般經驗法則，遷移應盡可能無縫，理想情況下，在發布之日，所有繁重的工作都已經完成，只應執行嚴格必要的步驟。 這意味著您應該在實際發布日期之前遷移所有可能的內容，因為這將為您提供修復錯誤和 QA 的空間。 如果它是一個新的站點構建並且您正在遷移數據，您通常可以從內容凍結窗口中受益並提前移動您的內容。 如果可能，您還可以使用策略逐步移動您的內容。 查看下一部分以獲取此技術的示例。

儘管多次被忽視，但適當的遷移計劃可以避免遷移中的各種問題。 不要讓意外情況導致您的遷移失敗，請提前計劃！ 有關規劃遷移的更深入討論，我鼓勵您查看 10up 最佳實踐的遷移部分。

使用 Rsync 逐步複製上傳

大型網站的上傳文件夾可能非常大，將其壓縮為 ZIP 文件以供以後提取並不總是最好和最快的解決方案。 還有其他幾種方法可以將上傳文件夾複製到目標服務器。 企業類遷移的常用工具是rsync ，它可以比使用標準 SFTP 解決方案更快地在服務器之間傳輸文件，而且它還可以暫停和恢復傳輸。 它會跟踪已經傳輸的內容，這意味著我們可以逐步同步我們的文件。 例如，您可以在實際遷移前幾天開始同步文件，以便為您爭取一些時間。 然後，在遷移當天，您需要做的就是同步文件，以確保自上次同步以來添加的所有內容都傳輸到目標服務器。

這種方法唯一需要注意的是，您需要手動將上傳的子目錄移動到正確的位置，因為多站點的上傳文件夾結構略有不同：每個站點都有自己的子文件夾，其名稱是站點的 ID .

作為最後一個示例，讓我們看看如何將大型單站點遷移到多站點實例。 我們將從將單個站點導出到 ZIP 包並在目標服務器上運行試運行測試開始。 此時，任何人都無法訪問該站點，因為該域仍指向舊服務器，這意味著您可以安全地將主機文件指向新服務器以測試遷移。 您還可以在目標站點上啟用諸如限制站點訪問之類的插件，以確保它不能以任何方式公開訪問。

對於我們的試運行測試，我們會在計劃的遷移日期前幾天或幾週導出站點以進行測試並了解該過程需要多長時間。 請注意，上傳文件夾不包括在內。

先做空運行

始終先進行試運行。 理想情況下，試運行應該發生在實際服務器上或具有類似服務器堆棧的暫存環境中。

考慮使用--mysql-single-transaction標誌

import 命令還支持--mysql-single-transaction標誌，它將 SQL 導出包裝到單個事務中，以一次提交來自導入的所有更改，防止寫入壓倒數據庫服務器，尤其是在集群 MySQL 環境中。

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

使用rsync ，我們可以輕鬆傳輸生成的導出文件：

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

然後我們在目標服務器上運行導入命令：

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

現在我們需要知道新創建的子站點的blog_id是什麼； 我們可以通過運行獲得該信息：

從上述命令的輸出中，我們知道我們的站點已使用 ID 2 導入。我們需要使用rsync正確移動上傳文件夾。 從單站點服務器，我們將運行以下命令：

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

上面的命令會將整個上傳文件夾複製到多站點安裝的正確位置，該位置位於站點文件夾下，並且位於其名稱只是站點 ID 的文件夾內（在本例中為 2）。 此時，我們現在可以編輯主機文件，將單站點域指向多站點服務器； 然後我們可以進行一些測試以確保遷移按預期工作。

對於最終遷移，一切都將是相同的，除了我們將--blog_id=2傳遞給導入命令：

 $ wp mu-migration import all site.zip --blog_id=2

作為一個好處，上傳同步會更快，因為rsync只會傳輸自上次同步以來已更改或添加的文件。

結論

遷移到多站點或從多站點遷移很困難，本文介紹的工具通過將工作量減少到幾個 CLI 命令來簡化整個遷移過程。 MU-Migration 已經在生產中積極使用了一年多，是一個完全開源的項目。 該插件是在 Github 上開發的，歡迎提出請求！