この記事は Habakiri Advent Calendar 2015 24日目の記事です。ここまで自分で Habakiri のメリットをずっと書いてきて、参加頂いた皆さんにも良いところや活用事例をあげて頂いたので、良くない部分もまとめておこうと思います。これからテーマを作る誰かの参考になれば幸いです。

意外にあった「やりすぎ問題」

Habakiri は、なるべく薄く、汎用的に使えるテーマとして開発しましたが、実際に業務で使ってみるとまだまだやりすぎで打ち消しが必要になったりすることがありました。

カスタマイザーがやりすぎ

コードを書かなくてもざっくりカスタマイザーで設定できれば楽だなと思い、カスタマイザーで多くのカスタマイズができるようにしましたが、色の設定やグローバルナビゲーションの設定など、設定項目を多く作りすぎてカスタマイザーで何が設定できるのか俯瞰できず、逆に面倒になってしまいました。

あくまでベーステーマというコンセプトを通すのであれば、色の設定は最小限にして、ざっくりレイアウトはできます、くらいにしておいたほうが良かったかなと反省。

ヘッダーレイアウトがやりすぎ

ヘッダーのレイアウトは一般的な Web サイトであればわりと共通化されているので、メジャーなレイアウトであればカスタマイザーから簡単に切り替えできるようにしたくて用意したのですが、なるべく HTML は共通化して CSS で何とかしようとしたせいで、class 付けがごちゃついたり、無駄に CSS を強くかけないといけなくなったりして、パターンから外れるレイアウトがやりにくくなってしまいました。選択によって読み込む HTML 自体を切り替えるようにしたほうが良かったかなと反省。

グローバルナビゲーションがやりすぎ

Habakiri のグローバルナビゲーションは、画面サイズによって、一般的の横一列のレイアウト <> オフキャンバスナビゲーション、と動的に切り替わるようになっています。

WordPress の場合はログインすると上部に管理バーが表示されるのでそれがあるときと無いとき、また、カスタマイザーでヘッダー固定を選択している場合とそうでない場合、の組み合わせの4パターンを1つのソースで問題なく動作させるというのがかなり大変で、これ絡みでのバグフィックスや CSS の詳細度問題で非常に手間取りました。

オフキャンバスナビゲーションの動きは好きなのですが、初期のものはもっと単純なものにして、アドオンを追加すれば今のようなオフキャンバスナビゲーションになるとかいう感じにしたほうが汎用的かつ上書きもし易い形にできたかなと反省。

メリットも多いんだけど、Boostrap ヘビーすぎ

もともと Bootstrap を使いたくて開発したという一面もありますし、Bootstrap ベースであることで皆さんに気軽に使ってもらえるというメリットもあるのですが、Bootstrap は結構何でも屋なのでそんなに使わない機能もたっぷり入っていて、無駄にサイズが大きくなってしまいます。フル活用してサイト制作するなら無駄ではないんですけど。

Bootstrap は必要な機能だけ選択してコンパイルできるようになっているのですが、組み込んだテーマだとそういうわけにもいかないので、じゃあどうすれば良かったというのはわかりませんが、いっそ normalize とグリッドシステムだけとか、ぎりぎりまで薄い CSS フレームワークでも良かったかなと。

prefix 問題

CSS の class 名

Bootstrap の class 名には prefix がついていません。また、Habakiri で定義されている  class 名にも prefix はつけていません。最初は特に問題ないだろうと思っていましたが、結構使われやすい汎用的な名前が定義されているので、子テーマでお気軽に命名したら既に定義されていて別の名前を考えなければいけなくなったり、無駄に CSS を上書きしないといけなくなったりすることがありストレスでした。Bootstrap は馴染みのある方なら定義されている class 名は頭にあるかもしれませんが、Habakiri の class 名なんか把握しているはずはないので、せめて Habakiri の class 名には prefix を付けるべきだったなと反省。

テンプレートパーツ

Habakiri は細かくモジュール（テンプレートパーツ）の切り出しを行っており、それらは modules/ というディレクトリに格納されています。Habakiri はアクションフックが大量にあるという特性上、テンプレートを上書きするよりアクションフックにフックしてテンプレートパーツを読みこませるという使い方が多くなりやすいのですが、そのときにお気軽に子テーマに modules/ というディレクトリを作ってパーツを保存すると、既存のパーツと名前がダブっていて上書きされちゃう、ということが起きやすいかなと思いました。これも CSS の prefix 問題と全く同じ構造なので、全てのパーツに prefix を付けたほうが良かったなと反省。

クラスメソッド

Habakiri の functions.php はクラス化されていて、だから関数ベースの場合と違ってクラス名にされ prefix つけておけばメソッド名には付けなくても良いから楽なんですよ、と言いふらしていたのですが、実際使ってみるとメソッド名、特にフックさせたコールバック関数については prefix を付けておいたほうが良かったなと思いました。

というのも、Habakiri の場合はフック名とコールバック関数名を同じにしている場合が多く、例えばwp_enquque_scriptsフックにwp_enquque_scripts()というメソッドをフックさせたりしているのですが、これって子テーマでお気軽に上書きしちゃって Habakiri の同名の処理が消えちゃうっていうのが結構ありそうなんですよね。なので、せめてフックのコールバック関数については prefix を付けておけば良かったなと反省。

あまり考えずにやってしまった問題

ここまで上げたのも「あまり考えずにやってしまった」と言えばそうなんですけど。

ディレクトリ構成が適当

特にどういった構成が一般的かとか調査せずに決めてしまったので、今となっては結構違和感がある構成だな…と。せっかく Sass を使っているので FLOCSS とかを参考にディレクトリ構成すればより多くの人にすんなりきたでしょうし、content-*.php がルートに散らばっているのも邪魔くさいので、これも /content みたいなディレクトリを作ってまとめれば良かったなと反省。

Habakiri の場合、A というテンプレートが B というテンプレートを読み込み、B が更に C というテンプレートを読み込んでいる、という構成が結構あるのですが、この A も B も C も同じ階層にあったりして、何かそれが微妙に違和感があるので、良い案はまだ無いのですが、読み込まれるテンプレートの階層にあわせてディレクトリも良い感じに階層化できれば、わざわざコードを追わなくても階層が把握しやすくテンプレートを上書きする場合も探しやすいと思うので、同じような構成でこんな風にしているよーとかあればぜひ教えてほしいです。

マークアップが適当

運用してみると、例えば.entriesや.articleを modifire でわけるのとかすごく微妙でした。（結局あまり効果的に指定できない）。

また、Microformts にちゃんと対応させようと頑張ったのですが、Microformats の「CSS の class 名で構造化する」というのはデザインやマークアップに影響されやすかったりして良くないなと思いました。WordPress はデフォルトで Microformats 用の.hentryを出力しますが、正直これはかなりお節介なので、フィルターフックでいっそ出力されないようにして、JSON-LD とかで構造化したほうが良いと思います。

ちなみにテーマ側で JSON-LD 対応するというのはプラグインテリトリーを犯してしまうことになるんですかね…？「構造化データ」という点でみれば Microformats や Microdata に対応させるのと同じなので良いんじゃないかなと思うのですが、HTML と切り離されているということを考えるとプラグインでやるべきことのような…。うーん。

こうすればもっと汎用化できたと思うこと

テンプレートパーツの呼び出し

今テンプレートパーツの呼び出しは header.php などのベーシックなテンプレートからget_template_part()で呼び出しているので、もしそのパーツが不要となった場合は子テーマでそのパーツと同名のパーツを作り、中身を空で保存する、ということになります。ただ、何か直感的では無くダサいですし、そこでは不要だけど別の場所に出したいということができません。それをやるなら header.php のような大元のテンプレート自体を上書きすることになってしまい良くありません。

なので、こういったテンプレートパーツの呼び出しもアクションフックで呼び出す形にしておけ良かったなと反省。それなら全く大元のテンプレートを上書きする必要が無く、functions.php からremove_action()するだけで良くなるので。

ということで

と色々良くないなと思うところがあるのですが、前にも書きましたがテーマのアップデートって既存ユーザーさんへの影響が大きすぎるので後で気付いてももはや変更できないということが多いです。だからリリース前に入念に、本当にこれで良いのか、絶対に問題ないか、よーく慎重に検討してからリリースしたほうが良いと思います。

余談ですが

次にテーマを開発するときは挙げた問題点をきちんと検討してから開発を行おうと心に決めているのですが、CSS の問題が今一番気になっているので、脱 Bootstrap するためにオリジナルの CSS フレームワークを細々と開発中だったりします。

全ての class 名に prefix が付いていて、グリッドシステム + α くらいの薄い構成にしています。ついでに先を見据えて float ベースではなく flexbox ベースにしました。IE10 以上なのでまだ実務では難しいかもしれませんが、次のテーマができあがる頃には flexbox が主流になっているだろう、ということで。

CSS フレームワークを開発するというのはすごく Sass の勉強になるので一度やられてみるとおもしろいと思います。容量をなるべく軽くするためにどうすれば良いかとかすごく考えないといけませんし、そのお陰で extend の使い方を勉強できました。Foundation 6 とか僕のフレームワークよりたくさん機能あるのにめちゃ軽いのでなんでや！と思って調べたり（僕のはグリッドシステムを柔軟にしすぎたのでその分サイズが少し大きい）。多分もっと削れると思うので、CSS マスターの方々にはぜひプルリク頂きたく…。