この記事は Habakiri Advent Calendar 2015 3日目の記事です。前回、前々回の記事で Habakiri が子テーマ利用前提のテーマだということをお話しました。そこで、今日は子テーマ利用前提のテーマとして、どのような考えを持って Habakiri を開発しているのか、また、どのような工夫をしているのかを書きたいと思います。

子テーマでの制作をストレス無く行えるように

Habakiri で一番に考えていることは「子テーマでの制作をストレス無く行える」ことを実現することです。基本的にはこれしか考えていません。だから Habakiri の初期デザインはすごくダサイですよね…。だけど、この初期デザインがダサイというのもポイントで、なぜダサいのかと言うと、ほとんど装飾をしないようにしているからです。

Habakiri は仕事でベースに使えるように開発をしています。仕事で作るテーマはそれこそデザインは様々だと思います。つまり、Habakiri で装飾を加えてしまうと子テーマでそれが邪魔になることがかなり多くなってしまうのです。だから Habakiri ではあえてほとんど装飾を加えず大まかなレイアウトだけを行うことで、子テーマで様々なデザインをストレス無く実現できるようにしています。

Bootstrap

Habakiri はベースとして Bootstrap を採用しています。CSS フレームワークを利用していないテーマもたくさんあると思いますが、Habakiri の場合は何らかの CSS フレームワークを利用することは必須でした。それは次の理由からです。

• 子テーマ利用が前提なので、親テーマだけで完結する CSS だと意味が無い。
• オレオレ CSS オンリーだとユーザーが子テーマでテンプレートを作ったり、ページを作成したりしていくときにオレオレ CSS の内容を把握しなければならない。また、そのためにドキュメントを用意する必要がでてくる。
• オレオレ CSS より、広く一般に使われている CSS フレームワークをベースにするほうが、ユーザーがすぐに使用することができる。
• 独自に汎用的な CSS フレームワークを作ろうとすると恐らくどこかで破綻する。もしくは最適化されていない CSS になりがち。

以上のことから、Bootstrap か Foundation をベースにするのが良さそうだなと判断しました。Habakiri を作り始めるまでは実はこれらの CSS フレームワークを使用したことはなかったのですが、ドキュメントを見る限りだと Bootstrap の方が簡単そうだったこと、情報も Bootstrap の方が多そうだったことから Bootstrap をベースとすることにしました。

ポピュラーなライブラリを含める

Web 制作の仕事を行っていると、ほぼ確実に使用するライブラリが1つか2つはあるかと思います。それを毎回毎回自分で組み込むのは無駄です。だから Habakiri ではそのようなライブラリをテーマに含めてしまうことにしました。では、ほぼ確実に使用するのは何だろうと考えると、スライドショーとアイコンフォントだなと（確実に異論はあると思いますが…）。

スライドショー

Bootstrap にはスライドショーのコンポーネントも入っているので初めは不要かなと思っていたのですが、バリエーションが少ないこと、装飾が当たりすぎていること、という点が仕事で使うとなると結局毎回別のライブラリを追加しないといけないことになりそうだなと思い、人気のライブラリを探して入れることにしました。

Habakiri を作るまではスライドショーは自作の物を使用していました。そこで GitHub でスターの数を調べたり、Twitter で訪ねてみたりして、slick を採用することにしました。JS に詳しい方からすると slick は作り的にどうなん、というのがあるらしいのですが、それ1つで様々なパターンのスライドが作れることを考えると、他にあまり選択肢はありませんでした。

アイコンフォント

Bootstrap には Glyphicons というアイコンフォントが同梱されています。ただ、これは種類が少なく、これだけだとあまり実用的ではありません。そこで Genericons を追加しました。ただ、結局これでもあまり実用的ではなく、最終的に Font Awesome も追加しました。Genericons のアイコンはだいたい Font Awesome でカバーできるため、今思えば Font Awesome だけで良かったなーと思っています…。

CSS をストレス無く書けるようにする

Bootstrap を採用したこともこれに当てはまりますが、もっと意識していることがありまして、それは「CSS の詳細度を低くすること」です。

Habakiri の CSS を見て頂けるとわかるかと思いますが、ID セレクタや !importat がほとんどありません。また、入れ子が深いセレクタもあまりありません。ID セレクタや !importat、入れ子が深いセレクタは詳細度が高くなります。

詳細度が高いと子テーマで CSS を上書きしたい場合に、ID から辿った深いセレクタを何度も書かないといけなくなったりして「ここを上書きしたい」だけなのに、その要素の親要素のことまで調べたりしないといけなくなり、時間の無駄です。だから Habakiri では直感的にスタイルの上書きができるように CSS の詳細度がなるべく低くなるような設計にしています。

詳細度を低くするには class の命名を考える必要があります。CSS 設計の構成案も様々なものがありますが、BEM の命名規則がそういった点や Sass との相性が良かったので BEM を採用することにしました。

なるべくコードを書かなくてすむ工夫

デザイナーさんにとっては、やはり「コードを書く」ということが一番のストレスなのではないかと考えました。そこで Habakiri ではコードを書かなくてもざっくりデザインの基礎的な部分やレイアウトが組めるようにカスタマイザーに力を入れました。Habakiri では主に下記のようなことをカスタマイザーでポチするだけで設定可能です。

• 色の設定（特にヘッダー・メニュー部分はカスタマイザーだけでほぼ完結できると思います）
• ヘッダーのレイアウト選択
• ブログ、404ページ、検索結果ページのレイアウト選択
• トップページスライドショーの設定（表示する画像、上にのせる 文字、エフェクト、表示時間、エフェクトに書ける時間、オーバーレイの色・透明度）
• その他、ロゴ設定、パンくず表示、関連記事表示、ページヘッダー表示など

また、固定ページのレイアウトも簡単に設定できるように、ページテンプレートも豊富に用意しています。左サイドバー、右サイドバー、トップページ用、ブランクページ、1カラム（サイドバー無し、ページ幅（最大固定）、ページ幅（リキッド））から選択することができます。

テンプレートをなるべく上書きしないですむ設計

親テーマに拡張性がないと、子テーマでデザインをカスタマイズしたい場合にどうしてもテンプレートを丸ごと上書きしないといけなくなります。僕はこの点は問題だと考えていて（詳しくは後日記事にします）、Habakiri ではテンプレートを丸ごと上書きしないですむように次のような工夫をしています。

大量のアクションフック

Habakiri には様々な箇所に大量のアクションフックがあります。大量にアクションフックを用意することで「ここに要素を追加したい」というときに、わざわざテンプレートを丸ごと上書きしなくても、functions.php 等からそこだけピンポイントに要素を追加することが可能になっています。

テンプレートを細かく分割して切り出す

アクションフックが大量にあれば要素を追加することはできますが、要素を書き換えたり削除することはできません。そこで、Habakiri では様々なパーツをmodules/というディレクトリにテンプレートパーツとして切り出しています。例えば、パンくず、copyright、ロゴ、ページャー等です。パーツを細かく切り出せば、ページのテンプレートを丸ごと上書きしなくても必要なモジュールだけ上書きすれば良くなるので、上書きが与える影響を最小限に抑えることができます。

functions.php をクラス化

これは難しいので良くないと言われることがしばしばあるのですが、僕的にはこれはかなりナイスなアイデアだと思っています。というのも、functions.php は親テーマのものが先にロードされるため、関数ベースだとその関数を素直に上書きすることができません（同名の関数は定義できないため）。子テーマから上書きできるようにするために、親テーマの各関数を if ( function_exists( ... ) ) {} で全て囲むという涙ぐまし努力を行っているテーマもありますが、正直それはかなり無駄な作業に思いますし、全くスマートでありません。

PHP にはクラスがあり、クラスには継承による上書きという機能があります。functions.php をクラス化すれば、継承によって素直に機能を上書きすることができます。関数ベースだとどうしても各関数が大きくなりがちですが、クラス化しておけば各処理をさらに細かく分割することで、上書きの影響を最小限に抑えるようなこともできるようになります。そのため、難しいと思われるのは承知の上で、Habakiri のfunctions.php はクラス化することにしました。

もしクラスを継承して使うことが難しいという場合は、フックの使用などはクラスを使わずに普通に関数ベースでも行えるので、特にクラスを使わなくても大丈夫ではあります。

とはいうものの…

テーマは HTML や CSS が主であり、これは子テーマ等で容易に上書きできたり書き換えたりすることができるので、それらのアップデートがユーザーに与える影響がとてもとても大きく、プラグインのようにお気軽にアップデートすることができません。そのため今となって「こうしておけば良かった」とか「ここはこうしたいけど今から変更するには影響が大きすぎる」みたいなところがいろいろとあります。この辺りも後日また記事にしたいと思います。