使用 WP-CLI 和 Robo 管理 WordPress 开发环境
已发表: 2022-09-13
自动化重复性任务是节省开发工作流程时间的最佳方法之一。 在我作为插件开发人员的日常工作中,我经常需要重置数据库、重新安装特定版本的 WordPress、安装一个或多个插件以及更新设置。 这很快就会让人厌烦,因此它非常适合自动化。 在本文中,我将向您展示如何将 WP-CLI 与 Robo 结合使用来自动化管理我的 WordPress 开发环境所需的任务。
WordPress 命令行工具 WP-CLI 是加快工作流程的良好开端。 如果您不熟悉它,我强烈建议您阅读我们众多博文中的一篇。 我们的安装指南是一个很好的起点,介绍了如何在您的操作系统上安装它、设置选项卡补全以及创建配置文件。
目录
- 什么是机器人?
- Robo 简化命令行 PHP
- 安装机器人
- 你的第一个命令
- 输入和输出
- 好帮手
- 机器人的好处
- 使用 Robo 维护 WordPress
- 重要文件
- 我的环境
- 数据库用户
- 网络服务器
- 照顾依赖关系
- 利用 wp-cli.yml
- 什么是 WP-CLI 中的别名?
- 命令默认值
- 创建自定义 Robo 命令
- 命令配置
reset
命令- 安装后步骤
profile
命令
- 包起来
什么是机器人?
Robo 是一个开源的现代任务运行程序,被包括 Drush 和 Codeception 在内的许多项目使用。
Robo 类似于 Gulp 和 Grunt,但使用的是 PHP 而不是 JavaScript。
这个想法是你可以创建像这样的漂亮的小命令:
# 重置我的 WP 开发环境并使其成为多站点 机器人重置--multi # 安装和设置 WP Offload Media 插件 robo 个人资料 ome-dev
Robo 任务运行器通过将 DocBlock 注释添加到命令中,可以轻松记录您创建的命令,以便您可以为自己的未来版本提供帮助:
# 不带任何参数的 Robo 将显示可用的命令。 机器人 可用命令: help 显示命令的帮助 list 列出命令 profile 在现有的 WordPress 环境中运行一组 wp-cli 命令 将 WordPress 环境重置为已知状态
询问有关特定命令的更多信息:
机器人帮助重置 描述: 将 WordPress 环境重置为已知状态。 读取环境和配置 来自 robo.yml 用法: 重置 [选项] 选项: --env[=ENV] 环境(开发,测试等)[默认:“开发”] --multi 进行多站点安装 --ver[=VER] WordPress 版本 [默认:“最新”]
我使用 Robo 创建了一些强大的命令,我每天都使用这些命令来管理我的 WordPress 开发环境。 在本文中,我将与您分享这些命令,并在此过程中介绍 Robo 命令。
Robo 简化命令行 PHP
让我们稍微检查一下后视镜。 编写命令行 PHP 命令当然不是什么新鲜事。 总是可以像这样从命令行运行 PHP 脚本:
php myscript.php
只要我记得,PHP 就已在大多数 *NIX 环境中用作命令行环境。 添加 PHP shebang 将在大多数安装了 PHP 解释器的环境中工作。
// file: myscript #!/usr/bin/env php <?php // do stuff here…
这使得可以从命令行执行脚本,而无需指定它应该由 PHP 解析(或包括 .php 文件扩展名):
我的脚本
从命令行运行原始 PHP 脚本的缺点是在每个脚本中需要处理大量的输入和输出开销。 从命令行接受参数,然后将消息输出到命令行的过程有点繁琐,感觉不是很灵活。
Robo 着手通过处理大多数脚本所需的大量标准“管道”来简化命令行 PHP 的编写。 这使您可以专注于脚本的核心功能。
安装机器人
在我们开始之前,您需要安装 Robo。 我将 Robo 全局安装在我的机器上,所以我是这样安装的:
作曲家全球需要整合/机器人
但是与通过 Composer 安装的任何东西一样,如果您对此更满意,可以将其保留为项目依赖项。 或者,GitHub 有通过下载robo.phar
来安装它的说明。
你的第一个命令
首先,我们需要在项目文件夹中初始化 Robo:
cd /path/to/myproject 机器人初始化
这实际上只是在您的文件夹中创建了一个新的RoboFile.php
,其内容如下:
<?php class RoboFile extends \Robo\Tasks { }
要添加我们的第一个命令,我们只需添加一个公共方法:
<?php class RoboFile extends \Robo\Tasks { public function hello($world) { $this->say("Hello, $world"); } }
正如您可能猜到的那样,上述方法创建了命令hello
并简单地在屏幕上输出一条消息。
解析参数
像我们上面所做的那样添加该方法是展示我喜欢 Robo 的更重要原因之一的好方法,即解析命令行参数。
为了向您展示我的意思,让我们尝试运行以下命令:
机器人你好 没有足够的论据(缺少:“世界”)。 你好 [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [ -n|--否 -interaction] [--simulate] [--progress-delay PROGRESS-DELAY] [-D|--define DEFINE] [--]
啊哈! Robo 给了我一条错误消息,因为hello
命令实际上需要一个$world
参数,然后继续写出该命令的完整用法语法。
让我们稍微改变一下方法,让参数可选:
public function hello($world = 'from Robo') { $this->say("Hello, $world"); }
…现在让我们再次运行它:
# 没有参数 机器人你好 你好,来自机器人 # 用一个简单的参数 你好! 你好呀! # 使用包含空格的 arg robo 你好“我住在命令行上” 你好,我住在命令行
这样更好! 通过使参数成为可选参数,Robo 现在可以愉快地执行我们的方法,即使没有传递参数。 我们还看到,我们可以传递一个简单的参数和一个在引号内的参数,并且它可以正常工作。
如果您曾经花时间为命令行脚本编写参数检查逻辑,您可能会意识到为什么这是一个不错的功能。 它只是消除了很多痛苦。
示例hello
命令使用一个位置参数。 Robo 还支持通过创建具有一些默认值的数组参数来使用标志和命名参数。
让我们进一步修改函数以选择性地打印出一些额外的字符:
public function hello( $world = 'from Robo', $flags = [ 'stars' => false, 'stripes' => false ] ) { if ( $flags['stars'] ) $this->say( '***************' ); if ( $flags['stripes'] ) $this->say( '===============' ); $this->say( "Hello, $world" ); if ( $flags['stripes'] ) $this->say( '==============='); if ( $flags['stars'] ) $this->say( '***************' ); }
这将告诉 Robo 我们可以选择使用双破折号传入命名参数:
# 只要包含一个命名参数,它就会得到值'true' 机器人你好——星星 *************** 你好,来自机器人 ***************
输入和输出
我们也已经看到了一个使用 IO 的例子。 Robo 任务对象的say()
函数只是简单地向用户输出一个字符串。 还有一个ask()
函数可以让你询问用户输入:
public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
机器人你好 ? 告诉我该说什么:foobar 富吧
Robo 使用 Symfony 控制台来创建用户交互。 这意味着除了两个简单的say()
和ask()
函数外,我们还可以从 Symfony 控制台访问任何函数,比如table()
:
public function table() { $this->io()->table( ['Header 1', 'Header 2'], [ ['Cell 1-1', 'Cell 1-2'], ['Cell 2-1', 'Cell 2-2'], ['Cell 3-1', 'Cell 3-2'], ] ); }
机器人桌 ---------- ---------- 标题 1 标题 2 ---------- ---------- 单元格 1-1 单元格 1-2 单元格 2-1 单元格 2-2 单元格 3-1 单元格 3-2 ---------- ----------
很酷,嗯?
好帮手
喜欢 Robo 的另一个原因是它内置了对许多常见任务的支持,这使得编写易于理解的代码变得更加容易,即使您在 3 个月后再次使用它。 让我们看看 Robo 如何帮助为一些非常标准的任务编写非常干净的代码:
# Create a directory, and switch to it: $this->taskExecStack() ->stopOnFail() ->exec('mkdir site') ->exec('cd site') ->run(); # Search and replace inside a text file: $this->taskReplaceInFile('VERSION') ->from('0.2.0') ->to('0.3.0') ->run(); # Run composer update: $this->taskComposerUpdate()->run(); # SSH into a server, go to a specific directory, list the contents of the directory, and set permissions on the logs subdirectory $this->taskSshExec('remote.example.com', 'user') ->remoteDir('/var/www/html') ->exec('ls -la') ->exec('chmod g+x logs') ->run();
使用普通的 PHP 和exec()
函数可以实现上述所有操作,但这通常会成为尝试将命令字符串粘合在一起并正确转义参数而不把事情搞砸的无望练习。
除了上面的例子,对 Git、Subversion、Rsync、Bower、Gulp、Docker、NPM 和其他开发环境中经常使用的工具也有类似的支持。
机器人的好处
总而言之,Robo 使创建命令行脚本变得更加容易,最终结果通常比普通 PHP 在语义上更具吸引力。
我发现与纯 PHP 脚本相比,Robo 的脚本最终更容易阅读和理解,因为很多命令行样板文件都隐藏在 Robo 本身内部。 就个人而言,几个月后我可以查看自己的代码,并且真的想知道它是谁编写的,所以任何可以帮助我编写清晰易读的代码的东西都是我工具带中受欢迎的补充。
使用 Robo 维护 WordPress
本文的其余部分假定您对 WP-CLI、使用 Composer 和使用命令行有所了解。
重要文件
此设置中有四个重要文件。 我将在这篇文章中介绍它们中的每一个:
- wp-cli.yml – 标准的 WP-CLI 配置文件。 在管理多个环境时,我使用它来利用 WP-CLI 的几个强大的内置功能。
- RoboFile.php – 这是实现 robo 命令的基础文件。
- robo.yml – 一个自定义 YAML 文件,用于我们的 Robo 命令的一些附加配置参数。
- composer.json – 标准的 Composer 配置文件。
我的环境
为了为本文的其余部分做好准备,我将快速描述我的本地开发环境是如何设置的。 这是我在磁盘上组织事物的简化版本:
~/src ├── devenv/ │ ├── RoboFile.php │ ├── composer.json │ ├── wp-cli.yml │ ├── robo.yml │ ├── wordpress-dev/ │ └── wordpress-test/ ├── 插件1/ │ ├── 资产/ │ └── 包括/ └── 插件2 └── ...
src
文件夹是存储与开发相关的所有内容的地方,而devenv
文件夹包含特定于实际运行时环境的文件。 由于我通常同时运行多个 WordPress 环境,因此每个 WordPress 安装都有自己的子文件夹,在本示例中命名为wordpress-dev
和wordpress-test
。
我使用的每个插件都位于每个插件的单独文件夹中。
在现实世界中,我有多个 devenv 文件夹,这样我就可以将 Delicious Brains 的工作与各种副项目分开,但这与本文无关。
数据库用户
为了使一切正常工作,我还在本地 MySQL 安装中为每个 WordPress 安装创建了本地数据库,并且有一个数据库用户,恰当地命名为wordpress
,可以正确访问这些数据库。 数据库的确切详细信息以及用户凭据存储在wp-cli.yml
文件中。
网络服务器
我使用 nginx 作为我的本地 Web 服务器,但您会发现 Apache2 也可以正常工作。 我的 nginx 配置设置为http://www.wordpress-dev.local
和http://www.wordpress-test.local
指向上面提到的两个 WordPress 文件夹。
照顾依赖关系
为了让我的 Robo 脚本更加灵活,我使用了一些通过 Composer 安装的附加功能,特别是 Symfony Yaml 解析器。 由于RoboFile.php
实际上只是一个普通的 PHP 文件,因此我可以自由地包含我想要的任何库,并且我很自然地使用 Composer 来执行此操作。 该项目的composer.json
文件如下所示:
{ "require": { "symfony/yaml": "^5.2" } }
如果您复制它,请不要忘记使用composer update
实际安装库。
利用 wp-cli.yml
使用 WP-CLI 时,您可以通过使用诸如wp-cli.yml
类的配置文件来简化生活。 我使用 WP-CLI 配置文件有两个主要原因:别名和为各种子命令设置默认值。
什么是 WP-CLI 中的别名?
本质上,WP-CLI 别名只是配置文件中的一个标签,可让您覆盖一些默认值。
别名最常见的用法可能是覆盖默认path
,以便每个别名指向一个单独的 WordPress 安装。 由于每个 WordPress 安装都使用数据库凭据保存自己的配置文件,因此这种方式使用的别名也代表一个单独的数据库。 WP-CLI 配置文件中的别名可以覆盖url
、 path
、 user
、 ssh
和http
设置,但不能覆盖子命令的默认值。
创建一个名为@test
的附加 WordPress 环境允许我运行 WP-CLI 命令,如下所示:
# 列出开发 WordPress 安装中的所有插件 wp插件列表 # 列出测试 WordPress 安装中的所有插件 wp @test 插件列表
命令默认值
如果您以前没有尝试过,为子命令设置默认参数非常方便。 例如,当您使用config create
命令创建一个新的 WordPress 配置文件时,您每次都需要指定至少三个参数:
$ wp config create --dbname=somedb --dbuser=myuser --dbpass=secret
如果您厌倦了键入此内容,可以将参数粘贴到wp-cli.yml
文件中:
config create: dbuser: myuser dbpass: secret dbname: somedb
完成后,您可以使用wp config create
,它会从您的wp-cli.yml
文件中获取正确的参数。
不幸的是,不可能为不同的别名设置不同的命令默认值。 这实际上是我开始关注 Robo 以实现更多自动化的原因之一。
我的 WP-CLI 配置文件如下所示:
# Global parameter defaults path: wordpress-dev url: http://www.wordpress-dev.local user: admin @test: path: wordpress-test url: www.wordpress-test.local # Subcommand defaults config create: dbuser: wordpress dbpass: ***** dbname: wordpress extra-php: | define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true); define( 'SCRIPT_DEBUG', true ); core install: admin_user: admin admin_password: admin admin_email: [email protected] title: WordPress Dev core multisite-install: admin_user: admin admin_password: admin admin_email: [email protected]
有了这个配置文件,我就可以运行常用命令,而不必每次都指定单独的参数:

# 重置测试环境的数据库 wp @test db reset --yes # 下载最新版本并创建 wp-config.php 文件 wp @test 核心下载 wp @test 配置创建 # 安装 WordPress wp @test core install --title="WordPress 测试"
由于 WP-CLI 会从配置文件中获取大部分参数,因此我不必输入我通常必须输入的所有命令行参数,例如--dbuser
和--admin_email
。
请注意,在上面的最后一个示例中,我单独提供了title
参数。 这是因为我希望站点标题在测试环境中有所不同,但无法使用别名覆盖此参数。
创建自定义 Robo 命令
设置一个全新的 WordPress 安装几乎是远远不够的。 通常需要安装和激活一个或多个插件,并且经常需要一些设置来修复这里和那里。
即使使用精心编写的 WP-CLI 配置文件,如果我想重置我的 WordPress 环境并准备好一切,我仍然会得到一长串命令。 我经常一遍又一遍地做这样的序列:
# 重置我的开发环境 wp db重置--是的 rm -rf 路径/到/wordpress wp核心下载 wp配置创建 wp核心安装 ln -s path/to/my/plugin1 path/to/wordpress/wp-content/plugins/ wp插件激活插件1
即使在充分利用 WP-CLI 配置文件的情况下,也需要大量输入。 为了避免一遍又一遍地输入它并且时不时地出错,我使用 Robo 创建了两个专门的命令来为我做这件事:
- reset – 将 WordPress 环境重置为已知状态。
- profile – 在现有环境中运行一组命令。
由于 WP-CLI 子命令默认参数不会扩展到不同的命令行环境,我们可以使用 Robo 用同一块石头杀死那只鸟。 让我们看看如何。
命令配置
我们的第一站是查看我为此创建的 Robo 配置文件。 它是用 YAML 编写的,这应该使其易于理解和扩展。 当我们到达使用它的命令时,我将回顾每个部分:
wordpress-dev: cli-prefix: "" path: "wordpress" core-multisite-install: title: WordPress Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ - ln -s $cwd/../plugins2 $path/wp-content/plugins/ wordpress-test: cli-prefix: "@test" path: "wordpress-test" config-create: dbname: wordpress-test core-install: title: WordPress Test core-multisite-install: title: WordPress Test Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ profiles: woocommerce: - $wp plugin install --activate woocommerce - $wp wc payment_gateway update cheque --enabled=true --user=admin - $wp option update woocommerce_calc_taxes yes - $wp wc tax create --name=VAT --rate=10 --user=admin - $wp wc shipping_zone_method create 0 --method_id=flat_rate --user=admin - $wp option update --format=json woocommerce_flat_rate_1_settings '{"title":"Flat rate","tax_status":"taxable","cost":"15"}' imageimport: - $wp media import $cwd/../media/lots-of-images/* issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR true --raw
每个 WordPress 环境都使用wordpress-$env
键标识。 每个键可以保存多个配置值。
reset
命令
第一个命令是reset
。 它在命令行中使用,如下所示:
# 重置开发(默认)环境 机器人重置 # 或者更明确 机器人重置 –env=dev # 重置测试环境 机器人重置 –env=test # 重置开发环境并安装 WordPress 多站点 机器人重置--multi # 将开发环境重置为特定的 WordPress 版本 机器人重置--ver=5.6.1
该命令做的第一件事是删除目标 WordPress 安装目录中的所有现有文件和文件夹,并重置配置的 WordPress 数据库。
然后, reset
命令使用 WP-CLI 命令core download
、 config create
和core install
或core multisite-install
之一,具体取决于--multi
选项。
在最大程度上,这使用位于wp-cli.yml
文件中的命令参数默认值。 这样做的原因是,在没有 Robo 包装器的情况下直接运行 WP-CLI 时,这些默认值也很有帮助。 但如上所述,在某些情况下这是不可能的。
因此, robo.yml
配置文件提供了为wp-cli.yml.
例如,在安装 @test 环境时,我们希望覆盖core install
参数--title
的参数。 我们可以通过在robo.yml
中添加以下内容来做到这一点:
wordpress-test: ... ... core-install: title: WordPress Test ... ...
这里的语法很简单:CLI 命令名称(空格替换为破折号)作为键,每个命名参数都有一个子键。 上面的示例将为core install
cli 命令生成以下额外参数:
wp @test core install --title="WordPress 测试"
安装后步骤
配置文件中的每个环境键都可以选择指定一个带有安装后步骤的数组。 这只是 WordPress 安装完成时执行的 bash 命令列表。 为了增加灵活性,在执行命令之前进行了一些字符串替换:
细绳 | 替换为 |
---|---|
$cwd | 当前工作目录 |
$路径 | 目标 WordPress 安装路径 |
$wp | wp-cli 命令,包括别名前缀,即 wp @test |
~ | (波浪号)当前用户的 HOME 目录 |
因此ln -s $cwd/../plugin1 $path/wp-content/plugins/
的安装后步骤将创建一个从我的插件文件夹之一到目标 WordPress 安装中的插件子文件夹的符号链接。
profile
命令
profile
命令与安装后的步骤非常相似,但它的用途是在现有的 WordPress 安装上运行一组命令。 假设您有一个非常简单的开发环境,您可以在其中完成大部分工作。但是,有时您需要安装 WooCommerce 插件并为其进行一些基本设置。 这就是profile
命令的用途。 它可以这样使用:
# 重置开发环境 机器人重置 # 安装 WooCommerce 并进行一些设置更改 机器人简介 woocommerce
上面的示例robo.yml
文件有一个 WooCommerce 配置文件。 应用该配置文件将:
- 使用 WP-CLI 安装和激活 WooCommerce。
- 使用
wc
子命令设置支付网关、税区和运输设置。 - 使用
option
sub 命令直接在 WordPress 选项表中修改一些设置。
使用不同的配置文件非常有用。 我大部分时间都在工作 WP Offload Media 插件,我经常需要将大量图像导入 WordPress 媒体库。 WP-CLI 有一个非常方便的命令:
wp 导入媒体 /some/long/path/I/often/forget/*
由于我经常忘记很多东西,特别是长路径名,我发现更容易记住:
robo 个人资料图片导入
这是另一个例子。 我一直在处理一个特定的 GitHub 问题,我们试图解决我们的插件和另一个流行的 WordPress 插件之间的兼容性问题。 当我处理这个问题时,我需要安装该插件并在wp-config.php.
所以我为它创建了一个配置文件:
.... issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR value
现在我可以一步准备好我的环境,只需robo profile issue2530
。
就像重置命令中post-install
步骤一样,配置文件定义中的每一行实际上只是一个单独的 bash 命令。 您可以使用它来启动单独的脚本、删除文件或任何您喜欢的东西。 也很有可能射中自己的脚,所以要小心行事。
来源
如果尝试上述任何方法听起来很有趣,这是我用于上述所有内容的 RoboFile,请随意使用它来开始使用 Robo 管理 WordPress。
<?php use Robo\Symfony\ConsoleIO; use Robo\Tasks; use Symfony\Component\Yaml\Yaml; require_once 'vendor/autoload.php'; /** * Class RoboFile */ class RoboFile extends Tasks { /** * Reset the WordPress environment to a known state. Reads environments * and configuration from robo.yml * * @option env Environment (dev, test etc) * @option multi Make a multi site install * @option ver WordPress version * * @return bool */ public function reset( $opts = [ 'env' => 'dev', 'multi' => false, 'ver' => 'latest' ] ) { $env = $opts['env']; $version = $opts['ver']; $multi = $opts['multi']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } if ( ! isset( $all_config[ $key ]['path'] ) ) { $this->say( "No path set for environment $env." ); } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; $version = $version === 'latest' ? '' : "--version=$version"; $config_create = $this->additional_parameters( 'config create', $config ); $install_cmd = $multi ? 'core multisite-install' : 'core install'; $install_params = $this->additional_parameters( $install_cmd, $config ); echo "$wp $install_cmd $install_params\n"; $this->taskExec( "$wp db reset --yes" )->run(); $this->taskExecStack() ->exec( "rm -rf $path/*" ) ->exec( "$wp core download $version" ) ->exec( "$wp config create $config_create" ) ->exec( "$wp config delete WP_DEBUG" ) ->exec( "$wp $install_cmd $install_params" ) ->run(); foreach ( $config['post-install'] as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * Run a set of wp-cli commands on an existing WordPress environment * * @param string $profileName Name of the profile in robo.yml * * @option env Environment (dev, test etc) */ public function profile( $profileName, $opts = ['env' => 'dev']) { $env = $opts['env']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; if ( ! isset( $all_config['profiles'][ $profileName ] ) ) { $this->say( "Profile $profileName not found" ); return false; } $profile = $all_config['profiles'][ $profileName ]; foreach ( $profile as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); // Quick and dirty. If the cmd exactly matches another profile, run it! if ( isset( $all_config['profiles'][ $cmd ] ) ) { $this->profile( $cmd, $env ); continue; } echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * @return array */ private function read_yaml() { return Yaml::parseFile( __DIR__ . '/robo.yml' ); } /** * @param $config * @param $env * * @return bool */ private function ensure_basic_config( $config, $env ) { $key = "wordpress-$env"; if ( ! isset( $config[ $key ] ) ) { $this->say( "No path set for environment $env." ); return false; } if ( ! isset( $config[ $key ]['cli-prefix'] ) ) { $this->say( "No wp-cli prefix set for environment $env." ); return false; } return true; } /** * @param string $name * @param array<string, string> $config * * @return string */ private function additional_parameters( $name, $config ) { $name = str_replace( ' ', '-', $name ); if ( ! isset( $config[ $name ] ) ) { return ''; } return implode( ' ', array_map( function ( $v, $k ) { return sprintf( "--%s='%s'", $k, $v ); }, $config[ $name ], array_keys( $config[ $name ] ) ) ); } }
包起来
在开发过程中,重复性任务往往会随着地域而变化。 我看不出有什么方法可以完全消除它们,但是尽可能多地自动化它们确实可以帮助您在可用的时间内完成尽可能多的实际工作。
结合我在此处概述的 WP-CLI 和 Robo 自动执行其中一些任务为我作为插件开发人员节省了每一天的时间。 我再也不能回去手动做这些事情了。
您使用哪些工具来自动化开发工作流程中最繁琐的部分? 在评论中告诉我。