WordPress公式dockerパッケージ wp-env による開発環境構築 – Capital P

二ヶ月ほど前に WordPressによる公式Dockerコンテナである wp-env がリリースされたが、現在は日本語ドキュメントの整備も進み、かなり成熟してきたようだ。

wp-envの特徴

さて、wp-envはDockerのnpmラッパーといった趣で、次のような .wp-env.json をリポジトリに用意しておくことで、開発環境がまるっと用意できる。

{
  "core": null,
  "plugins": [
    "."
  ]
}

Dockerを利用したWordPress開発環境はいくつかあるが、利点は下記の通り。

公式でサポートされている。たとえば Docker がリリースしているWordPressイメージなどはファイルパーミッションなどがやや微妙だった。
DockerとNode（v12以上）がインストールされていれば、環境を再現できる。追加ソフトウェアのインストールは不要（というより、npm経由ですべて揃う）なので、チームでの共有が楽。
プラグイン・テーマ単位での利用を想定しており、依存プラグインやテーマを指定することも難しくない。ローカルディレクトリも指定できる。したがって、受託案件などでも利用可能。
筆者のように数十個ものプラグイン・テーマをメンテしている場合、個別にWordPress環境を用意しなくてよいのが嬉しい。

リポジトリ上でのユースケース

さて、それでは実際のリポジトリで例を見てみよう。今回は筆者が運営するWordPressテーマ＆プラグインマーケットプレースで「テーマ作者に楽をしてもらおう」と作成している、kunoichi/theme-customizer というライブラリを取り上げる。ざっくり特徴を挙げると……

カスタマイザー項目を簡単に作成するためのライブラリである。
1クラスで1項目グループになっているので、カスタマイザーの項目をまとめることができる。
名前空間ベースで自動登録するので、add_actionなどをいろんなところに書き散らす必要はない。
テーマでよくある設定グループは設定済みクラスとして用意している。SEO設定やシェアボタンの表示有無など。
プラグイン形式で開発されているが、composer(packagist)経由でリリースされている。

このリポジトリの .wp-env.json を見てみると、次の通り。

{
  "core": null,
  "plugins": [ "." ],
  "themes": [
    "https://downloads.wordpress.org/theme/twentytwenty.latest-stable.zip"
  ]
}

"core": null としている場合、最新リリース版が利用される。
プラグインとしてカレントディレクトリを指定すると、そのままDockerコンテナ内でそのプラグインが有効化された状態で始まる。もしWooCommerceに依存したプラグインを作成しているなら、WooCommerceプラグインのZip URLを追加する。
テーマはTwenty Twenty を利用。ちなみに、テーマ・プラグインのバージョンを指定することもできる。latest-stable の部分をバージョン番号に変えれば良い。

他にもポートなどしているできるものがたくさんあるので、詳しくはドキュメントを見て欲しい。

つづいて、package.jsonを見てみよう。

{
  "name": "theme-customizer",
  "version": "1.0.0",
  "description": "A handy PHP class to integrate WordPress Theme Customizer.",
  "main": "index.js",
  "directories": {
    "test": "tests"
  },
 "engines" : {
   "node" : ">=12.0"
 },
"scripts": {
    "start": "wp-env start",
    "test": "echo \"Error: no test specified\" && exit 1",
    "env": "wp-env",
    "cli": "wp-env run cli wp"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/kuno1/theme-customizer.git"
  },
  "keywords": [
    "wordpress"
  ],
  "author": "Kunoichi INC <sushi@kunoichiwp.com>",
  "license": "GPL-3.0-or-later",
  "bugs": {
    "url": "https://github.com/kuno1/theme-customizer/issues"
  },
  "homepage": "https://github.com/kuno1/theme-customizer#readme",
  "devDependencies": {
    "@wordpress/env": "^1.3.0"
  }
}

wp-envのインストールは npm install --dev @wordpress/env で可能。scriptsにはいくつかのスクリプトを登録してある。

startは wp-env start のショートハンドに。npm startとすればWordPressが起動する。
env コマンドは停止 stop やDB削除 clean などのショートハンドとして利用。e.g.npm run env clean
cliでWP CLIのコマンドを実行できる。 e.g. npm run cli user list

以上の設定により、当該リポジトリでのWordPress開発は4コマンドで始められる。

git clone git@github.com:kuno1/theme-customizer.git
composer install # 必要なら
npm install
npm start

「WordPress環境を用意して wp-content/plugins に移動〜」などと言わなくてよいというのはだいぶお手軽だ。

設定の上書き

さて、場合によっては次のようなケースも考えられる。

プロジェクトAで使っていたプラグインをプロジェクトBでも試したいが、利用するテーマが違う。
WordPressの特定のバージョンでの動作を確認したい。
他のプラグイン（e.g. WooCommerce）に依存する機能を新規開発したいが、WooCommerceがないときの動作も確かめたい。

このようなケースに対し、wp-envは上書き用ファイル .wp-env.override.json が存在する場合、フィールドの値を上書きする。したがって、上記の例でたとえば依存プラグインにWooCommerceを追加したいとなれば、次のような内容を追加すれば良い。

{
  plugins: [
    ".",
    "https://downloads.wordpress.org/plugin/woocommerce.latest-stable.zip"
  ]
}

また、ドキュメントにも書かれている通り、この上書きファイルをリポジトリの無視リスト（.gitignore）に追加しておくことをオススメする。

wp-envの今後

さて、ざっくりとではあるが、wp-envの使い方について説明した。おそらくではあるが、今後のWordPressコア開発は wp-env + GitHubに移行していくだろうし、実際に一部のコントリビューターはすでにそうしているようだ。

wp-envには環境別の指定（production, test）などの項目もあることから、Kubernetesのようなコンテナオーケストレーション環境へのデプロイも視野に入れているのだろう。また、今回は触れなかったが、ユニットテストなども必要なものがそろった状態で始められるはずだ。

なんにせよ、開発も活発であり、コアで実際に使われ始めているので、WordPress開発環境に悩んでいる方は試してみてはいかがだろうか。

wp-envの特徴

リポジトリ上でのユースケース

設定の上書き

wp-envの今後

コメントを残すコメントをキャンセル