当为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
复制代码
结论
当设计和开发我们的WordPress主题和插件时,我们希望能够尽可能地专注于我们的实际工作。如果我们能够自动设置工作环境,我们就可以把额外的时间和精力投入到我们的产品中。
这正是DevKinsta所做的。我们只需按下一个按钮就可以启动一个本地WordPress网站,并在短短几分钟内创建许多不同环境的网站。
DevKinsta正在被积极开发和支持。如果你遇到任何问题或有一些疑问,你可以浏览文档或前往社区论坛,DevKinsta的创建者会帮助你。
所有这些,都是免费的。听起来不错吧?如果是这样,下载DevKinsta,然后去启动你的本地WordPress网站。