如何使用 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 上开发的，欢迎提出请求！