使用 WP-CLI 和 Robo 管理 WordPress 開發環境

已發表: 2022-09-13

自動化重複性任務是節省開發工作流程時間的最佳方法之一。 在我作為插件開發人員的日常工作中，我經常需要重置數據庫、重新安裝特定版本的 WordPress、安裝一個或多個插件以及更新設置。 這很快就會讓人厭煩，因此它非常適合自動化。 在本文中，我將向您展示如何將 WP-CLI 與 Robo 結合使用來自動化管理我的 WordPress 開發環境所需的任務。

WordPress 命令行工具 WP-CLI 是加快工作流程的良好開端。 如果您不熟悉它，我強烈建議您閱讀我們眾多博文中的一篇。 我們的安裝指南是一個很好的起點，介紹瞭如何在您的操作系統上安裝它、設置選項卡補全以及創建配置文件。

目錄

  1. 什麼是機器人？
    1. Robo 簡化命令行 PHP
    2. 安裝機器人
    3. 你的第一個命令
    4. 輸入和輸出
    5. 好幫手
    6. 機器人的好處
  2. 使用 Robo 維護 WordPress
    1. 重要文件
    2. 我的環境
    3. 數據庫用戶
    4. 網絡服務器
    5. 照顧依賴關係
  3. 利用 wp-cli.yml
    1. 什麼是 WP-CLI 中的別名？
    2. 命令默認值
  4. 創建自定義 Robo 命令
    1. 命令配置
    2. reset命令
    3. 安裝後步驟
    4. profile命令
  5. 包起來

什麼是機器人？

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 和使用命令行有所了解。

重要文件

此設置中有四個重要文件。 我將在這篇文章中介紹它們中的每一個：

  1. wp-cli.yml – 標準的 WP-CLI 配置文件。 在管理多個環境時，我使用它來利用 WP-CLI 的幾個強大的內置功能。
  2. RoboFile.php – 這是實現 robo 命令的基礎文件。
  3. robo.yml – 一個自定義 YAML 文件，用於我們的 Robo 命令的一些附加配置參數。
  4. 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 數據庫重置--是的
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 自動執行其中一些任務為我作為插件開發人員節省了每一天的時間。 我再也不能回去手動做這些事情了。

您使用哪些工具來自動化開發工作流程中最繁瑣的部分？ 在評論中告訴我。