クイック (tl;dr) インストラクション

Docker が実行中であることを確認したら、次のようにします: 

  1. $ cd /path/to/a/wordpress/plugin
  2. $ npm -g i @wordpress/env
  3. $ wp-env start

ローカル環境は http://localhost:8888 で利用可能です (ユーザー名: admin, パスワード: password)。

データベースの認証情報は次のとおりです: ユーザー root, パスワード password。データベースに直接接続するための包括的なガイドについては、MySQL データベースへのアクセスを参照してください。

前提条件

wp-env は、いくつかの一般的に使用される開発者ツールに依存しています:

  • Docker。 wp-env は Docker によって動作します。Docker のインストール手順は、Windows (WSL2 バックエンドを推奨)、macOS、および Linux にあります。
  • Node.js。 wp-env は Node スクリプトとして書かれています。最新の LTS バージョンをインストールするために、nvm のような Node バージョンマネージャを使用することを推奨します。あるいは、ここから直接ダウンロードすることもできます。
  • git。Git は、WordPress、プラグイン、テーマなどのソース管理からソフトウェアをダウンロードするために使用されます。インストール手順はここにあります。

インストール

グローバルパッケージとしてのインストール

前提条件がインストールされていることを確認したら、次のようにして wp-env をグローバルにインストールできます: 

  1. $ npm -g i @wordpress/env

これで wp-env を使用する準備が整いました！

ローカルパッケージとしてのインストール

プロジェクトにすでに package.json がある場合、wp-env をローカルパッケージとして使用することも可能です。まず、wp-env を開発依存関係としてローカルにインストールします: 

  1. $ npm i @wordpress/env --save-dev

wp-env をグローバルにインストールしている場合、実行するとローカルのプロジェクトレベルのパッケージが自動的に実行されます。あるいは、wp-env を npx 経由で実行できます。これは npm とともに自動的にインストールされるユーティリティです。npx は、ノードモジュールを通じてインストールされたバイナリを見つけます。例として: npx wp-env start --update。

グローバルインストールや npx を使用したくない場合は、package.json を修正し、npm scripts に追加のコマンドを追加します (https://docs.npmjs.com/misc/scripts): 

  1. "scripts": {
  2.    "wp-env": "wp-env"
  3. }

この方法で wp-env をインストールする場合、これらのドキュメントに詳述されているすべての wp-env コマンドは npm run で接頭辞を付ける必要があります。例えば: 

  3. # スクリプト (wp-env) にフラグを渡すには、npm 自体ではなく、もう一つのダブルダッシュを追加する必要があります
  5. $ npm run wp-env start -- --update

代わりに: 

  1. $ wp-env start --update

使用法

環境の開始

まず、Docker が実行中であることを確認してください。システムトレイまたはメニューバーの Docker アイコンをクリックすることで確認できます。

次に、WordPress プラグインまたはテーマを含むディレクトリに移動します: 

  1. $ cd ~/gutenberg

次に、ローカル環境を開始します: 

  1. $ wp-env start

最後に、ウェブブラウザで http://localhost:8888 に移動して、ローカルの WordPress プラグインまたはテーマが実行され、アクティブになっている WordPress を確認します。デフォルトのログイン認証情報はユーザー名: admin パスワード: password です。

環境の停止

ローカル環境を停止するには: 

  1. $ wp-env stop

一般的な問題のトラブルシューティング

多くの一般的な問題は、次のトラブルシューティング手順を順番に実行することで修正できます:

1. wp-env が実行中であることを確認する

まず、wp-env が実行中であることを確認します。これを確認する方法の一つは、Docker に現在実行中のコンテナのテーブルを印刷させることです: 

  1. $ docker ps

このテーブルには、デフォルトで次の3つのエントリが表示されるはずです: wordpress ポート 8888、tests-wordpress ポート 8889、mariadb ポート 3306。

2. ポート番号を確認する

デフォルトでは wp-env はポート 8888 を使用します。つまり、ローカル環境は http://localhost:8888 で利用可能です。

wp-env が使用するポートを設定して、他のサーバーと衝突しないようにするには、WP_ENV_PORT 環境変数を指定して wp-env を起動します: 

  1. $ WP_ENV_PORT=3333 wp-env start

docker ps を実行し、PORTS 列を調べることで、wp-env が現在使用しているポートを確認できます。

.wp-env.json ファイルにポート番号を指定することもできますが、環境変数が優先されます。

3. 更新とともに wp-env を再起動する

wp-env を再起動すると、基盤となる Docker コンテナが再起動され、多くの問題が修正される可能性があります。

wp-env を再起動するには、wp-env start を再度実行します。自動的にコンテナが停止し、再起動します。--update 引数を渡すと、更新がダウンロードされ、WordPress が再構成されます。 

  1. $ wp-env start --update

4. Docker を再起動する

Docker を再起動すると、基盤となる Docker コンテナとボリュームが再起動され、多くの問題が修正される可能性があります。

Docker を再起動するには:

  • 1. システムトレイまたはメニューバーの Docker アイコンをクリックします。
  • 2. 再起動を選択します。

再起動後、再度 wp-env を開始します: 

  1. $ wp-env start

5. データベースをリセットする

ローカル環境が使用するデータベースをリセットすると、多くの問題が修正される可能性があります。特に、WordPress のインストールに関連する問題です。

データベースをリセットするには:

⚠️ 警告: これにより、ローカルの WordPress インストール内の投稿、ページ、メディアなどが永久に削除されます。 

  1. $ wp-env clean all
  2. $ wp-env start

6. すべてを破棄して再スタートする

すべてが失敗した場合、wp-env destroy を使用して基盤となるすべての Docker コンテナ、ボリューム、およびファイルを強制的に削除できます。これにより、最初からやり直すことができます。

そのためには:

⚠️ 警告: これにより、ローカルの WordPress インストール内の投稿、ページ、メディアなどが永久に削除されます。 

  1. $ wp-env destroy
  4. # この新しいインスタンスは既存のデータがない新しいスタートです:
  6. $ wp-env start

含まれている WordPress PHPUnit テストファイルの使用

デフォルトで wp-env には、インストールされている WordPress のバージョンに対応する WordPress の PHPUnit テストファイル が含まれています。これらのファイルの場所を指す環境変数 WP_TESTS_DIR があります。これらのファイルを環境に含めることで、パッケージを使用したり、自分でインストールしてマウントしたりする必要がなくなります。これらのファイルを使用したくない場合は、WP_TESTS_DIR 環境変数を無視し、任意の場所から読み込む必要があります。

wp-tests-config.php ファイルのカスタマイズ

環境内にデフォルトの wp-tests-config.php ファイルを提供していますが、自分のファイルを使用したい場合もあります。WordPress では、テストに使用する wp-config.php ファイルを変更するために使用できる WP_TESTS_CONFIG_FILE_PATH 定数を提供しています。これを bootstrap.php ファイル内の希望のパスに設定すると、選択したファイルが環境に含まれているファイルの代わりに使用されます。

Composer、phpunit、および wp-cli ツールの使用

使いやすさのために、Composer、PHPUnit、および wp-cli が環境内で利用可能です。これらの実行可能ファイルを実行するには、wp-env run <env> <tool> <command> を使用します。例えば、wp-env run cli composer install や wp-env run tests-cli phpunit です。wp-env run cli bash や wp-env run cli wp shell のようなさまざまなシェルにもアクセスできます。

env 部分では、cli と wordpress はデータベースとマッピングされたボリュームを共有しますが、cli 環境にはさらに多くのツールが利用可能です。tests-cli / tests-wordpress 環境を使用して、別のテストデータベースを作成する必要があります。

デフォルトでは、実行コマンドのカレントワーキングディレクトリは WordPress インストールのルートです。プラグインで作業している場合、--env-cwd を渡して、composer/phpunit コマンドが作業しているプラグインに対して相対的に実行されるようにする必要があります。例えば、wp-env run cli --env-cwd=wp-content/plugins/gutenberg composer install。

これを簡単にするために、package.json ファイルにスクリプトを追加することがよく役立ちます: 

  1. {
  2.    "scripts": {
  3.    "composer": "wp-env run cli --env-cwd=wp-content/plugins/gutenberg composer"
  4.    }
  5. }

その後、npm run composer install は環境内で composer install を実行します。phpunit、wp-cli などについても同様にできます。

Xdebug の使用

Xdebug は wp-env 環境にインストールされていますが、デフォルトではオフになっています。Xdebug を有効にするには、--xdebug フラグを wp-env start コマンドとともに使用できます。フラグの動作についてのリファレンスは次のとおりです: 

  3. # Xdebug モードを「デバッグ」に設定します (ステップデバッグ用):
  5. wp-env start --xdebug
  8. # Xdebug モードを「オフ」に設定します:
  10. wp-env start
  13. # リストされた各 Xdebug モードを有効にします:
  15. wp-env start --xdebug=profile,trace,debug

wp-env を npm run を使用して実行しているとき、Gutenberg リポジトリで作業しているときや wp-env がローカルプロジェクト依存関係であるときは、--xdebug コマンドの前に追加のダブルダッシュを追加することを忘れないでください: 

  1. npm run wp-env start -- --xdebug
  4. # あるいは、npx を使用します:
  6. npx wp-env start --xdebug

それを忘れると、--xdebug パラメータは npm に渡され、wp-env start コマンドは無視されます。

各 Xdebug モードとその動作については、Xdebug ドキュメントを参照してください。

Xdebug 3 のみをインストールしているため、Xdebug は PHP バージョン 7.2 以上 (デフォルト) のみサポートされています。phpVersion がレガシーバージョンに設定されている場合、Xdebug はインストールされません。

Xdebug IDE サポート

IDE から Xdebug に接続するには、これらの IDE 設定を使用できます。この JSON の一部は、VS Code の launch.json 形式 (詳細は こちらで学べます) と この PHP デバッグ拡張 に対してテストされました。そのパスマッピングは特定のプラグインを指しており、wp-env インスタンス内で作業しているソースを指すように更新する必要があります。

port と pathMappings を自分の IDE で使用されている形式に変換するだけで済みます。 

  1. {
  2.    "name": "Listen for XDebug",
  3.    "type": "php",
  4.    "request": "launch",
  5.    "port": 9003,
  6.    "pathMappings": {
  7.    "/var/www/html/wp-content/plugins/gutenberg": "${workspaceFolder}/"
  8.    }
  9. }

リポジトリに .vscode/launch.json ファイルを作成した後、グローバル gitignore ファイルに追加して、プライベートに保ち、リポジトリにコミットされないようにすることをお勧めします。

IDE の Xdebug 設定が有効になったら、デバッガを起動し、PHP コードの任意の行にブレークポイントを置き、ブラウザをリフレッシュするだけで済みます！

要約は次のとおりです:

  • 1. xdebug を有効にして wp-env を開始します: wp-env start --xdebug
  • 2. IDE に適した Xdebug 拡張をインストールします。
  • 3. IDE デバッガをポート 9003 と wp-env 内の正しいソースファイルを使用するように構成します。
  • 4. デバッガを起動し、PHP コードの任意の行にブレークポイントを置きます。
  • 5. wp-env が実行されている URL をリフレッシュすると、ブレークポイントがトリガーされます。

コマンドリファレンス

wp-env は wp-env ホームディレクトリに生成されたファイルを作成します。デフォルトでは、これは ~/.wp-env です。例外は Linux で、ファイルは ~/wp-env に配置されます Snap パッケージとの互換性のため。wp-env ホームディレクトリには、/$md5_of_project_path という名前の各プロジェクトのサブディレクトリが含まれています。wp-env ホームディレクトリを変更するには、WP_ENV_HOME 環境変数を設定します。例えば、WP_ENV_HOME="something" wp-env start を実行すると、プロジェクトファイルがディレクトリ ./something/$md5_of_project_path にダウンロードされます (現在のディレクトリに対して相対的)。

wp-env start

start コマンドは WordPress 環境をインストールおよび初期化し、指定されたリモートソースをダウンロードします。デフォルトでは、wp-env は構成ファイルが変更されない限り、環境を更新または再構成しません。wp-env にソースを更新し、構成オプションを再適用するように指示するには、wp-env start --update を使用します。これにより、既存のコンテンツが上書きされることはありません。 

  1. wp-env start
  3. Starts WordPress for development on port 8888 (​http://localhost:8888​)
  4. (override with WP_ENV_PORT) and tests on port 8889 (​http://localhost:8889​)
  5. (override with WP_ENV_TESTS_PORT). The current working directory must be a
  6. WordPress installation, a plugin, a theme, or contain a .wp-env.json file. After
  7. first install, use the '--update' flag to download updates to mapped sources and
  8. to re-apply WordPress configuration options.
  10. Options:
  11.   --debug    Enable debug output.                     [boolean] [default: false]
  12.   --update   Download source updates and apply WordPress configuration.
  13.    [boolean] [default: false]
  14.   --xdebug   Enables Xdebug. If not passed, Xdebug is turned off. If no modes
  15.    are set, uses "debug". You may set multiple Xdebug modes by passing
  16.    them in a comma-separated list: `--xdebug=develop,coverage`. See
  17.    https://xdebug.org/docs/all_settings#mode for information about
  18.    Xdebug modes.                                              [string]
  19.   --scripts  Execute any configured lifecycle scripts. [boolean] [default: true]

wp-env stop

  1. wp-env stop
  3. Stops running WordPress for development and tests and frees the ports.
  5. Options:
  6.   --debug            Enable debug output.             [boolean] [default: false]

wp-env clean [environment]

  1. wp-env clean [environment]
  3. Cleans the WordPress databases.
  5. Positionals:
  6.   environment  Which environments' databases to clean.
  7.    [string] [choices: "all", "development", "tests"] [default: "tests"]
  9. Options:
  10.   --debug    Enable debug output.                     [boolean] [default: false]
  11.   --scripts  Execute any configured lifecycle scripts. [boolean] [default: true]

wp-env run [command…]

run コマンドは、シェルセッションを開いたり、WP-CLI コマンドを呼び出したり、コンテナ内で任意のコマンドを実行したりするために使用できます。

場合によっては、wp-env run がコンテナに渡すオプションと衝突することがあります。

この場合、wp-env はオプションを自分のものとして扱い、適切にアクションを取ります。

例えば、wp-env run cli php --help を試みると、wp-env ヘルプテキストが表示されます。

これを回避するには、ダブルダッシュの後に衝突するオプションを渡します。wp-env はダブルダッシュの後のすべてを処理せず、単にコンテナに渡します。PHP ヘルプテキストを取得するには、wp-env run cli php -- --help を使用します。 

  1. wp-env run <container> [command...]
  3. Runs an arbitrary command in one of the underlying Docker containers. A double
  4. dash can be used to pass arguments to the container without parsing them. This
  5. is necessary if you are using an option that is defined below. You can use
  6. in all WordPress and CLI containers. WP-CLI is also available in the CLI
  7. containers.
  9. Positionals:
  10.   container  The Docker service to run the command on.
  11.    [string] [required] [choices: "mysql", "tests-mysql", "wordpress",
  12.    "tests-wordpress", "cli", "tests-cli", "composer", "phpunit"]
  13.   command    The command to run.                                      [required]
  15. Options:
  16.   --debug    Enable debug output.                     [boolean] [default: false]
  17.   --env-cwd  The command's working directory inside of the container. Paths
  18.    without a leading slash are relative to the WordPress root.
  19.    [string] [default: "."]

例えば:

開発インスタンスのユーザーを表示:

  1. wp-env run cli wp user list
  2. ⠏ Running `wp user list` in 'cli'.
  4. ID      user_login      display_name    user_email      user_registered roles
  5. 1       admin   admin   wordpress@example.com   2020-03-05 10:45:14     administrator
  7.  Ran `wp user list` in 'cli'. (in 2s 374ms)

テストインスタンスでの投稿の作成:

  1. wp-env run tests-cli "wp post create --post_type=page --post_title='Ready'"
  3.  Starting 'wp post create --post_type=page --post_title='Ready'' on the tests-cli container.
  5. Success: Created post 5.
  6.  Ran `wp post create --post_type=page --post_title='Ready'` in 'tests-cli'. (in 3s 293ms)

テストインスタンスでの WordPress シェルを開き、PHP コマンドを実行する:

  1. wp-env run tests-cli wp shell
  2.  Starting 'wp shell' on the tests-cli container. Exit the WordPress shell with ctrl-c.
  4. Starting 31911d623e75f345e9ed328b9f48cff6_mysql_1 ... done
  5. Starting 31911d623e75f345e9ed328b9f48cff6_tests-wordpress_1 ... done
  6. wp> echo( 'hello world!' );
  7. hello world!
  8. wp> ^C
  9.  Ran `wp shell` in 'tests-cli'. (in 16s 400ms)

開発インスタンスでのプラグインまたはテーマのインストール

  1. wp-env run cli wp plugin install custom-post-type-ui
  3. Creating 500cd328b649d63e882d5c4695871d04_cli_run ... done
  4. Installing Custom Post Type UI (1.9.2)
  5. Downloading installation package from https://downloads.wordpress.org/plugin/custom-post-type-ui.zip...
  6. The authenticity of custom-post-type-ui.zip could not be verified as no signature was found.
  7. Unpacking the package...
  8. Installing the plugin...
  9. Plugin installed successfully.
  10. Success: Installed 1 of 1 plugins.
  11.  Ran `plugin install custom-post-type-ui` in 'cli'. (in 6s 483ms)

パーマリンク構造の変更

これを行うことで、wp-env 環境内の REST API (wp-env/wp/v2/) エンドポイントへのアクセスを有効にすることができます。エンドポイントは、プレーンパーマリンクでは利用できません。

例

パーマリンクを投稿名のみに設定するには: 

  1. wp-env run cli "wp rewrite structure /%postname%/"

パーマリンクを年、月、投稿名に設定するには: 

  1. wp-env run cli "wp rewrite structure /%year%/%monthnum%/%postname%/"

wp-env destroy

  1. wp-env destroy
  3. Destroy the WordPress environment. Deletes docker containers, volumes, and
  4. networks associated with the WordPress environment and removes local files.
  6. Options:
  7.   --debug    Enable debug output.                     [boolean] [default: false]
  8.   --scripts  Execute any configured lifecycle scripts. [boolean] [default: true]

wp-env logs [environment]

  1. wp-env logs
  3. displays PHP and Docker logs for given WordPress environment.
  5. Positionals:
  6.   environment  Which environment to display the logs from.
  7.    [string] [choices: "development", "tests", "all"] [default: "development"]
  9. Options:
  10.   --debug    Enable debug output.                     [boolean] [default: false]
  11.   --watch    Watch for logs as they happen.            [boolean] [default: true]

wp-env install-path

環境ファイルが保存されているパスを取得します。これには、Docker ファイル、WordPress、PHPUnit ファイル、およびダウンロードされたソースが含まれます。

例: 

  1. $ wp-env install-path
  3. /home/user/.wp-env/63263e6506becb7b8613b02d42280a49

.wp-env.json

実行する wp-env ディレクトリ内に .wp-env.json ファイルを指定することで、開発環境が使用する WordPress インストール、プラグイン、およびテーマをカスタマイズできます。

.wp-env.json は、テストおよび開発インスタンスの両方に適用されるオプションのフィールドをサポートしています。

フィールド タイプ デフォルト 説明
"core" `````string\ null````` null 使用する WordPress インストール。null が指定されている場合、wp-env は WordPress の最新の製品リリースを使用します。
"phpVersion" `````string\ null````` null 使用する PHP バージョン。null が指定されている場合、wp-env は WordPress の製品リリースで使用されるデフォルトバージョンを使用します。
"plugins" string[] [] 環境にインストールしてアクティブ化するプラグインのリスト。
"themes" string[] [] 環境にインストールするテーマのリスト。
"port" integer 8888 (8889 テストインスタンス用) インストールに使用する主要なポート番号。ポートを通じてインスタンスにアクセスします: ‘http://localhost:8888’。
"testsPort" integer 8889 テストサイトのポート番号。ポートを通じてインスタンスにアクセスします: ‘http://localhost:8889’。
"config" Object 下記参照。 wp-config.php 定数のマッピング。
"mappings" Object "{}" WordPress ディレクトリをローカルディレクトリにマウントするためのマッピング。
"mysqlPort" integer null (ランダムに割り当てられた) 公開する MySQL ポート番号。この設定は env.development および env.tests オブジェクトでのみ利用可能です。

注: ポート番号環境変数 (WP_ENV_PORT および WP_ENV_TESTS_PORT) は .wp-env.json の値よりも優先されます。

core、plugins、themes、および mappings フィールドには、さまざまなタイプの文字列を渡すことができます。


| タイプ | 形式 | 例 |
| —- | —- | —- |
| 相対パス | .<path>\|~<path> | "./a/directory"、"../a/directory"、"~/a/directory" |
| 絶対パス | /<path>\|<letter>:\<path> | "/a/directory"、"C:\\a\\directory" |
| GitHub リポジトリ | <owner>/<repo>[#<ref>] | "WordPress/WordPress"、"WordPress/gutenberg#trunk"、ブランチが指定されていない場合、wp-env はリポジトリのデフォルトブランチにフォールバックします。 |
| SSH リポジトリ | ssh://user@host/<owner>/<repo>.git[#<ref>] | "ssh://[email protected]/WordPress/WordPress.git" |
| ZIP ファイル | http[s]://<host>/<path>.zip | "https://wordpress.org/wordpress-5.4-beta2.zip" |

リモートソースは ~/.wp-env にある一時ディレクトリにダウンロードされます。

さらに、env キーは、個々の環境に基づいて上記のオプションのいずれかをオーバーライドするために利用可能です。例えば、次の .wp-env.json ファイルを考えてみてください: 

  1. {
  2.    "plugins": [ "." ],
  3.    "config": {
  4.    "KEY_1": true,
  5.    "KEY_2": false
  6.    },
  7.    "env": {
  8.    "development": {
  9.    "themes": [ "./one-theme" ]
  10.    },
  11.    "tests": {
  12.    "config": {
  13.    "KEY_1": false
  14.    },
  15.    "port": 3000,
  16.    "mysqlPort": 13306
  17.    }
  18.    }
  19. }

開発インスタンスでは、cwd がプラグインとしてマッピングされ、one-theme がテーマとしてマッピングされ、KEY_1 が true に設定され、KEY_2 が false に設定されます。また、デフォルトポート 8888 も使用されます。

テストインスタンスでは、cwd は依然としてプラグインとしてマッピングされますが、テーマはマッピングされません。さらに、KEY_2 は依然として false に設定されていますが、KEY_1 はオーバーライドされて false に設定されます。3000 はデフォルトポートをオーバーライドします。

これにより、各環境に適用されるオプションを変更するための多くの権限が与えられます。

.wp-env.override.json

ここにあるフィールドはすべて .wp-env.json よりも優先されます。このファイルは、バージョン管理から無視されると便利で、ローカル開発のオーバーライドを保持します。plugins や themes のようなオプションはマージされないことに注意してください。その結果、オーバーライドファイルで plugins を設定すると、ベースレベルの設定にリストされているすべてのプラグインがオーバーライドされます。マージされるのは config と mappings のみです。これにより、デフォルト値を失うことなく独自の wp-config 値を設定できます。

デフォルトの wp-config 値。

開発インスタンスでは、これらの wp-config 値がデフォルトで定義されています: 

  1. WP_DEBUG: true,
  2. SCRIPT_DEBUG: true,
  3. WP_PHP_BINARY: 'php',
  4. WP_TESTS_EMAIL: '[email protected]',
  5. WP_TESTS_TITLE: 'Test Blog',
  6. WP_TESTS_DOMAIN: 'localhost',
  7. WP_SITEURL: 'http://localhost',
  8. WP_HOME: 'http://localhost',

テストインスタンスでは、上記のすべてが依然として定義されていますが、WP_DEBUG と SCRIPT_DEBUG は false に設定されています。

これらは config 構成内で値を設定することでオーバーライドできます。null に設定すると、定数が完全に定義されないようになります。

さらに、URL を参照する値には、指定された環境のポートが含まれます。したがって、testsPort: 3000, port: 2000 を設定すると、WP_HOME (例えば) は開発インスタンスで http://localhost:3000` on the tests instance andhttp://localhost:2000` になります。

ライフサイクルスクリプト

lifecycleScripts オプションを .wp-env.json で使用すると、ライフサイクルの特定のポイントで実行される任意のコマンドを設定できます。この構成

は、WP_ENV_LIFECYCLE_SCRIPT_{LIFECYCLE_EVENT} 環境変数を使用してオーバーライドすることもでき、残りはオプションのすべて大文字のスネークケース名になります。例えば、WP_ENV_LIFECYCLE_SCRIPT_AFTER_START。これらは新しい環境と既存の環境の両方で実行されるため、構築するコマンドが後続の実行で壊れないことを確認してください。

  • afterStart: wp-env start の環境設定が完了した後に実行されます。
  • afterClean: wp-env clean の環境クリーニングが完了した後に実行されます。
  • afterDestroy: wp-env destroy の環境が破壊された後に実行されます。

例

最新の安定版 WordPress + 現在のディレクトリをプラグインとして

これはプラグイン開発に役立ちます。 

  1. {
  2.    "core": null,
  3.    "plugins": [ "." ]
  4. }

最新の開発版 WordPress + 現在のディレクトリをプラグインとして

これは、上流のコアの変更をテストする必要があるプラグイン開発に役立ちます。これは環境変数 WP_ENV_CORE を介して設定することもできます。 

  1. {
  2.    "core": "WordPress/WordPress#master",
  3.    "plugins": [ "." ]
  4. }

ローカル wordpress-develop + 現在のディレクトリをプラグインとして

これは、プラグインと WordPress コアの両方で同時に作業するのに役立ちます。

wordpress-develop のビルドを実行している場合は、core を build ディレクトリにポイントします。 

  1. {
  2.    "core": "../wordpress-develop/build",
  3.    "plugins": [ "." ]
  4. }

wordpress-develop を dev モード (例: watch コマンド dev または dev ビルド build:dev) で実行している場合は、core を src ディレクトリにポイントします。 

  1. {
  2.    "core": "../wordpress-develop/src",
  3.    "plugins": [ "." ]
  4. }

完全なテスト環境

これは統合テストに役立ちます。つまり、古いバージョンの WordPress と異なるプラグインやテーマの組み合わせが互いにどのように影響するかをテストします。 

  1. {
  2.    "core": "WordPress/WordPress#5.2.0",
  3.    "plugins": [ "WordPress/wp-lazy-loading", "WordPress/classic-editor" ],
  4.    "themes": [ "WordPress/theme-experiments" ]
  5. }

mu-plugins およびその他のマッピングされたディレクトリの追加

マッピング構成を介して mu-plugins を追加できます。マッピング構成を使用すると、WordPress インストール内の任意の場所にディレクトリをマウントできるため、サブディレクトリをマウントすることもできます。ここで注意すべきは、theme-1 はアクティブ化されないことです。 

  1. {
  2.    "plugins": [ "." ],
  3.    "mappings": {
  4.    "wp-content/mu-plugins": "./path/to/local/mu-plugins",
  5.    "wp-content/themes": "./path/to/local/themes",
  6.    "wp-content/themes/specific-theme": "./path/to/local/theme-1"
  7.    }
  8. }

インスタンスでプラグインやテーマをアクティブ化しないようにする

plugins キー内のすべてのプラグインはデフォルトでアクティブ化されるため、mappings キーを使用してこの動作を回避する必要があります。これは、常にアクティブ化されるべきではないテストプラグインがある場合に役立ちます。 

  1. {
  2.    "plugins": [ "." ],
  3.    "mappings": {
  4.    "wp-content/plugins/my-test-plugin": "./path/to/test/plugin"
  5.    }
  6. }

テスト環境でのみプラグインをマッピングする

ある環境でプラグインをアクティブにする必要があるが、他の環境ではそうでない場合、env.<envName> を使用して特定の環境に固有のオプションを設定できます。ここでは、テストインスタンスで cwd とテストプラグインをアクティブ化します。このプラグインは他のインスタンスではアクティブ化されません。 

  1. {
  2.    "plugins": [ "." ],
  3.    "env": {
  4.    "tests": {
  5.    "plugins": [ ".", "path/to/test/plugin" ]
  6.    }
  7.    }
  8. }

カスタムポート番号

wp-env にカスタムポート番号を使用するように指示して、インスタンスが他の wp-env インスタンスと衝突しないようにできます。 

  1. {
  2.    "plugins": [ "." ],
  3.    "port": 4013,
  4.    "env": {
  5.    "tests": {
  6.    "port": 4012
  7.    }
  8.    }
  9. }

これらは、環境変数 WP_ENV_PORT、WP_ENV_TESTS_PORT、WP_ENV_MYSQL_PORT および WP_ENV_TESTS_MYSQL_PORT を介して設定することもできます。

特定の PHP バージョン

wp-env に特定の PHP バージョンを使用するように指示して、互換性とテストを行うことができます。これは環境変数 WP_ENV_PHP_VERSION を介して設定することもできます。 

  1. {
  2.    "phpVersion": "7.2",
  3.    "plugins": [ "." ]
  4. }

ノードライフサイクルスクリプト

これは、環境を設定した後にいくつかのアクションを実行するのに役立ちます。たとえば、E2E テスト環境をブートストラップすることです。 

  1. {
  2.    "lifecycleScripts": {
  3.    "afterStart": "node tests/e2e/bin/setup-env.js"
  4.    }
  5. }

高度な PHP 設定

.htaccess ファイルをマッピングすることで PHP 設定を設定できます。これは、.htaccess ファイルを /var/www/html から wp-env を実行するディレクトリにマッピングします。 

  1. {
  2.    "mappings": {
  3.    ".htaccess": ".htaccess"
  4.    }
  5. }

その後、.htaccess ファイルには次のようなさまざまな設定を含めることができます: 

  3. # 注: デフォルトのアップロード値は 1G です。
  5. php_value post_max_size 2G
  6. php_value upload_max_filesize 2G
  7. php_value memory_limit 2G

これは、環境内でアクセスが難しい php.ini に追加したいオプションがある場合に役立ちます。

このパッケージへの貢献

これは Gutenberg プロジェクトの一部である個別のパッケージです。このプロジェクトはモノレポとして整理されています。特定の目的を持つ複数の自己完結型ソフトウェアパッケージで構成されています。このモノレポ内のパッケージは、npm に公開され、WordPress や他のソフトウェアプロジェクトで使用されています。

このパッケージや Gutenberg 全体への貢献について詳しく知りたい場合は、プロジェクトの主要な 貢献者ガイド をお読みください。