Habakiriで学んだこと・反省点、そして解決したいこと

はい、ということで今年もやります Advent Calendar。昨年は Habakiri Advent Calendar というのをやりまして、1人でやることになるんじゃないかと思っていましたが結果的にたくさんの方にご参加頂きました。ありがとうございます。

Habakiri 推しだった昨年ですが、実際に使っていくともっと良いアプローチがあるんじゃないの…？みたいなところが見えてきまして、Mimizuku というテーマを作りました。今年はこのテーマを軸に Mimizuku Advent Calendar としてテーマの設計に関する話とかをやっていきたいと思います。今のところ僕1人ですごく寂しい感じなので、ぜひご参加ください（数的にちょうど良かったので土日あけてますw）

まず1日目は「Habakiriで学んだこと・反省点、そして解決したいこと」ということで、Miimzuku を開発するに至った経緯を書きたいと思います。

いやいや、そもそも Habakiri ってなによ？という方はまず一度公式サイトをご覧いただければ。

Habakiri で解決したかったこと

Habakiri、Mimizuku には一連の流れがありまして、解決したい共通の問題というのがあります。それが「フルスクラッチめんどくさい問題」です。「WordPress でサイト制作をする」というのはほぼイコール「テーマを作る」ということになると思いますが「WordPress で一般的な構成の Web サイトをつくる」という場合、まず最初にやることとか、つくっていく中でこれはやる、みたいなことってある程度決まっていると思うんですよね。で、フルスクラッチでつくるとなるとそういうことを全部やらないといけないというのがすごくめんどくさい。「既存テーマからコピペするから」という方もいるとは思うのですが、僕としては「多数の既存テーマの中から該当するコードを見つけてきてコピペして今回のテーマにあうように改変する」という行為すらめんどくさい。

じゃあベースとなる親テーマを作って、そういう問題は親テーマで吸収できるようにして、その差分を子テーマで作るようにしてしまえば効率化できるんじゃないの？ということろがスタートになります。つまり、僕は「こういうサイトのときは Habakiri で解決する」ではなくて「WordPress で Web サイトをつくる」という全ての場合で使えるテーマとして Habakiri の開発をスタートしました。

Habakiri で予想通りいったこと・いかなかったこと

Habakiri の大きな特徴として以下のものがあります。

• Bootstrap
• 大量のアクションフック
• カスタマイザー

Bootstrap

まず「Bootstrap」。Web 制作者なら誰もが知る超有名 CSS フレームワークですね。やっぱりもうデファクトスタンダードといっていいくらい使われているものなので、仕事でも Bootstrap ベースというのは重宝されますし、安心感もあります。そういう意味では Bootstrap ベースである、ということ自体は結構良かったのではと思います。

ただ使えば使うほど Bootstrap、結構ヘビーだなぁと思うようになりました。世間では容量が重いとか動作が遅いとか言われていますが、僕はそんなことは全然気にしていなくて、それは事実をもとにした発言じゃなくて感情論なのでは？と思っている派です。じゃあ何がきつかったのかというと、各コンポーネントのスタイルの指定が強すぎるなぁと思うことが多かったのです。

大量のアクションフック

これは思った通り機能してくれました。Habakiri は例えば記事の前後とか、タイトルの前後とか、ヘッダーの前後とか、いろいろなところにアクションフックが用意してあります。なので「ここに何かを足したいんですよ」みたいなときにテンプレートを上書きせずにその何かを追加することができます。もしこういうフックがないテーマを親とした場合、一部分だけ何かを追加したいだけだとしてもまるっとテンプレートを上書きしなければいけなくなります。いわゆる「子テーマ上書き問題」です（僕が勝手に言っているだけ。誰か流行らしてください）。最近「子テーマはいいぞ」みたいな声をよく聞きますが、この問題をみなさんがどう考えているのかというのは常々気になっていまして、機会があればディスカッションしたり考えを聞いてみたいなぁと思っています。

で、わりと機能したアクションフックですが、これにも1つ問題がありました。アクションフックがあることで「追加」は抜群にやりやすくなりました。ただ、「変更」や「削除」ができない。変更・削除をする場合はテンプレートを上書きするしかないのです。

カスタマイザー

いちいち初期設定的なスタイルを書きたくないということで Habakiri ではカスタマイザーで設定できる項目を充実させました。ただ、スピードという観点からいうと GUI で設定するというのはどうしてもコードを書くより遅いです。だからカスタマイザーでいちいちポチポチするのがすごくストレスに感じるようになりました。そこでカスタマイザー部分にフィルターフックを設けてカスタマイザーを触らなくてもコードで設定できるようにしました。これはそこそこ良い発想だったと思うのですが…同時にそれなら最初からカスタマイザーいらなくね？とも思うようになりました。

どのように解決するか

Habakiri の良い点を活かしつつ、上記のような問題をどうすれば解決できるか考え、Mimizuku というテーマをつくっています。それぞれの問題について Mimizuku では次のようなアプローチをとっています。

CSS フレームワーク

Bootstrap をやめて独自に CSS フレームワークをつくりました。ここであんまり長くなると後日の記事ネタが無くなってしまうので詳しくはまた別の記事で書きます。

子テーマからの HTML・テンプレートの上書き

そもそも親テーマの HTML を活かすということを捨てて、子テーマで HTML やテンプレートを差し替えやすくする、という形をとりました。

カスタマイザー

廃止しました。もし Mimizuku がそれなりに流行れば、必要であれば別途アドオンと開発して販売とかもできるなぁと…。

Habakiri で予想外だったこと

もともと僕とか制作者向けにつくっていた Habakiri ですが、ググったりしてみると、結構制作者ではない方が使ってくださっているというのがわかってきました。Bootstrap であること、カスタマイザーでそこそこカスタマイズができることが要因だと思います。

Habakiri は issue もいくつかたまってしまっていますが、制作者向けには Mimizuku を、非制作者な方とか、予算が少ない案件でちゃっとやりたいという場合には Habakiri を、という切り分けができるんじゃないかなぁとか考えています。

ということで、明日は Mimizuku の大きな特徴の1つである「テンプレートをレイアウトファイルとビューファイルに分離するメリット」について書きたいと思います。ではではー。