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

前編は主に私がなぜこんな考え方をするようになってきたかを書きましたが、後編では実際に子テーマを使わずにベースとなるテーマをカスタマイズする方法について考察していきます。

子テーマを使わないカスタマイズ方法（一般的なもの）

CSSの修正だけなら、追加CSSを利用する

WordPressには、外観 > カスタマイズ に「追加CSS」の項目があります。
十数行程度のCSSを追加したいのであれば、ここにCSSを書くだけでOKです。

ただ、追加CSSはふとしたミスで消してしまったりすると元に戻せませんので、バックアップが重要です。

各ページのみに適用されるCSSを追加したい場合は「Simple CSS」プラグインが使えます。
このプラグインを使えば、テンプレートを修正して各ページにクラスを割り当てるコードを挿入したりする必要はありません。

Simple CSS

functions.php に追記するだけならマイプラグインを作る

プラグインの開発なんて難しいと思っている方もいらっしゃるかもしれませんが、実は functions.php に関数を追記できるスキルがあるならプラグインが作れます。
functions.php は修正に失敗すると画面が真っ白になってしまったりして焦りますが、マイプラグインにしておけば、とりあえず無効にすれば直ります。

WordPress (自分専用)マイ・プラグインを作ろう

functions.php を修正する代わりにプラグインを使う

マイプラグインより便利なのが「Code Snippets」プラグインを使う方法です。
管理画面から関数ごとに登録し、有効／無効を切り替えることができますので、カスタマイズをちょっと試してみたいときに便利です。
また、関数ごとにタイトルを付けられるので管理も楽になります。
インポート／エクスポートができるので、他のサイトに持っていくこともできます。

そして、なんとこのプラグインは、文法上のエラーがあると警告してくれます。
文末に ; が無いとか、{ } のネストが合ってないとか、うっかりやりがちだけど、functions.php でやってしまうと画面が真っ白になりかねないミスを未然に防ぐことができます。

Code Snippets

マイプラグイン（または Code Snippets）でフックを使う

WordPressのコアファイルや多くのプラグインには「フック」という仕組みがあり、外部から処理を変更できるようになっています。
「Snow Monkey」、「Lightning」、「Nishiki」など一部のテーマのテンプレートにもフックが仕込まれており、これを使ってテンプレートの処理を変更することができます。

WordPress初心者開発者向け フィルターフックとアクションフック入門

https://qiita.com/kurudrive/items/11c164c05bf0dba66920

フックを使ったWordPressテーマのカスタマイズの仕方

WP ZoomUP #52 – フック
https://www.notion.so/WP-ZoomUP-52-a64926cd665342f4aa0e6ec1e181e254

ただ、フックを探すためにテーマテンプレートのソースコードを調べる必要があったり、アクションフック・フィルターフックについての基礎知識が必要だったりと、少々ハードルが高いです。

また当然ですが、フックが仕込まれていないテーマではテンプレートの処理を変えることは出来ません。

子テーマもフックも使わないテーマテンプレートのカスタマイズ

というわけで前置きが長くなりましたが、ここからが本記事のメインです。

私は子テーマを使ってカスタマイズをするときに Git でバージョン管理をしているのですが、ある時、ふっと

と思ったんです。

私が考えた手順は下記のようなものです。

カスタマイズの手順

1. 親テーマをインストールした状態で、初回コミット
2. 続けてブランチ「parent」を作成
3. ブランチを「master」に切り替えてテンプレートを修正
   （開発用ブランチを作ってもOK）
   ※parentブランチはカスタマイズ時にはさわらない！
4. 修正したら「master」ブランチにコミット
   （または、開発用ブランチをmasterにマージ）

親テーマがアップデートされたときの手順

1. まず、ブランチを「parent」に切り替え
   ※これ重要です！
2. テーマを更新
   （外観 > テーマ の画面で更新してOK）
3. 「parent」ブランチに更新をコミット
4. 「master」ブランチに切り替えて、更新されたparentブランチをmasterにマージ
   ここでコンフリクトが起きたら、parentブランチの差分と見比べて修正

この手法のメリット

私が思うこの手法のメリットは次のとおりです。

• 親テーマの修正点が差分で確認できる
• 自分がカスタマイズした点も差分で確認できる
• カスタマイズによる変化が最小限なので、親テーマの修正が反映される
• 何かあったらOKだった時点まで戻せる

いかがでしょうか？
これならフックが仕込まれていないテーマのテンプレートでもピンポイントで修正ができ、親テーマのアップデートにもしっかり追従できるカスタマイズができるのではないでしょうか？

今や Dreamweaver でさえ標準で Git が使える時代ですし、導入は難しくないですよね？

個人的には「親テーマの修正点が差分で確認できる」というのがポイント高いと思います。
WordPressのトレンドを知れたり、テーマ制作のより良い手法を学ぶことができます。

注意！　本番環境でやっちゃダメ

注意点としては、親テーマのアップデート作業を適用する際にいったんカスタマイズをしていない状態にしますので表示が崩れます。
またコンフリクトした時は、修正が完了するまでウェブサイトの表示が崩れます。
そのため、テスト環境でmasterへのマージまで行ってから、更新したテーマを本番環境に適用するようにしてください。

1. テスト環境で更新したテーマディレクトリをzip圧縮してダウンロード
2. 本番環境でzipファイルをアップロードして更新

当然ですが、本番環境では、外観 > テーマ の画面で更新ボタンを使った更新をしてはいけません。
（まぁ、やったとしても Git でもどせばいいんですが）

まとめ

子テーマによるカスタマイズを推奨しないテーマも多くなってきています。
今後、フルサイトエディテングに進んでいくと、管理画面上でパーツを作成していくような流れになってテーマカスタマイズの意味も変わってくるのではないかと思いますし、そうなってくると本記事の話もあまり意味がなくなってきますね。

WordPressによるサイト制作って、今後どうなっていくんでしょうか？
まだまだ勉強しないといけないのかなぁ？
好きでやってる仕事なので飽きなくていいかなと思いつつ、Wordpress自体のアップデートのペースを、もうちょっと落としてほしいなぁとも思っています。