テーマのカスタマイズに、もう子テーマは使いたくない！（前編）

『WordPressのテーマカスタマイズをする場合は、子テーマで行いましょう』

テーマの制作やカスタマイズについての書籍やインターネットの情報を見ると、ほとんどこう書いてあると思います。
私も実際に仕事でWordPressのサイト構築を行う場合は、子テーマを使ってカスタマイズをすることが多いです。

でも、およそ10年にわたって数多くのWordPressサイトを構築し、それらのサイトを長期間にわたってサポートしてきたなかで
『子テーマによるサイト構築って、実はあまり良い方法ではないのでは？』
と考えるようになってきました。

本記事では、私がWordPressでサイト構築を行うようになってからのテーマ制作手法の変化と、今考えているテーマカスタマイズのベタープラクティス（決してベストではないです）について書きたいと思います。

WordPressテーマ制作手法の変化

静的HTMLをテンプレートタグに置き換える手法

私がWordPressで初めてサイト制作を行ったのは、2010年です。
当時は、まず静的HTMLでページを作り、タイトル・メニュー・コンテンツなどをWordPressテンプレートタグに置き換えてテンプレートファイルを作成するという手法が一般的でした。
おそらく、そのころシェアが高かったMovableTypeの制作手法をWordPressに当てはめたものではないかと思いますが、私にとってはわかりやすい手法でした。

既存テーマを流用する手法

しかし、出力されるページをすべて管理画面で事前に設定するMovableTypeとは異なり、WordPressは制作者が意図しないページが出力されてしまいます。
例えば、月日アーカイブページ、著者アーカイブページ、検索結果ページなどは、MovableTypeでは制作者が設定しなければ出力されませんが、WordPressでは出力されてしまいます。
そのため、事前にどのようなページが出力されるのかを把握しておき、テンプレートファイルを用意しておく必要があります。

そこで用いられるようになったのが、WordPress同梱のデフォルトテーマや公式テーマ、またはUNDERSCORES・bonesなどのブランクテーマ（スターターテーマ）をベースにカスタマイズしていく手法です。
必要なテンプレートがすでに用意されていて、作りこまなくてもいいテンプレートはデフォルトでもそれなりに使えるようになっているので制作効率が良い手法でした。

子テーマでカスタマイズする手法

デフォルトテーマや公式テーマをそのままカスタマイズして制作してしまう方法は制作効率が良い反面、大きな問題があります。
ベースにしているテーマがアップデートされたとき、管理画面からアップデートを行うとカスタマイズした部分が消えてしまうのです。
そのため、「公開後はテーマのアップデートを行わない」というサイトが多く作られることになりました。
しかしテーマのアップデートは、WordPress本体のアップデートによる不具合修正や新機能への対応が含まれていますので、本来はまずい対応策です。

そこで推奨されたのが、子テーマを使った制作手法です。
新規作成したテーマのstyle.cssに「Template: twentyten」のように親とするテーマディレクトリを記載することで、カスタマイズしたいテンプレートファイルだけを子テーマで作成し、それ以外は親テーマを参照するようになります。
この手法であれば、制作効率も良く親テーマをアップデートしてもカスタマイズ部分が消えることはありません。

子テーマによるサイト構築手法は標準的な手法として広まり、現在も推奨されています。

親テーマのアップデートに影響されないのは”良いこと”なのか？

制作者によってスタンスは違うと思いますが、基本的に私は「ウェブサイトは公開してからがスタート」という考えを持っています。
公開後、運用を続けていく中で常に改善していけるのがウェブサイトの良いところだと考えているからです。

WordPressで構築されたサイトを運用していく中で避けられないのが「WordPress本体のアップデート」です。
WordPressは他のCMSと比較して、非常にアップデートの頻度が高いシステムだと思います。
脆弱性の修正がテーマ制作に影響することは少ないのですが、ウェブの変化に対応して機能面がアップデートされた場合はテーマ制作に大きく影響する仕様変更が行われることがあります。

例えば下記のような仕様変更です。

• wp_title() が非推奨になった
  （システム側で最適なtitleタグを生成する）
• query_posts() が非推奨になった
  （メインクエリを書き換えるのではなく、pre_get_postsフックを使う）
• CSSやJavaScriptはheader.phpやfooter.phpに書かず、functions.phpでenqueueするようになった
  （依存関係やバージョン管理のため）

親テーマがデフォルトテーマやしっかりした公式テーマだと、本体のこうした仕様変更にしっかり追従してテーマファイルの内容が変更されます。

また、親テーマのテンプレート構成が変更されることもあります。
大きなテンプレートファイルが細かくテンプレートパーツに分けられたり、HTMLタグが変更されたり（divがheaderになるとか）、idやclassが変更されたりといったことです。
functions.phpで作成していた独自関数の変更が行われることもあります。

でも、子テーマはテンプレートファイルを別ディレクトリにコピーしてしまっていますから、親テーマのこうした変更が反映されません。
するとこんな不具合が生じてしまいます（すべて私の実際の経験です）

• titleタグが2つ書き出される
• バージョン違いのjQueryが複数読み込まれてJavaScriptがエラーになる
• 子テーマでカスタマイズしていない部分のHTMLタグが変更されてCSSが反映されない
• 子テーマでカスタマイズしていない部分のHTML構造が変更されてレイアウトが崩れる
• 真っ白になってページが表示されない！

WordPressは後方互換性が十分に考慮されていますので、こうした不具合は公開してからしばらくは出て来ません。

しかし、公開後3年～5年くらい経つと出てくるのです！

WordPressの本体アップデートに伴って問題が発生するので、上記の問題も同時多発的に発生し、そのたびに休日返上徹夜での改修作業が発生します。
子テーマのお守りも辛いなぁと悶々としていた時、画期的なカスタマイズ方法を推奨しているテーマを見つけました。

子テーマではなくプラグインでカスタマイズをするという発想

私が見つけたのは、今ではWordPress開発者なら知らない人はいない超有名テーマ「Snow Monkey」のブログ記事です。

Snow Monkey のカスタマイズは子テーマよりプラグインがオススメ！プラグインの雛形をダウンロードできるようにしました

上記の記事で特に私が共感したのはこの部分です。

あと、子テーマをつくるとテンプレートの上書きを気軽にやってしまう問題もあります。v4.4 から v5 にアップデートしてサイトが真っ白になった、などのトラブルがあった方はほぼほぼこのテンプレートの上書きが原因だったはずです。テンプレートの上書きは意図せず古いコードを残したままにしてしまうので、無くなった関数などがかかれているとサイト真っ白状態になっちゃうんですよね。

とはいえ、どうしてもテンプレートの上書きをしたい場合は普通のテーマだと子テーマをつくるしかないのですが、Snow Monkey はv5でテンプレート読み込み周りに全部フックを仕込んだので、v5 からはプラグイン領域から全てのカスタマイズが可能になりました。

Snow Monkey のカスタマイズは子テーマよりプラグインがオススメ！プラグインの雛形をダウンロードできるようにしました – WordPress テーマ Snow Monkey
https://snow-monkey.2inc.org/2019/02/04/my-snow-monkey-plugin/

「子テーマでテンプレートを上書きしない」というカスタマイズができるテーマというのは衝撃でした。
そこで早速新規案件で Snow Monkey を採用し、子テーマではなくプラグインでのカスタマイズを行ってみました。

Snow Monkey は作者のキタジマタカシさんの対応が素晴らしく、ユーザーの要望をどんどん取り込んで成長しているテーマです。
そのためアップデート頻度も非常に高いです。
でもプラグインによるカスタマイズであれば、親テーマのアップデートからの影響はほとんど受けません。
これはキタジマさんが絶妙にフックを設定しているからなのですが、これまで子テーマのお守りにうんざりしていた私にとっては感動モノでした。

Snow Monkey 以外ではどうすればいい？

でも、Snow Monkey 以外ではこの手法は使えません。
（実は Lightning は出来るらしいし、他のテーマでも出来るものはあるようですが）

じゃあ今後は全部 Snow Monkey で構築すればいいじゃないかという人もいますが、やっぱりテーマって向き不向きがあるので、そういうわけにもいきません。
お客様の都合でサブスクリプションのテーマを使えないケースもあります。

あと、正直に言うと、フックでのカスタマイズはテンプレートの書き換えよりもすごく頭を使います。
テンプレートにパーツがインクルードされているのとは逆の発想になるので、デザイナー脳だとすごく難しいんです。
しばしば『フックでのカスタマイズはfunctions.phpに修正が集約されてわかりやすい』と書いてある記事を見かけますが、『私とは頭の構造が違うのだろうな』と思わずにはいられません。

またまた悶々とした日々を過ごしていた時、私はハッと思いつきました。

わざわざ子テーマ作らなくても、親テーマを直接修正しちゃえばいいじゃないか。
コードの管理はGitでやったらええやん。

長くなりそうなので、後編に続きます。