目次
きっかけ
WordPressのテーマ開発といえば、昔ながらのPHPテンプレートをゴリゴリ書いていくイメージがあるかもしれない。でも最近のWeb開発の世界では、コンテナ化された開発環境、コンポーネント指向のテンプレート、高速なビルドツールが当たり前になっている。
「WordPressだってモダンな開発体験ができるはずだ」という思いから、Sage（Rootsが開発しているスターターテーマ）をベースにした開発環境を構築してみた。
選んだ技術とその理由
開発環境：Docker
正直に言うと、Dockerを選んだのは「別のマシンで環境構築するのが面倒だから」という身も蓋もない理由だ。
PHPのバージョンを揃えて、MySQLをインストールして、WordPressを配置して、パーミッションを調整して……という作業を、新しいマシンを使うたびにやりたくない。以前の環境で何をどう設定したか、半年も経てば忘れている。
Dockerでコンテナ化しておけば、必要な設定はすべてファイルに記述されている。新しいマシンでもコンテナを起動するだけで、前と同じ環境が手に入る。「あのとき何をインストールしたんだっけ」と悩む時間がなくなる。
副次的に、ホストマシンの環境を汚さないという利点もある。PHPやMySQLをローカルにインストールしなくていいし、プロジェクトごとに異なるバージョンを使い分けるのも簡単だ。
ただし、WindowsやmacOSではファイルI/Oが遅くなることがあるし、小規模なテーマ開発ではオーバーヘッドが気になる場面もある。ローカル環境の構築に抵抗がなければ、Dockerなしでも問題ない。自分の場合は「環境構築を二度とやりたくない」という気持ちが勝った。
テンプレートエンジン：Laravel Blade
WordPressの標準的なテンプレートは、正直読みにくい。PHPの開始タグと終了タグが入り乱れて、条件分岐やループを書くたびに <?php と ?> を行ったり来たりする。後から見返したときに「これ何やってるんだっけ」となることが多い。
Laravel Bladeを使うと、これがかなりすっきりする。@if や @foreach といったディレクティブで制御構造を書けるし、変数の出力も直感的な記法になる。単純に、コードが読みやすくなる。
Bladeは出力時のエスケープをデフォルトで行ってくれるので、うっかりエスケープし忘れる心配が減る。ただし、the_content() のようなWordPress特有のHTML出力や、ユーザー入力を扱う部分では従来どおり適切なサニタイズが必要だ。Bladeを使えばすべて安全、というわけではない。
レイアウト継承の仕組みもある。ヘッダーやフッターを共通化して、各ページで必要な部分だけ書けばいい。同じコードをコピペして回る必要がなくなる。
その分、学習コストはかかる。Bladeの記法やSageのディレクトリ構造に慣れるまでは少し時間が必要だ。
ビルドツール：Vite
以前はwebpackを使っていたけど、設定が複雑すぎて毎回調べ直すのが嫌になった。
Viteは設定がシンプルだし、何より開発サーバーの起動が速い。CSSやJavaScriptを編集すると、HMR（Hot Module Replacement）で即座に反映される。ページ全体がリロードされることなく、変更した部分だけがスッと切り替わるのは快適だ。
Bladeテンプレートの変更は自動リロードで反映される。こちらはHMRではなくページ全体のリフレッシュになるけど、それでも手動でリロードする手間は省ける。
本番ビルドの最適化も自動でやってくれるので、そのあたりを自分で設定する手間も省ける。
CSSフレームワーク：Tailwind CSS
CSSを別ファイルに書いて、クラス名を考えて、HTMLとCSSを行き来する……というのが面倒だった。TailwindならHTMLにユーティリティクラスを書くだけでスタイリングできる。
最初は「HTMLが汚くなるのでは」と思ったけど、実際に使ってみると、スタイルがどこに定義されているか探し回る手間がなくなって楽だった。使われているクラスだけが最終的なCSSに含まれるので、ファイルサイズも小さく保てる。
TailwindとWordPressの theme.json は思想的に相性が良い。カラーパレットやタイポグラフィを揃えることで、エディタとフロントエンドの一貫性を保ちやすい。ただし自動で連携してくれるわけではなく、両者を同期させる設計は自分で行う必要がある。
アーキテクチャの考え方
関心の分離
このテーマでは、「アプリケーションロジック」「テンプレート」「アセット」を分けている。
WordPressのフックやカスタム投稿タイプの登録はアプリケーションロジックに、HTMLの構造はBladeテンプレートに、CSS・JavaScript・画像はアセットに。それぞれ置き場所が決まっているので、「あのコードどこに書いたっけ」と探し回ることが減る。
Laravel Acornによる機能拡張
SageはLaravel Acornという仕組みを通じて、Laravelの機能の一部をWordPressに持ち込んでいる。サービスプロバイダーで起動処理を整理したり、依存性注入でコードを整理したりできる。
WordPressの伝統的なやり方（グローバル関数をたくさん定義する）に比べると、コードの見通しが良くなる。ただし、WordPressのライフサイクルとLaravelの設計思想が完全に一致しているわけではないので、プラグインとの連携などで戸惑う場面もある。慣れるまでは少し時間がかかる。
開発体験
実際の開発フローはこんな感じになる。
開発サーバーを起動すると、ファイルの変更を監視してくれる。CSSやJavaScriptはHMRで即座に反映され、Bladeテンプレートは自動リロードで確認できる。
本番環境にデプロイするときは、ビルドコマンドで最適化されたアセットを生成して、必要なファイルだけをサーバーにアップロードする。開発時に使っていたソースファイルやnode_modulesは本番環境には不要だ。
この構成を選ばない理由
公平を期すために、この構成が合わないケースも書いておく。
小規模な案件や、WordPressに慣れた人が多いチームでは、従来のテーマ構造のほうがスムーズなことも多い。Sage + Blade + Viteの組み合わせは学習コストがかかるし、Docker環境の維持にも手間がかかる。
「とりあえず動くテーマを早く作りたい」という場面では、もっとシンプルな構成のほうが適切かもしれない。
まとめ
結局のところ、この環境を構築した動機は「面倒なことを減らしたい」に尽きる。
環境構築の手間を減らしたいからDocker。テンプレートを読みやすくしたいからBlade。ビルド設定をシンプルにしたいからVite。CSSを書く手間を減らしたいからTailwind。
それぞれの技術には制約やトレードオフもある。万能な構成ではないし、学習コストもかかる。それでも、自分にとっては面倒な作業が減って、開発が楽になった。WordPressでもこういう選択肢が取れるようになったのは、ありがたいことだと思う。