用DevKinsta在本地旋转多个WordPress网站-一一网

当为WordPress构建主题和插件时，我们需要确保它们在所有将被安装的不同环境中工作良好。当为我们自己的网站创建一个主题时，我们有时可以控制这个环境，但在其他时候我们不能，例如当通过公共的WordPress仓库分发我们的插件，让任何人都可以下载和安装它。

关于WordPress，我们需要担心的可能的环境组合包括。

不同版本的PHP。
不同版本的WordPress。
不同版本的WordPress编辑器（又称块状编辑器）。
HTTPS的启用/禁用。
多站点启用/禁用。

让我们看看这是怎么一回事。PHP 8.0，这是PHP的最新版本，已经引入了与以前版本不同的突破性变化。由于WordPress官方仍然支持PHP 5.6，我们的插件可能需要支持7个版本的PHP。PHP 5.6，加上PHP 7.0到7.4，再加上PHP 8.0。如果插件需要PHP的某些特定功能，比如类型属性（在PHP 7.4中引入），那么它将需要支持该版本的PHP以后的版本（在这种情况下，PHP 7.4和PHP 8.0）。

关于WordPress的版本问题，这个软件本身可能偶尔会引入一些突破性的变化，比如在WordPress 5.6中更新到一个较新的jQuery版本。此外，WordPress的每个主要版本都会引入新的功能（例如5.0版本中引入的新的Gutenberg编辑器），这可能是我们产品所需要的。

块状编辑器它也不例外。如果我们的主题和插件包含自定义块，对它们进行所有不同版本的测试是必须的。至少，我们需要担心两个版本的Gutenberg：一个是WordPress核心版，一个是作为独立插件的版本。

关于HTTPS和多站点，我们的主题和插件可能会有不同的表现，这取决于这些是否被启用。例如，我们可能想在不使用HTTPS时禁止对REST端点的访问，或者从多站点向超级管理员提供扩展功能。

这意味着有许多可能的环境是我们需要担心的。我们如何处理它呢？

弄清环境

一切可以自动化的东西，都必须自动化。例如，为了测试我们的主题和插件的逻辑，我们可以创建一个持续集成过程，在多个环境中运行一组测试。自动化带走了一大块的痛苦。

然而，我们不能仅仅依靠让机器为我们做所有的工作。我们还需要访问一些测试WordPress网站，以直观地了解在一些软件升级后，我们的主题是否仍然看起来像预期的那样。例如，如果Gutenberg更新了它的全局样式系统或一个核心块的行为方式，我们要检查我们的产品是否没有受到变化的影响。

我们需要支持多少种不同的环境？假设我们的目标是4个版本的PHP（7.2到8.0），5个版本的WordPress（5.3到5.7），2个版本的Gutenberg（核心/插件），HTTPS启用/禁用，以及多站点开启/关闭。这一切相当于总共有160种可能的环境。这实在是太多了，难以处理。

为了简化问题，我们可以把它减少到少数几个环境，而不是为每个可能的组合制作一个网站，总之，包括所有不同的属性。

例如，我们可以制作这五种环境。

PHP 7.2 + WP 5.3 + Gutenberg core + HTTPS + multisite
PHP 7.3 + WP 5.4 + Gutenberg plugin + HTTPS + multisite
PHP 7.4 + WP 5.5 + Gutenberg plugin + no HTTPS + no multisite
PHP 8.0 + WP 5.6 + Gutenberg core + HTTPS + no multisite
PHP 8.0 + WP 5.7 + Gutenberg core + no HTTPS + no multisite

旋转5个WordPress站点是可以管理的，但这并不容易，因为它涉及到技术挑战，特别是启用不同版本的PHP，以及提供HTTPS证书。

我们想轻松地启动WordPress站点，即使我们的系统知识有限。而且，我们想快速完成它，因为我们还有开发和设计工作要做。我们怎样才能做到这一点呢？

用DevKinsta管理本地WordPress网站

幸运的是，现在启动本地WordPress网站并不困难，因为我们可以避免手工操作，而是依靠一个工具来为我们自动完成这个过程。

DevKinsta正是这样的工具。它能够以最小的努力启动一个本地WordPress网站，用于任何需要的配置。该网站将在喝杯咖啡的时间内被创建。而且，它的成本肯定比一杯咖啡低。DevKinsta是100%免费的，可用于Windows、macOS和Ubuntu用户。

顾名思义，DevKinsta是由Kinsta创建的，Kinsta是WordPress领域领先的托管服务提供商之一。他们的目标是简化WordPress项目的工作过程，不管是对设计师还是开发人员、自由职业者还是机构。我们越容易设置我们的环境，我们就越能专注于我们自己的主题和插件，我们的产品就越好。

为DevKinsta提供动力的魔法是Docker，这个软件能够通过容器将一个应用程序与环境隔离。然而，我们并不需要了解Docker或容器。DevKinsta将底层的复杂性隐藏起来，所以我们只需按下一个按钮就可以启动WordPress网站。

在这篇文章中，我们将探讨如何使用DevKinsta来启动5个不同的本地WordPress实例来测试一个插件，以及我们有哪些好的功能可以使用。

用DevKinsta启动一个WordPress网站

上面的图片显示了第一次打开DevKinsta时的情况。它为创建一个新的本地WordPress网站提供了3个选项。

新WordPress网站
它使用默认配置，包括最新的WordPress版本和PHP 8。
从Kinsta导入
它从MyKinsta托管的现有网站上克隆配置。
自定义网站
它使用一个由你提供的自定义配置。

按下选项#1，就会在字面上产生一个本地的WordPress网站，甚至不用考虑它。如果我可以的话，我可以进一步解释一下；真的没有比这更多的东西了。

如果你碰巧是Kinsta的用户，那么按选项#2可以让你直接从MyKinsta导入一个网站，包括数据库的转储。(同时，它也可以反过来使用：DevKinsta的本地修改可以推送到MyKinsta的暂存网站上。)

最后，当按下选项#3时，我们可以指定本地WordPress站点要使用的自定义配置。

让我们按下选项#3的按钮。配置屏幕将看起来像这样。

有几个输入是只读的。这些是目前固定的选项，但在未来的某个时候会变成可配置的。例如，网络服务器目前被设置为Nginx，但增加Apache的工作正在进行中。

我们目前可以配置的选项有以下几个。

网站的名称（本地URL是由它计算出来的）。
PHP版本。
数据库名称。
HTTPS启用/禁用。
WordPress网站的标题。
WordPress的版本。
管理员的电子邮件、用户名和密码。
启用/禁用的多站点。

在为我的第一个本地WordPress网站（名为 “GraphQL API on PHP 80″）完成这些信息后，点击 “创建网站”，DevKinsta只花了2分钟就创建了这个网站。然后，我就看到了新创建的网站的信息屏幕。

新的WordPress站点在它自己的本地域名下可用graphql-api-on-php80.local 。点击 “打开网站 “按钮，我们可以在浏览器中看到我们的新网站。

我为所有不同的所需环境重复了这个过程，瞧，我的5个本地WordPress站点很快就启动和运行了。现在，DevKinsta的初始屏幕列出了我所有的网站。

使用WP-CLI

从我的环境所需的配置来看，到目前为止，我已经满足了所有的项目，除了一个：把Gutenberg作为一个插件安装。

接下来让我们来做这个。我们可以像往常一样通过WP管理员来安装一个插件，如上图所示，我们可以通过点击网站信息屏幕上的 “WP管理员 “按钮进入。

更好的是，DevKinsta已经安装了WP-CLI，所以我们可以通过命令行界面与WordPress网站互动。

在这种情况下，我们需要对Docker有一个最基本的了解。在一个容器中执行命令是这样的。

docker exec {containerName} /bin/bash -c '{command}'
复制代码

需要的参数是。

DevKinsta的容器被称为devkinsta_fpm 。
安装和激活一个插件的WP-CLI命令是wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
容器内的WordPress站点的路径是/www/kinsta/public/{siteName} 。

把所有东西放在一起，在本地WordPress网站上安装和激活Gutenberg插件的命令就是这个。

docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'
复制代码

探索功能

对于我们的本地WordPress网站，有几个方便的功能。

第一个是与Adminer整合，这是一个类似于phpMyAdmin的工具，用于管理数据库。有了这个工具，我们可以通过一个自定义的SQL查询直接获取和编辑数据。点击网站信息屏幕上的 “数据库管理员 “按钮，将在一个新的浏览器标签中打开Adminer。

第二个值得注意的功能是与流行的电子邮件测试工具 Mailhog的整合。由于这个工具，从本地WordPress网站发送的任何电子邮件实际上并没有被发送出去，而是被捕获，并显示在电子邮件收件箱中。

点击一封电子邮件，我们可以看到它的内容。

访问本地安装文件

在安装完本地WordPress站点后，它的包含所有文件（包括WordPress核心、安装的主题和插件以及上传的媒体项目）的文件夹将是公开的。

**Mac和Linux：**在/Users/{username}/DevKinsta/public/{siteName} 。
**Windows：**在C:\Users\{username}\DevKinsta\public\{siteName} 下。

(换句话说：本地WordPress网站的文件不仅可以通过Docker容器访问，还可以通过我们操作系统中的文件系统访问，比如在Windows中使用My PC，在Mac中使用Finder，或者任何终端。)

这非常方便，因为它为安装我们正在开发的主题和插件提供了一个快捷方式，加快了我们的工作。

例如，要在所有5个本地网站上测试一个插件的变化，我们通常要到每个网站的WP管理员那里去，然后上传新版本的插件（或者，使用WP-CLI）。

不过，通过访问网站的文件夹，我们可以简单地从其 repo中克隆该插件，直接放在wp-content/plugins 。

$ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins
$ git clone git@github.com:leoloso/MyAwesomePlugin.git
复制代码

这样，我们就可以在git pull ，把我们的插件更新到最新版本，使它在本地的WordPress网站上立即可用。

$ cd MyAwesomePlugin
$ git pull
复制代码

如果我们想在不同的分支上测试开发中的插件，我们同样可以做一个git checkout 。

git checkout some-branch-with-new-feature
复制代码

由于我们可能有几个不同环境的站点，我们可以通过执行一个bash脚本来自动完成这个过程，这个脚本会迭代本地的WordPress站点，并为每个站点执行一个git pull ，以安装在其中的插件。

#!/bin/bash

iterateSitesAndGitPullPlugin(){
  cd ~/DevKinsta/public/  for file in *
  do
    if [ -d "$file" ]; then
      cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin
      git pull
    fi
  done
}

iterateSitesAndGitPullPlugin
复制代码