掌握迁移——更快、更简单、更安全地将站点从 A 迁移到 B 的方法

已发表: 2023-04-09

迁移可能很棘手! 我们都知道当我们看到一个人失败时那种沮丧(或极度恐惧)的感觉,但我们也知道当迁移成功时那种如释重负的感觉。 鉴于迁移的所有复杂性和细微差别,我们如何才能提高成功率并赢回时间来专注于我们真正想做的工作?

无论您是需要将已建立的项目复制到本地计算机,还是需要将少量增量更新部署到生产环境,请跟随我们了解如何加速、简化和降低迁移风险。

视频:掌握迁移——更快、更轻松、更安全地将站点从 A 迁移到 B 的方法

演讲嘉宾:

  • WP Engine 高级产品经理 Kevin Hoffman
  • WP Engine 高级产品经理 Austin Wendt

会议幻灯片:

掌握迁移——更快、更简单、更安全的方式将您的站点从 A 移动到 B 下载

成绩单:

AUSTIN WENDT: 欢迎大家,感谢大家的加入。 我们很高兴有你。 欢迎来到 DE{CODE} 会议。

我叫 Austin Wendt,是 WP Engine 的高级产品经理,致力于构建我们的本地产品。 我的同事 Kevin 和我,你们很快就会在这里见到他们,今天很高兴能与你们讨论更智能的构建——特别是在掌握迁移方面。 因此,我们将涵盖更快、更简单和更安全的方法,将您的站点从 A 点移动到 B 点,这样您就可以对这些开发工作流程充满信心,无论您是将站点带到本地、安全的开发环境,还是随着时间的推移,我们准备好推动该网站上线。

在我们深入讨论之前,我将介绍一个快速议程。所以我们今天要介绍的是我们将介绍我们在 WP Engine 谈论移动代码时喜欢考虑的三种迁移类型。 我们将定义理想的迁移工作流程,并在本演示过程中向您介绍迁移代码的不同方法。 我们将介绍导出您现有的站点,并将其降低——导入到本地开发环境中。

我们将讨论执行首次部署——所以当您第一次上线您的网站时,它看起来像什么,以及实现它的几种方法,然后随着时间的推移同步这两个环境。 因此,让我们深入研究它。

我们想到的三种迁移类型——用户可以尝试完成三种主要选项。 第一种是远程到本地。 因此,如果您已经在 Web 上的某个地方托管了一个站点,并且想将其引入本地(可能是小写的 l)本地环境,那么当您可能开始在客户的现有站点上工作时,它会很有用。 因此,您要么继承了一个新客户,要么客户要求您进行更改并将其带到安全的地方,以便您可以在低风险环境中解决问题。

当您只是想拉取最新的数据库更改时也非常有用,这样您就可以确保您的远程环境和您的生产环境——或者对不起,开发环境——尽可能紧密地匹配。 第二个是本地到远程。 所以当你从你的个人机器返回到某处的托管服务器时——你要么是第一次部署一个完整的站点,要么你已经做了一些代码更改并且你正在推送这些更改,调用准备主题或插件,无论您希望在您的网站上实时反映什么。

第二个——对不起,第三个是远程到远程。 我们今天不会深入探讨这个问题,但您将学习的工具可以帮助您实现这一目标。 当您切换托管服务提供商时,您通常会使用它 - 因此从主机 A 移动到主机 B,或者当您在开发、暂存和生产环境之间移动时,无论您的网站在哪里托管。

因此,我将把它交给 Kevin 来自我介绍,并让我们开始了解理想的迁移流程是什么样子的。 凯文,把它拿走。

凯文霍夫曼: 嘿,谢谢,奥斯汀。 所以我叫 Kevin Hoffman,我是 WP Migrate 的产品经理。 今天,我想从我们将要进入​​的迁移类型的游戏计划开始。 因此,无论何时您要从远程环境进入本地计算机,然后备份到远程主机,这都是一项艰巨的任务。 但我们希望您在本演示文稿中留下一个解决方案的游戏计划,以便您可以自信地自己进行这些迁移。

首先,我们要从旧主机中删除现有站点。 因此,这将包括使用 WP Migrate 的完整站点导出。 然后我们将移动到 Local,在那里我们可以进行本地开发更改,然后将该站点部署回我们的新主机。

因此,为了开始工作,我将使用 WP Migrate 进入完整的站点导出流程。 您可能会问自己,为什么在这种情况下我们要使用完整的站点导出? 为什么不直接在两个环境之间推或拉? 好吧,有几个原因。

首先,我将使用 WP Migrate 的 Pro 版本,但您也可以使用 WP Migrate Lite,这是我们在 WordPress 插件目录中的插件的免费版本。

我们在这种情况下使用完整站点导出的四个主要原因首先是因为它是一种单向迁移。 我们想离开远程主机,而且我们没有回去的计划。 也没有现有的本地安装可供我们将站点移入。 如果有的话,我们可以使用推送迁移或拉取迁移来将站点下载到本地机器中。 但是因为没有现有的安装,拖放导入到本地是最有意义的。

最后,通过进行完整站点导出,我们还可以获得免费备份。 整个站点将封装在一个捆绑的 zip 文件中,这是您进行任何未来更改之前的一个很好的备份。

因此,为了让事情开始,让我们进入 WP Migrate 看看它是如何工作的。

因此,当您第一次打开 WP Migrate 时,您面前将有六个操作。 因为我们希望尽快将站点从远程主机中取出,所以我们将选择导出操作。 打开导出配置文件使我们能够配置数据库选项,以及媒体、主题、插件和 WordPress 核心文件。

让我们继续,从数据库配置开始。 现在,如果我愿意,我可以从这次迁移中排除某些表或发布类型。 但现在,我想使用默认配置,只是将整个站点从远程主机中取出。 我确实想在我们要导出的站点上提及标准查找和替换字段,例如 URL 或本地 WordPress 安装路径。

现在,如果您正在进行手动迁移,您可能希望移动这些值并编辑它们以匹配目标。 然而,因为我们使用的是 Local,它足够聪明地为我们处理这个查找和替换,所以我们实际上不必填写这些可选字段。 我们可以将它们留空并继续前进。

接下来是自定义查找和替换。 这是在我的 WordPress 数据库或我的网站内容中搜索任何字符串的能力。 例如,也许我有一个旧公司名称,我想用我的新公司名称替换​​它,我可以通过这些自定义查找和替换字段来实现。 我可以根据需要添加额外的行。

这样就可以处理数据库。 让我们进入媒体上传。 现在,因为我要移动整个站点,所以我想选择导出所有媒体上传。 但我确实想排除一些文件,如日志、备份和缓存,它们可能会使导出膨胀。

当我们进入主题文件时,我想包括我所有的主题。 这次不是,只是活跃的主题,因为我只关心积极影响现场的主题。

同样,对于插件——我只想导出我的活动插件。 对于 WordPress 核心文件,我确实想继续并包含这些文件,因为我想确保我的 WordPress 核心与我从中导出的网站的确切版本相匹配。

配置文件完全配置后,我现在可以开始导出,这将快速遍历我的数据库表、媒体上传、主题、插件和 WordPress 核心文件。

此时,数据库和站点内的所有文件都被捆绑到一个方便的 zip 文件中。 所以在短短 18 秒内,整个站点就被压缩了。

我现在准备搬到本地。 在我这样做之前,我想快速浏览一下 zip 文件,看看里面有什么。 你可以看到我有一个文件目录。 这包括所有 WordPress 文件,包括我的 WP 内容、插件、主题和上传。 而且我还有数据库转储。

另一个文件,对于 WP Migrate 来说非常重要和独特——WP Migrate 导出 JSON 文件包含有关导出站点的关键信息,例如 PHP 版本和 MySQL 版本,因此当 Local 负责导入时,它可以尽可能地匹配那个远程环境。

因此,您已准备好导入 Local。 我会把它寄回奥斯汀。

AUSTIN WENDT: 太棒了,谢谢,凯文。 是的,我很高兴介绍,就像凯文提到的那样,我们如何才能将该 zip 文件导入本地并准备好开始构建。 但首先,我想先介绍一下 Local 是什么。 如果您不熟悉,Local 是排名第一的 WordPress 开发工具,由 WP Engine 的人员构建,我们非常高兴与社区免费分享和提供。

所以它是一个免费的开发工具。 如果您还没有听说过,请查看 localWP.com,我们很乐意让您使用该产品。 但今天,我们将使用 Local 来促进此工作流程。

为什么是本地? 与您的机器特定的任何环境类似,它的风险非常低。 正如凯文所说,当您从 WP Migrate 导入导出时,Local 将尝试做的是我们将密切模仿生产环境。 所以尽可能接近,WordPress 版本,PHP 版本,数据库,你的本地机器应该模仿生产中发生的事情,这样如果你正在排除故障或试图看看出了什么问题,本地应该能够告诉您,并尽可能了解托管环境中正在发生的事情。

使用 Local 执行此操作的另一个主要好处是 Kevin 刚刚提到的工作流程与主机无关。 因此,无论您在哪里托管,无论是使用 Flywheel 还是 WP Engine,您都可以非常快速轻松地导出该站点并放入本地。

所以我会把它放到一个演示中,并向您展示它在本地 UI 中的样子。

太棒了,所以我已经完成了 WP Migrate,并将该 zip 文件保存到我的桌面。 当我在 Local 中创建站点时,会出现一个新的拖放区,表明您可以在此处拖放 zip 文件。 Local 的另一个好处是我可以从 UI 中的任何屏幕执行此操作。 因此,如果我将该 zip 文件拖放到本地,它会从 Kevin 提到的 WP 迁移导出 JSON 文件中为我建议网站名称。

它预选了我的 PHP、我的 Web 服务器和我的数据库。 然后,我单击“创建”,Local 会处理剩下的事情。 因此,Local 正在积极解压缩该 zip 文件,导入所有这些 WordPress 文件,并在我的机器上以尽可能接近生产的状态设置该站点。

当它开始运行时,它会请求更新我的主机文件的权限,我将输入我的密码并允许它这样做。 但是随后,Local 开始添加 WordPress,您就可以开始了。

完成后,我将真正快速强调的是您可以在左侧看到 - 过去几周 Local 中新增了对站点进行分组的功能。 因此,我会将 Garrett's Grocery 拖放到我的 DE{CODE} 演示部分——这是一种很好的方式,我鼓励您检查以组织您的网站,可能按客户端或版本分组,连接到 WP引擎与否,最适合您的。 所以试一试。

但是 Local 在这里结束,它正在更改该站点域。 要做的是在我的机器上配置它,以便它可用,正如您在此处看到的那样,位于 mysite.local。 如果我单击“打开站点”,这里是 Garrett's Grocery。 所以我已经有效地离开了我的托管环境,将它拖放到本地,并在不到两分钟的时间内让它在我的机器上运行,这太棒了。

因此,在这个例子中,我们展示的是能够从您的旧主机获取它,无论它在互联网上的任何地方,并结合 WP Migrate 全站导出,将其放入本地并模仿您的在不到几分钟的时间内创建生产环境。

现在,问题是,一旦我在 Local 中获得它,我就可以开始进行更改了。 我如何将其取回并重新在互联网上发布? 为了从 Local 获取您的网站并将其恢复到您的主机,我们将使用 Local Connect 部署到 WP Engine 或 Flywheel。 来自完整站点迁移和部分迁移。

但是为什么要进行完整的站点部署呢? 首次将整个站点部署到您的主机就是一个很好的例子。 所以也许该站点根本不存在,或者它可能只是主机上的一个模板化站点。 如果您希望包含整个主题或插件更改,或者您可能只是准备完全覆盖今天主机上的当前站点。 所以也许它已经有了内容,但现在上面的内容不再有生产力或有益,你准备好擦掉它,你会使用完整的站点部署。

所以使用 Local,这很容易实现。 我将向您展示它的外观演示。 所以我在这里有 Garrett's Grocery,我已经对我准备推送的网站进行了一系列更改。 现在,Local 有 Local Connect 的概念,正如我提到的——左侧有一个云图标,用于连接。 右下角还有一个连接到主机,这将允许我连接 WP Engine 或 Flywheel。

今天,我将通过转到“连接”选项卡并单击“连接到平台”来完成此操作。 我将登录我的 WP Engine 帐户,我不会让你看着我登录。你可以看到发生的是 Local Connect 拉入了我在 WP Engine 上可以访问的所有站点。 现在,我要做的是在概览中回到 Garrett's Grocery。 在右下角,我将选择连接到 WP 引擎。

Local 将检查该站点是否与 WP Engine 的基础架构兼容。 所以使用最新的 WordPress 和 PHP,然后我可以单击 Push。

推送将允许我选择要在 WP Engine 上覆盖的视线。 它将允许我选择环境。 所以我会选择 Austin Wendt 站点,然后选择 Production。 您将在屏幕右侧看到的是 Local 正在确定文件列表。

这意味着本地本质上是在我的机器上的内容和服务器上存在的内容之间运行差异,并将其提供给我,以便我可以真正看到和理解我将要进行的更改。 因为这是一个完整的站点部署,你可以看到我的本地环境没有发生任何事情,但我将覆盖生产环境中的所有内容,正如你在右侧看到的那些红色 X。

然后我点击,Push to WP Engine,Local 开始处理剩下的事情。 整个视频大约有四分钟——我会坐在这里,让你和我一起看。 发生的事情是 Local 正在打包这些文件。 它开始将这些文件上传到 WP Engine。 并开始分析,就像我说的,我的机器上的内容与 WP Engine 服务器上的内容之间的差异。

如果您在那里托管,同样的工作流程也适用于 Flywheel。 我们将按照相同的流程输入您的机器和服务器之间的文件差异。

所以现在,Local开始打包数据库。 它也将其推送到 WP Engine。 因此,它会删除远程服务器上存在的所有现有表,并将它们替换为来自我的机器的表。

作为该数据库转换的一部分,它将查看站点域并为我执行搜索和替换,如您现在所见。 这样存储在数据库中的所有链接和 URL 以及表前缀都将得到更新,以便在生产环境中正常工作。

所以它会为我更新那些表前缀。 就这样,我的网站已被推送到 WP 引擎。

所以重新开始,Garrett's Grocery 仍在我的机器上。 而且,如果我转到“连接”选项卡,我可以在右侧看到我推送到的 Austin Wendt 网站,它说它已连接到 Garrett's Grocery。 如果我点击网站名称 Austin Wendt,它会在浏览器中打开,向我展示互联网上的新内容。

因此,既然我们了解了如何使用 Local 来完成完整的站点部署,我想介绍一下我们如何使用 Local 来使用我们称为 MagicSync 的功能来同步环境。

所以 MagicSync 是增量迁移的另一种说法。 因此,只需在本地环境和远程服务器之间移动少量代码。 你为什么要这样做?

所以也许您不想替换整个站点。 您只对准备上线的现有站点进行了较小的部分更改。 Local 的另一个好处是,正如我提到的,Local 将允许您使用 diff 功能,挑选并选择您想要包含甚至排除的文件。 所以这里一个很常见的用例是,也许我在我的机器上做了很多事情,但我想排除推拉媒体,因为这是我网站的一个非常繁重和密集的部分。 我可以取消选择媒体。

因此,我将在这里深入演示 MagicSync 的外观。 再说一次,这里我有 Garrett's Grocery – 说我这次做了另一组较小的更改,我准备好看到它在 WP Engine 上的实时反映。 这里的工作流程相同——在我屏幕的右下角,我返回以推送到 WP Engine。 它已经为我预选了 Austin Wendt 网站和环境,记得我上次这样做的时候。

而这一次,它会更短——它再次决定了我机器上的内容和 WP Engine 服务器上的内容之间的差异。 所以它会回到这里,并且它检测到对站点进行了一组较小的更改。 我可以取消选择我想要的所有文件更改。 我可以只选择我的 WP 内容文件夹。

或者在这种情况下,假设我只想推送我的数据库。 所以我可以选中数据库框并点击推送。 所以现在发生的是我们之前看到的相同工作流程,除了 Local 实际上没有将任何文件推送到 WP Engine。 它只是用当前在 WP 引擎服务器上的数据库替换我在我的机器上所做的数据库更改。

这里的工作流程非常相似——我们实际上会看到这一过程,因为它不需要那么长的时间。 因为差异较小。 所以我们将数据库上传到 WP 引擎。 本地将再次为我前进并进行搜索和替换。 因此它将检测表前缀是否已更改,我的机器上不同的 URL 需要反映在远程主机上。

它将为我进行这些更新。 在大约不到一分钟的时间里,我在我的机器上所做的站点更改将被推送到 WP 引擎,并准备好供同事和同行使用,无论是想回顾我所做的工作,也许我已经推送到开发环境,或者如果它在网络上处于生产状态,并准备好供我的客户或消费者使用,或者只是消费者可以在网络上查看。

就这样,该网站已被推送到 WP 引擎,如果我返回浏览器,您会看到该网站已更新并反映在那里。 因此,现在我们了解了如何使用 Local 来完成增量迁移,我想把它交还给 Kevin,向您展示使用 WP Migrate 工具完成此操作的另一种方法。

凯文霍夫曼: 嘿,谢谢,奥斯汀。 感谢您通过 Local to WP Engine 工作流程指导我们,但我们知道您并不总是能够控制您的托管服务提供商。 因此,下一个工作流程将向您展示如何在任意两个 WordPress 环境之间迁移。 在这种情况下,从本地到任何其他网络主机。

为此,我们将使用一个名为推拉的概念,使用 WP Migrate。 现在,你为什么要推或拉? 现在与完整站点导出相比,这是双向迁移。 这意味着这两个站点都已经存在,并且需要更多的前期投资才能获得更长期的回报。

因此,一旦完成此设置,您就可以随时处理增量迁移,并持续保持两个环境同步。

那么让我们看看它是什么样的。 因此,假设您的站点已准备好部署到您的远程主机。 您的媒体库中有许多帖子和图像。 我们将获取此内容并将其移动到一个新站点,该站点目前有零个帖子,并且媒体库中没有图像。

我们将在此处采用的不同方法是使用推送迁移。 它问我的第一件事是来自远程站点的连接信息。 所以我可以切换到远程站点,并在我的设置选项卡中,将连接信息直接复制到我的剪贴板。 我还想启用推送迁移,这样我就可以接受来自本地站点的这些推送请求。

通过将该信息粘贴到连接信息框中,我现在已连接到远程站点,并且我已准备好配置我的数据库选项。 与我们的导出工作流相比,您会在这里注意到的最大区别是 URL 和路径的查找和替换端都已为我们完全填写。 这是因为 WP Migrate 在两个站点上都有,并且可以访问该信息,并且可以为我们处理这些信息,而无需我们输入任何内容来启动迁移。

我不打算进行自定义查找和替换,但我将包括我从库中上传的所有媒体,以及我所有的主题和插件。 现在,当您选择我的插件时,您会在这里注意到一个独特的功能,它会向我显示该插件在远程站点上的状态。 现在,在这种情况下,那里没有插件,所以所有这些插件都是第一次添加,当您将鼠标悬停在该图标上时,会指示当前版本号。

我将继续保存此配置文件以供将来使用,我将其命名为 Push Full Site。 所以任何时候我需要将一个完整的站点推送到那个远程位置,我可以简单地重新访问这个配置文件并运行它。

当我运行配置文件时,您会再次看到它逐一显示表格、媒体上传、主题、插件,并且您会在迁移过程中获得有关请求大小的一些信息。

迁移完成后,您可以继续并关闭模式,现在您的两个环境已同步。

此时,您可能想重新访问您的配置文件屏幕,以查看保存的配置文件如何可供您单击返回,如果您需要再次运行它。

所以这是一个完整的站点部署,在 WP Migrate 中有一个保存配置文件。 但您可能想知道,如何部署增量更改? 所以就像 Austin 向您展示的那样,通过在本地使用 MagicSync,这是使用 WP Migrate 实现的另一种方式。 所以我要创建另一个推送配置文件,输入相同的连接信息,但这次,当我选择我的媒体上传时,我只会推送新的和更新的媒体上传。

这意味着,第一次运行迁移时,它将包括所有内容。 但是此后的每次迁移,它只会包含已更改的媒体文件。

每当您推送内容和媒体文件而无需担心主题或插件时,这都是一个出色的工作流程。 所以我现在要保存此配置文件,并将其命名为推送内容和媒体。

所以这给我留下了两个迁移配置文件,我可以将它们用于两个不同的目的。 它们保存在我的个人资料屏幕上,并且在我需要跳回它们时随时可用。 我什至可以设置一个拉取配置文件,然后将生产数据拉取到这个本地站点,并使两个环境在两个方向上保持同步。

这样就结束了我们使用本地和 WP Migrate 从远程移动到本地,再回到远程的工作流程。

正如你所看到的,现在我们的游戏计划已经完成,我们有使用从 WP Migrate 导出的完整站点移出远程站点的解决方案,将其拖放到本地,然后向上推送到 WP Engine 或 Flywheel,或任何其他主机。 因此,这只是迁移解决方案的冰山一角,以及结合使用 WP Migrate 和 Local 的可能性。

因此,我们希望在您下次需要运行自己的迁移时为您提供一个游戏计划。 期待在我们的 Twitter 帐户上收到您关于 WP Migrate 和 Local 的消息,我们希望您喜欢 DE{CODE] 的其余部分。 感谢您加入我们。