2020-04-30

Craft CMS の Project Config でベースをサクッと用意する #craftcms

Craft 3.1 から Project Config の機能はあったのだけど、ちゃんと使ったことがなかったので試してみた。

プロジェクトコンフィグ | Craft 3 ドキュメント
https://docs.craftcms.com/v3/j...
Project Config | Craft 3 Documentation
https://docs.craftcms.com/v3/p...

Project Config を使うことで以下の設定を引き継ぐことができる。

  • アセットボリューム、および、名前付けされた画像の変形
  • カテゴリグループ
  • Craft、および、プラグインのスキーマのバーション
  • Craft のエディション
  • メールの設定
  • フィールド、および、フィールドグループ
  • グローバル設定（設定のみ、コンテンツを含みません）
  • 行列ブロックのタイプ
  • プラグインのエディション、および、設定
  • 「設定 > ルート」のルート定義
  • セクション、および、入力タイプ
  • サイト、および、サイトグループ
  • システム名、タイムゾーン、および、システムのステータス（稼働中 / オフライン）
  • タググループ
  • ユーザー設定、および、ユーザーグループ

カテゴリとかはエントリ同様に管理画面からつくってDBに保存されているので、 Project Config だけでは引き継ぐことは難しい。
そこは Feed Me などで引き継ぐのが良いと思われる。

Project Config のドキュメントはDBをエクスポートしてインポートするという感じの記述があるので、それ通りにやると丸っと環境を持っていくことができる。
ある意味、Project Config は関係ないとも言えるのだけど。

Project Config の設定を有効にする

元となる環境の config/general.php で、 Project Config の設定を有効にする。

return [
'*' => [
    'useProjectConfigFile' => true,
],
];

これを有効にした状態で、管理画面にアクセスすると、 project.yaml が生成される。

Project Config を使って別の環境で再現する

Craft CMS を別の環境にインストールする。
DBを合わせて持っていく場合は別の環境に Craft CMS をインストールして、DBをインポートする。

project.yaml と general.php を元の環境から別の環境へ持っていくことで状態を復元できる。

ドキュメントに記述はないけど、 composer.json も合わせて持っていくことで、プラグイン周りもインストールできる。
（composer.lock はいったん削除なりリネームしておいて composer install を実行する）

DBを持って行った時はこのようなかんじでエントリ等も移行できる。

DBは持って行かずにCraft CMSを新規インストールして、元の環境から project.yaml, general.php を持って行った時はこのようにセクションなど箱だけが復元できる。

なのでよく使うセクションとかのセットを1つ用意しておき、その設定を project.yaml として保持しておく。
Craft CMS をインストールしたらそれらを使うことで、開発時のスタートとして簡単に始められる。

general.php, project.yaml, composer.json, templates/ あたりをぬかみそ的に自分たちのものとして育てていくと良さそうに思う。

composer.json を入れる場合はプラグインの設定がそれぞれ hoge.php とかであったりするからそれもあってもいいのかもしれない。

更新したproject.yamlの内容を反映する

一度 Project Config の設定をしておくと元の環境で管理画面から設定変えたりするとその内容が project.yaml に反映される。

その project.yaml を別の環境に持っていくとこのような感じで適用するかどうか？のメッセージが出る。

これを同期することで、別環境でも変更を適用することができる。

before がないからわかりにくいのだけど、元の環境で craft34 というセクションを追加して、その project.yaml を持ってくることで別環境でもセクションが再現できた。

本番環境と開発環境でデータは本番環境が正だけど、セクションとかの箱は共通だったり、開発環境で調整してから本番環境へ持っていく、という時にはこういう使い方もできるかもしれない。

project.yaml に差分が出ないように変更を制御する

データ自体に整合性がない場合は Project Config を使ったほうがスムーズにいく場合もありそう。

そういう環境構成の時は本番環境での変更が project.yaml に設定されては困る場合もあると思う。

general.php の allowAdminChanges 設定を以下のようにしておくことで管理画面での設定は変更できなくなる。

return [
    '*' => [
        'useProjectConfigFile' => true,
    ],
    'production' => [
        // Disable project config changes on production
        'allowAdminChanges' => false,
    ], 
];

元々の管理画面の左カラムメニュー

allowAdminChanges が false の時。

「設定」「プラグインストア」のメニューが非表示になっている。

composer.json からプラグインをインストールしていない時のエラー

composer.json を持って行っていないとこのような感じでプラグイン関係がインストールされていなくて、ロードできないとか出る。

ドキュメントには書かれていないのだけど、 composer.json もセットの方が良いとは思う。

ということでまずは bit part 用のデフォルトセットみたいなのを作っておこうと思う。

最近参加したプロジェクトでは振り返りや複数の人が参加した時に困らないようなルールづくりとかドキュメント準備とかがしっかりしてたので、そういうのを見習ってやっていきたいところだなー

参考