Local（旧Local by flywheel）から中々wp-envに移行できない理由としてよく「データベースマネジメントツールとMailHogがない」ことが挙げられます。
ということでnpm run wp-env startで全部立ち上がるようにしていきます。
ココナラ
でWordPressのエラー解決サービスを始めました！
追加オプション無しで3,000円から受け付けておりますが、新規会員登録で300円、僕の紹介コードを入力すると1,000円分のポイントが貰えるので実質1,700円から利用することができます！
- 突然画面が真っ白になった
- 英語のエラーが表示されてどうしたらいいかわからない
- とにかく困っている
どんなことでもぜひお気軽にご相談ください！
wp-env × Adminer × MailHogの要点
- データベースのチェックをGUIで行える、書き換えも容易
- WordPressのメール機能に関する開発を行える
wp-envにAdminerとMailHogが組み合わさると何が嬉しいかというとこの2点。
僕はSend Chat ToolsというSlackやDiscordにWordPressのコメント通知やログイン通知、アップデート通知、Rinkerの終売通知なんかを送信するプラグインを作っているのですが、もし正常に遅れなかった場合メール通知する必要があります。
そのためMailHogはぜひとも欲しい機能でした。
wp-envは標準でこの2つに対応していないので、連携するDockerコンテナを建ててこれらの機能を使えるようにします。
GitHubリポジトリ
当記事で解説しているコードは以下のリポジトリにあります。
GitHub Repository:https://github.com/braveryk7/wp-env-with-adminer-mailhog
要点
compose.yamlを用意しAdminerとMailHogの設定を記述する.wp-env.jsonにはメールに関する定数を記述するdocker compose up -dやdocker compose downがwp-envと連動するようにする
基本的に操作を増やすのはナンセンスなので、.wp-env.jsonに用意されているライフサイクルスクリプトセクションを使って自動的に目的のコンテナが立ち上がり、終了時には自動的にコンテナが終了するように設定します。
ただしこれは仕組み上、どうしても既存のwp-envコマンドとdocker composeコマンドの組み合わせだけでは行えないので簡単なシェルスクリプトを書いてそれを実行するようにします。
環境
僕の環境構築時点での各種バージョンです。
$ node -v
v18.17.1
$ npm -v
9.6.7
$ docker -v
Docker version 25.0.0, build e758fe5# package.json
{
"devDependencies": {
"@wordpress/env": "^9.2.0"
}
}特に@wordpress/envパッケージはバージョンによって結構大きな違いがあるので、必ず最新情報を公式でキャッチアップしてください（動かない等あったら教えて下さると嬉しいです）。
手順
実際に必要なファイル群を用意していきます。
ファイル構成
/
├── .wp-env.json
├── /bin
│ └── after-start-scripts.sh
├── /node_modules
│ └── /.bin
│ └── wp-env
├── compose.yaml
├── package-lock.json
└── package.json必須なファイルは.wp-env.jsonとcompose.yamlぐらいです。
.wp-env.jsonはwp-envの立ち上げを、compose.yamlはAdminerとMailHogの立ち上げを行います。
より便利に使えるようにbinディレクトリ配下にシェルスクリプトをおいてあります。
ファイル作成
まずは必要なファイル群を生成していきます。
# git管理するなら
$ git init
# ディレクトリの作成
$ mkdir bin
# ファイル作成
# package.jsonはnpm initしても可
# .wp-env.jsonは後で作成
$ touch bin/after-start-scripts.sh compose.yaml package.json
# package.jsonはnpm install時、正しいjson形式である必要がある
# そのため最低限jsonとして認識されるように{}を記述
$ echo "{}" > package.json続いて@wordpress/envパッケージを導入します。
起動できるかテストも兼ねて一度動かしてみます。
# @wordpress/envインストール
$ npm i -D @wordpress/env
# wp-envが実行されるかどうか確認
# .wp-env.jsonが無いと警告されるが一旦無視
$ node_modules/.bin/wp-env start
Warning: could not find a .wp-env.json configuration file and could not determine if
'/home/user_name/develop/wp-env-with-adminer-mailhog'
is a WordPress installation, a plugin, or a theme.
WordPress development site started at http://localhost:8888
WordPress test site started at http://localhost:8889
MySQL is listening on port 32784
MySQL for automated testing is listening on port 32785
✔ Done! (in 6s 592ms)これで表示されたURLにアクセスして問題が無いか確認してください。
続いてこのコンテナのハッシュ値を取得します。
# ハッシュ値取得
# この場合ハッシュ値は242ad077a237e5d5c0781dd085d26fdf
# ハッシュ値はcompose.yamlで使用する
$ node_modules/.bin/wp-env install-path
/home/user_name/wp-env/242ad077a237e5d5c0781dd085d26fdf
✔ (in 0s 605ms)
# .wp-env.json作成
$ touch .wp-env.jsonハッシュ値は後ほど使用するのでどこかにメモしておくかターミナルに表示しておいてください。
.wp-env.json
{
"config": {
"WP_DEBUG": true,
"WP_DEBUG_LOG": true,
"WP_DEBUG_DISPLAY": true,
"WPMS_ON": true,
"WPMS_SMTP_HOST": "mailhog",
"WPMS_SMTP_PORT": 1025,
"WPMS_MAILER": "smtp"
},
"core": "https://ja.wordpress.org/latest-ja.zip",
"env": {},
"mappings": {},
"phpVersion": "8.2",
"port": 59650,
"testsPort": 59651,
"plugins": [
"https://downloads.wordpress.org/plugin/query-monitor.zip",
"https://downloads.wordpress.org/plugin/wordpress-beta-tester.zip",
"https://downloads.wordpress.org/plugin/wp-crontrol.zip",
"https://downloads.wordpress.org/plugin/wp-multibyte-patch.zip",
"https://downloads.wordpress.org/plugin/wp-mail-smtp.zip"
],
"themes": [
"https://github.com/xserver-inc/cocoon/archive/refs/heads/master.zip"
],
"lifecycleScripts": {
"afterStart": "sh bin/after-setup-scripts.sh"
}
}色々書いてありますが、重要な部分をピックアップします。
"config": {
"WP_DEBUG": true,
"WP_DEBUG_LOG": true,
"WP_DEBUG_DISPLAY": true,
"WPMS_ON": true,
"WPMS_SMTP_HOST": "mailhog",
"WPMS_SMTP_PORT": 1025,
"WPMS_MAILER": "smtp"
},まずconfigブロックでWP_DEBUGの設定と後ほど紹介するWP Mail SMTPというプラグインの定数を設定しています。
他にもWP Mail SMTP向けの設定はありますが、とりあえず最低限これだけ記述しておけば動きます。
特にWPMS_SMTP_HOSTは後述するcompose.yamlのcontainer_nameと合わせるようにしてください。
"plugins": [
"https://downloads.wordpress.org/plugin/query-monitor.zip",
"https://downloads.wordpress.org/plugin/wordpress-beta-tester.zip",
"https://downloads.wordpress.org/plugin/wp-crontrol.zip",
"https://downloads.wordpress.org/plugin/wp-multibyte-patch.zip",
"https://downloads.wordpress.org/plugin/wp-mail-smtp.zip"
],ここでは開発に便利な各種プラグインをまとめてインストールしていますが、一番最後のwp-mail-smtp.zipが今回の肝です。
WP Mail SMTPはWordPressのメール機能を強化するプラグインで、テストメールの送信機能があるため採用しています。
それ以外のプラグインは不要なら削除してください。
"themes": [
"https://github.com/xserver-inc/cocoon/archive/refs/heads/master.zip"
],テーマは日本でも人気があり無料で使えるCocoonをインストールしてあります、これも好みで変えてください。
後で手動でアップロードして好きなテーマを実装することももちろん可能です。
"lifecycleScripts": {
"afterStart": "sh bin/after-start-scripts.sh"
}最後のlifecycleScriptsセクションはざっくりいうと「特定のタイミングで特定の処理が走らせられますよ」というもの。
ここではafterStartというタイミングでシェルスクリプトを走らせています。
その名の通り、npm run wp-env startコマンドが走った後に実行されます。
bin/after-start-scripts.sh
npm run wp-env run cli -- wp plugin delete akismet hello
docker compose up -dここでは試しにコンテナ内のwp-cliを動かしてデフォルトで入っている邪魔なAkismetとHello Doryという2つのプラグインを削除しています。
重要なのは2行目、docker compose up -dコマンドを使って後述するcompose.yamlを元にAdminerとMailHogコンテナを立ち上げています。
compose.yaml
volumes:
maildir: {}
services:
adminer:
image: adminer
restart: always
ports:
- 8080:8080
networks:
- wpnetwork
mail:
image: mailhog/mailhog
container_name: mailhog
ports:
- 1025:1025
- 8025:8025
environment:
MH_STORAGE: maildir
MH_MAILDIR_PATH: /tmp
volumes:
- maildir:/tmp
networks:
- wpnetwork
networks:
wpnetwork:
external:
name: 242ad077a237e5d5c0781dd085d26fdf_default今回一番重要な部分がこのcompose.yamlです。
volumes:
maildir: {}まずはMailHogのメールがコンテナを終了させるたびに消えてしまうのは困るので永続化しています。
adminer:
image: adminer
restart: always
ports:
- 8080:8080
networks:
- wpnetworkAdminerの設定部分です。
バージョン指定がある場合はバージョンを記述してください。
portsは空いてるものであれば何でも良いですが、何故か僕のWSL/Ubuntu環境だと59000番台以降が使えませんでした。どうして・・・！
networksはwpnetworkという名称を指定しています。
mail:
image: mailhog/mailhog
container_name: mailhog
ports:
- 1025:1025
- 8025:8025
environment:
MH_STORAGE: maildir
MH_MAILDIR_PATH: /tmp
volumes:
- maildir:/tmp
networks:
- wpnetworkMailHogの方はコンテナ名をmailhogと明示しています、これは.wp-env.jsonで指定したWPMS_SMTP_HOSTで使用するためです。
portsは2つ設定してありますが、MailHogコンテナがデフォルトで1025番をSMTPに、8025番をWeb UI用に充てているのでそのまま同じポート番号を充てています。
networksにはAdminerと同様wpnetworkを指定しています。
networks:
wpnetwork:
external:
name: 242ad077a237e5d5c0781dd085d26fdf_default最後のnetworksがwp-envとdocker composeそれぞれで立ち上げたコンテナを同じネットワーク内であると明示しています。
ネットワーク全体をwpnetworkという名前で定義し、wp-env側で作成するネットワークを接続するために冒頭取得したハッシュ値を記述します。
wp-envで起動したコンテナは「ハッシュ値_default」という命名規則でNAMEがつくので、特に_defaultを忘れないようにしましょう。
package.json
最後にwp-envコマンドをいちいちnode_modulesから指定するのは面倒なので、package.jsonのscriptsにコマンドを記述します。
{
"scripts": {
"wp-env": "wp-env"
},
"devDependencies": {
"@wordpress/env": "^9.2.0"
}
}これでnpm run wp-envというコマンドで呼び出せるようになりました。
wp-env × Adminer × MailHog 稼働チェック
それでは準備ができたので実際に稼働してみましょう！
一度wp-envを起動しているので、--updateオプションをつけて再起動させます。
$ npm run wp-env start --update
> wp-env
> wp-env start
WordPress development site started at http://localhost:59650
WordPress test site started at http://localhost:59651
MySQL is listening on port 32788
MySQL for automated testing is listening on port 32789
✔ Done! (in 48s 25ms)無事起動ができたようです。
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8523fb34e763 adminer "entrypoint.sh php -…" 24 seconds ago Up 22 seconds 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp wp-env-with-adminer-mailhog-adminer-1
5d3a69adbbef mailhog/mailhog "MailHog" 24 seconds ago Up 22 seconds 0.0.0.0:1025->1025/tcp, :::1025->1025/tcp, 0.0.0.0:8025->8025/tcp, :::8025->8025/tcp mailhog
d6a32d426eb4 242ad077a237e5d5c0781dd085d26fdf_cli "docker-entrypoint.s…" 37 seconds ago Up 35 seconds 242ad077a237e5d5c0781dd085d26fdf-cli-1
5ff14b9c9b5a 242ad077a237e5d5c0781dd085d26fdf_tests-cli "docker-entrypoint.s…" 37 seconds ago Up 35 seconds 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1
43bdc86764d6 242ad077a237e5d5c0781dd085d26fdf_tests-wordpress "docker-entrypoint.s…" 37 seconds ago Up 35 seconds 0.0.0.0:59651->80/tcp, :::59651->80/tcp 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1
d7241cbb6603 242ad077a237e5d5c0781dd085d26fdf_wordpress "docker-entrypoint.s…" 37 seconds ago Up 35 seconds 0.0.0.0:59650->80/tcp, :::59650->80/tcp 242ad077a237e5d5c0781dd085d26fdf-wordpress-1
f24a2125bb97 mariadb "docker-entrypoint.s…" 37 seconds ago Up 36 seconds 0.0.0.0:32789->3306/tcp, :::32789->3306/tcp 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1
41f310e73dcc mariadb "docker-entrypoint.s…" 57 seconds ago Up 55 seconds 0.0.0.0:32788->3306/tcp, :::32788->3306/tcp 242ad077a237e5d5c0781dd085d26fdf-mysql-1docker psコマンドでコンテナ状況を見てみると、Adminrとmailhogのコンテナが確認できます。
今回の設定通りなら、以下のURLでアクセスができるはずです。
| コンテナ | URL |
|---|---|
| WordPress環境 | http://localhost:59650 |
| WordPressテスト環境 | http://localhost:59651 |
| Adminer | http://localhost:8080 |
| MailHog | http://localhost:8025 |
WordPress環境
WordPress環境にアクセスすると問題がなければサイトトップページが表示されます。
もちろん/wp-adminへアクセスするとログインページが表示されます。
| 項目 | 値 |
|---|---|
| ID | admin |
| Password | password |
初期設定は上記のIDとパスワードでログインが行なえます。
.wp-env.jsonで指定したCocoonがインストールされています。
こちらはプラグインページ。
ライフサイクルスクリプトで指定したように、デフォルトでは必ずインストールされているAkismetとHello Dollyが削除されています。
ライフサイクルスクリプトはどんなLinuxコマンドも実行できるので、立ち上げ段階から記事データを入れておきたいとかタイムゾーン設定、パーマリンク設定等を記述しておけばとても便利になります。
先程のテーマの有効化も、必ずこのテーマを使うぞ！と決まっているならシェルスクリプトに追記します。
# bin/after-start-scripts.sh
# npm run wp-env run cli -- wp theme activate <theme_slug>
# theme_slugはテーマの名前のようなもの
# Twenty-Twenty Fourならtwentytwentyfour
# 今回のCocoonの場合、本来はcocoon-masterだがmasterを指定する
# 以下はTwenty-Twenty Fourを明示的に有効化
npm run wp-env run cli -- wp theme activate twentytwentyfourAdminerコンテナ
Adminerはlocalhost:8080でアクセスできます。
| 項目 | 値 |
|---|---|
| サーバ | mysql |
| ユーザ名 | root |
| パスワード | password |
| データベース | wordpress |
デフォルトでは以上の情報で接続可能、これはwp-envで立ち上げたWordPressのwp-config.phpに記述された情報で、wp-cliを使って確認することができます。
# ~/wp-env/<ハッシュ値>/<WordPressのバージョン>/wp-config.phpに記載されいてる情報
# <WordPressのバージョン>は今回ならlatest-ja
$ npm run wp-env run cli -- wp config get DB_HOST
mysql
$ npm run wp-env run cli -- wp config get DB_USER
root
$ npm run wp-env run cli -- wp config get DB_PASSWORD
password
$ npm run wp-env run cli -- wp config get DB_NAME
wordpress
無事ログインできました。
MailHogコンテナ
MailHogはlocalhost:8025でアクセスできます。
メールがMailHogで正常に受信（WordPress側から送信）できるかテストします。
左側のメニューからWP Mail SMTP->ToolsにアクセスしSend Emailボタンをクリックします。
MailHog側でテストメールが受信できていればOK、これでメール送信を伴う機能のテストはMailHog経由で行なえます。
wp-env × Adminer × MailHogの弱点改善
以上で欲しい機能は満たせましたが、実は問題点がいくつかあります。
終了はwp-envとdocker composeを順番通り手動で行う必要がある
まずは終了時。
wp-envはコンテナが必要なくなった時、または.wp-env.jsonを書き換えてリスタートする時に一度明示的にコンテナを削除します。
その時同時にネットワークも削除しますが、AdminerやMailHogのコンテナがアクティブの場合この2つのコンテナもネットワークに接続されているため、先にwp-envのコンテナを終了/破棄/再起動するとネットワークが削除できずエラーが出ます。
# 以下はwp-env stopの例だがwp-env start --updateもwp-env destroyも同様の結果となる
$ npm run wp-env stop
> wp-env
> wp-env stop
✖ Error while running docker compose command.
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1 Removed
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1 Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1 Removed
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1 Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1 Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1 Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1 Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1 Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1 Removed
Network 242ad077a237e5d5c0781dd085d26fdf_default Removing
Network 242ad077a237e5d5c0781dd085d26fdf_default Error
failed to remove network 242ad077a237e5d5c0781dd085d26fdf_default: Error response from daemon: error while removing network: network 242ad077a237e5d5c0781dd085d26fdf_default id e395e5150627852f03cb6b1849f83aeb98c9c4ce72774be3c733f36ba0ef9991 has active endpoints最後のfailed to remove networkがそれで、ネットワークの削除に失敗しています。
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8523fb34e763 adminer "entrypoint.sh php -…" 13 hours ago Up 13 hours 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp wp-env-with-adminer-mailhog-adminer-1
5d3a69adbbef mailhog/mailhog "MailHog" 13 hours ago Up 13 hours 0.0.0.0:1025->1025/tcp, :::1025->1025/tcp, 0.0.0.0:8025->8025/tcp, :::8025->8025/tcp mailhogwp-envのコンテナは全て削除されています。
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
e395e5150627 242ad077a237e5d5c0781dd085d26fdf_default bridge localしかしこのようにnetworkはアクティブなままです。
これの何が問題かというと、wp-envのライフサイクルスクリプトにはafterStartと同じくafterDestroyが存在します。
つまりafterStartと同じノリでシェルスクリプトにdocker compose downを書いてafterDestroyで呼んでもwp-envがエラーで落ちてしまうのでafterDestroyが実行されずコンテナの削除ができません。
これを解決する手段はいくつかありますが、重要な点は以下の順番を守ること。
docker compose downコマンドでAdminerとMailHogコンテナを終了させるwp-envコマンドを実行する
この順番さえ守れればOK。
スマートな方法として、package.jsonにカスタムコマンドを設定することが考えられます。
{
"scripts": {
"wp-env": "wp-env",
"env-start": "wp-env start", //追記
"env-stop": "docker compose down && wp-env stop", //追記
"env-restart": "docker compose down && wp-env start --update", //追記
"env-rm": "docker compose down && wp-env destroy" //追記
},
"devDependencies": {
"@wordpress/env": "^9.2.0"
}
}今回はenv-stopという名前で定義してみました、このように明示的にdocker compose downを行ってからwp-env stopを順番に実行しています。
カスタムコマンド名は何でも良いんですが “wp-env”という名称は混乱するので避けた方が良いでしょう、他にも”server-stop”や”dev-stop”等が考えられます。
ちなみにnpm scripts内にスペース（例えばenv stop）を使うとコマンド実行時にnpm run "env stop"のように明示的にクオーテーションで囲う必要があり面倒なので避けた方がベター。
stopと同じようにenv-start、env-restart、env-rmを定義しています。
wp-env startはライフサイクルスクリプトを使わずに直接カスタムコマンドを作って使うこともできます、これはお好みの方でOK。
複数wp-env環境が存在するとdestroyに失敗する
wp-envは1つ仮想環境を建てると合計5つのdocker imageを使用します。
# wp-env実行
$ npm run wp-env start
# docker image確認
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
1249c7a84e1c8b5a5dcf75e0841ed384_cli latest 0eeceacf00f0 22 hours ago 457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli latest 0eeceacf00f0 22 hours ago 457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress latest e906d2d1a247 8 days ago 815MB
1249c7a84e1c8b5a5dcf75e0841ed384_wordpress latest e906d2d1a247 8 days ago 815MB
mariadb latest 2b54778e06a3 2 months ago 404MBではwp-envを2つ使用、例えばプラグインAとプラグインBの開発を行っており、それぞれの環境で利用するとどうでしょう。
# 別プラグインに移動
$ cd /path/to/plugin_b/
# wp-env実行
$ npm run wp-env start
# dockerコンテナ確認
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b3e24ebfd76 242ad077a237e5d5c0781dd085d26fdf_tests-cli "docker-entrypoint.s…" 33 seconds ago Up 31 seconds 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1
0938b959c846 242ad077a237e5d5c0781dd085d26fdf_cli "docker-entrypoint.s…" 33 seconds ago Up 32 seconds 242ad077a237e5d5c0781dd085d26fdf-cli-1
d5ee5778eae9 242ad077a237e5d5c0781dd085d26fdf_tests-wordpress "docker-entrypoint.s…" 34 seconds ago Up 32 seconds 0.0.0.0:59651->80/tcp, :::59651->80/tcp 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1
8bd9b0e50310 242ad077a237e5d5c0781dd085d26fdf_wordpress "docker-entrypoint.s…" 34 seconds ago Up 32 seconds 0.0.0.0:59650->80/tcp, :::59650->80/tcp 242ad077a237e5d5c0781dd085d26fdf-wordpress-1
ec2dd15e0105 mariadb "docker-entrypoint.s…" 34 seconds ago Up 32 seconds 0.0.0.0:32805->3306/tcp, :::32805->3306/tcp 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1
341d26832857 mariadb "docker-entrypoint.s…" 57 seconds ago Up 56 seconds 0.0.0.0:32804->3306/tcp, :::32804->3306/tcp 242ad077a237e5d5c0781dd085d26fdf-mysql-1
0e29b54ca37e 1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 1249c7a84e1c8b5a5dcf75e0841ed384-tests-cli-1
6ced35965caa 1249c7a84e1c8b5a5dcf75e0841ed384_cli "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 1249c7a84e1c8b5a5dcf75e0841ed384-cli-1
7a519859bb06 1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 0.0.0.0:49651->80/tcp, :::49651->80/tcp 1249c7a84e1c8b5a5dcf75e0841ed384-tests-wordpress-1
0e4e4be07091 1249c7a84e1c8b5a5dcf75e0841ed384_wordpress "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 0.0.0.0:49650->80/tcp, :::49650->80/tcp 1249c7a84e1c8b5a5dcf75e0841ed384-wordpress-1
01f0f2fb18a1 mariadb "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 0.0.0.0:32803->3306/tcp, :::32803->3306/tcp 1249c7a84e1c8b5a5dcf75e0841ed384-tests-mysql-1
55d74d4c7325 mariadb "docker-entrypoint.s…" 7 minutes ago Up 7 minutes 0.0.0.0:32802->3306/tcp, :::32802->3306/tcp 1249c7a84e1c8b5a5dcf75e0841ed384-mysql-1この通り、242ad077a237e5d5c0781dd085d26fdfと1249c7a84e1c8b5a5dcf75e0841ed384の2つの環境が存在していることが確認できます。
# docker image確認
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
1249c7a84e1c8b5a5dcf75e0841ed384_cli latest 0eeceacf00f0 22 hours ago 457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli latest 0eeceacf00f0 22 hours ago 457MB
242ad077a237e5d5c0781dd085d26fdf_cli latest 0eeceacf00f0 22 hours ago 457MB
242ad077a237e5d5c0781dd085d26fdf_tests-cli latest 0eeceacf00f0 22 hours ago 457MB
242ad077a237e5d5c0781dd085d26fdf_wordpress latest e906d2d1a247 8 days ago 815MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress latest e906d2d1a247 8 days ago 815MB
1249c7a84e1c8b5a5dcf75e0841ed384_wordpress latest e906d2d1a247 8 days ago 815MB
242ad077a237e5d5c0781dd085d26fdf_tests-wordpress latest e906d2d1a247 8 days ago 815MB
mariadb latest 2b54778e06a3 2 months ago 404MBしかしdocker imageを確認するとmariadbは1つしかありません。
wp-env destroyはdocker imageの削除も行うので、つまり2つ以上のwp-env環境が存在している場合、wp-env destroyは100％失敗します。
コンテナ使用中はimageを削除できないためです。
何が言いたいかというと、wp-envのライフサイクルスクリプトにおけるafterDestroyは100％実行されることが保証できないということです。
あまりafterDestroyを多用する場面は思いつかないとはいえ、提供されている機能なのに利用できない場面があるというのは安心して使用できません。
そのため、基本的にはafterDestroyは使わずにnpm scripts内で完結するほうが現状好ましいといえます。
wp-envにAdminerとMailHogを組み合わせる開発環境 まとめ
wp-envは非常に簡単なコマンドで開発環境の構築が行なえ、更に少し工夫することでAdminerやMailHogといった非常に便利なコンテナを連携させることができます。
特に複数人で開発を行っているなら、.wp-env.jsonやcompose.yamlをコミットしてGitHubにプッシュするだけで全員が同じ環境を共有できます。
まだ正直wp-env自体に荒削りな部分がある点は否めませんが、これからWordPress開発を行うなら必ず導入したい必須ツールです。
コメント