Planet4 の環境構築

Before anything
Set node version:
.nvmrc
を見ると 16 になっている。
asdf install nodejs 16.20.2
asdf local nodejs 16.20.2
Check the requirements:
npm run env:requirements
> planet4-develop@0.7.1 env:requirements
> node ./scripts/requirements.js
Shell:
/bin/zsh
Node version: v16.20.2
Docker version:
✓ Found: Docker version 24.0.6, build ed223bc
Docker compose version:
✓ Found: Docker Compose version v2.21.0-desktop.1
wp-env version:
✗ Not found. Please install wp-env.
node:child_process:935
throw err;
wp-env
が無いと言われる。
これどうするんだろう?
package.json に @wordpress/env
があるから、まあいいのかな。
Install npm packages:
npm install
もう一度 np run env:requirements
すると、wp-env
のエラーは消えるが、代わりに nvm を入れろと言われる。おそらく無くても大丈夫だろう。
Installation
Install default developer environment with:
npm run env:install
一部エラーが出た。
✔ Ran `composer update -n` in 'cli'. (in 5s 90ms)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 116M 100 116M 0 0 16.2M 0 0:00:07 0:00:07 --:--:-- 21.7M
Importing default database ...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1871k 100 1871k 0 0 1098k 0 0:00:01 0:00:01 --:--:-- 1099k
✔ (in 0s 775ms)
✔ (in 0s 751ms)
✔ (in 0s 639ms)
sed: RE error: illegal byte sequence
ℹ Starting 'wp config set DB_NAME planet4_dev' on the cli container.
Success: Updated the constant 'DB_NAME' in the 'wp-config.php' file with the value 'planet4_dev'.
✔ Ran `wp config set DB_NAME planet4_dev` in 'cli'. (in 0s 901ms)
ℹ Starting 'wp plugin activate --all' on the cli container.
Plugin 'gravityformshubspot' activated.
Plugin 'gravityformsquiz' activated.
Plugin 'planet4-plugin-medialibrary' activated.
Success: Activated 3 of 19 plugins.
✔ Ran `wp plugin activate --all` in 'cli'. (in 11s 450ms)
ℹ Starting 'wp user create admin admin@planet4.test --user_pass=admin --role=administrator' on the cli container.
Error: The 'admin' username is already registered.
✖ Command failed with exit code 1
Command failed with exit code 1
ℹ Starting 'wp user update admin --user_pass=admin --role=administrator' on the cli container.
sendmail: can't connect to remote host (127.0.0.1): Connection refused
Success: Updated user 1.
✔ Ran `wp user update admin --user_pass=admin --role=administrator` in 'cli'. (in 1s 638ms)
The local instance is now available at http://www.planet4.test/
nro
の意味がわかっていなかったが、National/Regional Organization ということで、japan を入れてみたらうまく行った。
npm run nro:install japan
npm run env:status
> planet4-develop@0.7.1 env:status
> docker compose -f $(npx wp-env install-path)/docker-compose.yml -f scripts/docker-compose.p4.yml ps --all
✔ (in 1s 42ms)
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
6d1ea266e663480e85fc5851037ddd6c-cli-1 6d1ea266e663480e85fc5851037ddd6c-cli "docker-entrypoint.sh /bin/sh -c 'while true; do sleep 2073600; done'" cli 7 minutes ago Up 7 minutes
6d1ea266e663480e85fc5851037ddd6c-mysql-1 mariadb "docker-entrypoint.sh mariadbd" mysql 7 minutes ago Up 7 minutes 0.0.0.0:57493->3306/tcp
6d1ea266e663480e85fc5851037ddd6c-tests-cli-1 6d1ea266e663480e85fc5851037ddd6c-tests-cli "docker-entrypoint.sh /bin/sh -c 'while true; do sleep 2073600; done'" tests-cli 7 minutes ago Up 7 minutes
6d1ea266e663480e85fc5851037ddd6c-tests-mysql-1 mariadb "docker-entrypoint.sh mariadbd" tests-mysql 7 minutes ago Up 7 minutes 0.0.0.0:57507->3306/tcp
6d1ea266e663480e85fc5851037ddd6c-tests-wordpress-1 6d1ea266e663480e85fc5851037ddd6c-tests-wordpress "docker-entrypoint.sh apache2-foreground" tests-wordpress 7 minutes ago Up 7 minutes 0.0.0.0:8889->80/tcp
6d1ea266e663480e85fc5851037ddd6c-wordpress-1 6d1ea266e663480e85fc5851037ddd6c-wordpress "docker-entrypoint.sh apache2-foreground" wordpress 7 minutes ago Up 7 minutes 0.0.0.0:80->80/tcp
サイトを見る
特にドキュメントに説明は無い。
> planet4-develop@0.7.1 env:start
> npx wp-env start
WordPress development site started at http://www.planet4.test/
WordPress test site started at http://www.planet4.test:8889/
MySQL is listening on port 58029
MySQL for automated testing is listening on port 58030
✔ Done! (in 2s 195ms)
とある。
となっている。もちろん、このドメインは私は利用できない。
とりあえず、CircleCI の設定で、 /etc/hosts
を書き換えて対応しているようなので、これに習う。
とりあえず出てきた。
admin ページも閲覧してみる。
初期のパスワードは admin
でいいようだ。

何度かインストール作業を繰り返していると、エラーが出ることがわかってきた。
深追いはしていないが、どうやら planet4 は複数のリポジトリを planet4-develop リポジトリで統合して開発するのだが、そこでどのブランチや tag を使うかで変わってくる。
なので、今後も今回の手順が正しいかはわからないが、そこを頭に入れておくと良さそう。
npm run env:install で npm install エラーが出る
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: @wordpress/components@25.7.0
npm ERR! Found: react@18.2.0
npm ERR! node_modules/@wordpress/components/node_modules/react
npm ERR! react@"^18.2.0" from @wordpress/element@5.18.0
npm ERR! node_modules/@wordpress/components/node_modules/@wordpress/element
npm ERR! @wordpress/element@"^5.18.0" from @wordpress/components@25.7.0
npm ERR! node_modules/@wordpress/components
npm ERR! dev @wordpress/components@"^25.7.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^18.0.0" from @wordpress/components@25.7.0
npm ERR! node_modules/@wordpress/components
npm ERR! dev @wordpress/components@"^25.7.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: react@18.2.0
npm ERR! node_modules/react
npm ERR! peer react@"^18.0.0" from @wordpress/components@25.7.0
npm ERR! node_modules/@wordpress/components
npm ERR! dev @wordpress/components@"^25.7.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
以下の2つの依存リポジトリで package.json が配置されており、このあたりで conflict が起こっているのではないかと思います。
.p4-env.json で依存リポジトリのコミットを指定
wp-env.json と merge される形になる .p4-env.json
が定義されています。
これを以下のようにします。main
の代わりに現時点での最新のリリースタグを利用します。
"images": "1-25"
},
"repos": {
- "planet4-base": "main",
- "planet4-master-theme": "main",
- "planet4-plugin-gutenberg-blocks": "main"
+ "planet4-base": "v2.113.0",
+ "planet4-master-theme": "v1.266.0",
+ "planet4-plugin-gutenberg-blocks": "v1.67.0"
},
"composer": {
"processTimeout": "600"
この状態で再度 npm run env:install
すると無事にサイトが見れるようになりました。
Japan テーマの適用で Class 'Timber\Menu' not found のエラーが出る
npm run nro:install japan
を使って、Japan のテーマでサイトを立ち上げようとすると以下のエラーが出ます。
PHP Fatal error: Uncaught Error: Class 'Timber\Menu' not found in /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-theme-navbar.php:27
Stack trace:
#0 /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-theme-navbar.php(19): P4JP_Theme_Navbar->hooks()
#1 /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-loader.php(95): P4JP_Theme_Navbar->__construct()
#2 /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-loader.php(54): P4JP_Theme_Loader->load_services(Array)
#3 /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-loader.php(42): P4JP_Theme_Loader->__construct(Array)
#4 /var/www/html/wp-content/themes/planet4-child-theme-japan/functions.php(33): P4JP_Theme_Loader::get_instance()
#5 /var/www/html/wp-settings.php(591): include('/var/www/html/w...')
#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('/var/www/html/w...')
#7 phar:///usr/local/bin/wp/vendor/wp-cli/wp-c in /var/www/html/wp-content/themes/planet4-child-theme-japan/classes/class-p4jp-theme-navbar.php on line 27
ここに関しては二つの手当てをする必要がありました。
npm run env:install を事前に実行する
Installation のページでは
For NRO developers, use instead:
と書いてある通り、 npm run nro:install japan
とする場合には、 npm run env:install
は不要のように書かれています。
しかし、今回のケースでは事前に実行する必要がありました。(ここに関しては私の読み違いがあるのかもしれません)
ちなみに、順序が逆でも成功はするのですが、その場合には管理画面が日本語化されません。
planet4-develop を最新のリリースタグに変更する
ドキュメントでは main
ブランチで開発するように書いてあります(というか、実際そうする必要があると思います)が、今回のエラーを解消するには最新のリリースタグに変更する必要がありました。
現時点でいえば、 v0.7.1
になります。
この状態で、上記の npm run env:install
, npm run nro:install japan
を順に実行することで、無事に Japan のテーマが入った状態のサイトが動くようになりました。

Japan テーマのテンプレートを使って固定ページを作る
Japan テーマを適用したサイトにしても、DB は変更されないので、見た目は master テーマと変わりません。よって、メニューも master テーマの内容と同じになります。
Japan のテーマは以下の固定ページ用のテンプレートを issue ページのために用意しています。
また、issue の内容はすでに twig で記述されており以下に格納されています。
実際のサイトで言えば、 https://www.greenpeace.org/japan/explore/ の配下のページ群にあたります。
このテンプレートを使うには例えば以下のようにテンプレートを Issue Page
を利用するようにします。
そして twig で記述された内容を利用するには、 URL を plastic
や climate
など、上記の twig のファイル名の _head.twig
, _content.twig
の前の prefix を指定すれば良いです。(上記であれば plastic
を指定しています)
プレビューすると以下のように内容を含めたページが確認できます。(画像はなぜか環境を考慮しないパスになっているのでローカルでは表示できません。)
固定ページとして登録できれば、後は外観から、メニューを編集し追加すればOKです。

開発完了からデプロイまでの流れ
NRO について上記の資料があるが、現在は古くなっている。
具体的には
-
planet4-<nro>
に対してタグを作ったりする操作は原則不要
ということである。deployment に関するトリガーの処理等は planet4-<nro>
に書かれているのだが、それらはすべて子テーマの方に連動している。
以下は、Github の権限が付与されている前提で書いている。(contributor や planet4 のプロジェクトに関わる必要がある)
dev サイトへのデプロイ
子テーマのリポジトリの main
ブランチにデプロイ対象のコードを入れればいい。
おそらくは PR を作成して merge するのが行儀がいいのだが、守られていないケースも散見される。
Github から移動できるが、以下の CicleCI のページでも進捗が確認できる。
また、ここでビルドが成功すると、そのまま planet4-japan のリポジトリにもコミットが作られトリガーが動き出し、dev サイトへのデプロイが実行される。
production サイトへのデプロイ
ここでも子テーマのリポジトリを使う。(ドキュメントとは異なっている)
子テーマのリリースを作成し tag を作成することになる。
tag に関しては、前回のタグからパッチバージョンを上げるだけで良い。(おそらく 10 が上限なので、それを超えるとマイナーバージョンが上がる。)
また、ブランチは通常 main
からで良さそうである。(と案内された)
上記の CircleCI の Pipeline の Workflow が production
となっているものが production デプロイに関するものになる。
Github 上ではコミットは積まれないので、タグを打った commit のビルドステータスから CircleCI のページに行ける。
staging / production デプロイ
dev 同様にこちらも planet4-japan のリポジトリの方がデプロイを担っている。
tag は自動で打たれ、その tag が打たれた commit のビルドステータスから CircleCI のジョブを辿れる。
上記の production
workflow が該当する。
上記のように workflow が組まれているが、[HOLD]
を commit message につけない限りは自動で production deploy まで進む。(ここはドキュメント通り)
この段階まで進むと、staging と production サイトに反映されているため、動作確認ができる。
つまり、NRO の場合は、もしも最終のチェック等をする場合には dev サイトの段階で行う必要がある。
リリースノート
上記を見ると、一応書かれているようであるが、書かなくていいと中の人に言われた。(おそらく何かルールがあるんだろう)