Mimizukuの基本設計

Mimizuku Advent Calendar 5日目の記事です。土曜日に SaCSS に登壇させていただきまして Mimizuku Advent Calendar の紹介もしてきましたがどうでしょうか。いまだ参加者は僕だけです。

ということで今回は Mimizuku の基本設計について書きます。

メインテンプレート

といっても何について書けば良いのかあまりピンときていないので（自分でテーマ決めたのに…）、特徴的な部分について書こうと思います。

Mimizuku はsingle.phpやpage.phpなどのメインとなるテンプレートには HTML を書かずコントローラーとして使い、HTML は別途用意したレイアウトファイル、ビューファイルに記述するようにしています。これについては2日めの記事「WordPress のテンプレートをレイアウトファイルとビューファイルに分離するメリット」に詳しく書いたので省略します。

header.php、footer.php、sidebar.php

header.php、footer.php、sidebar.phpについては、WordPress コアで差し替えやすくする仕組みが提供されています。例えばheader.phpであれば、通常get_header();と呼び出すところをget_header('front');みたいにすればheader-front.phpがロードされる、という感じです。機能的には全然良いのですが、こうすることでテーマのルートに複数のheader-xxx.phpが展開されてしまうのがなんだかなーと思っていました。ちゃんとディレクトリわけしたいなーと。ということで Mimizuku では独自にフィルターフックを作り、そのフックを利用して/layout/header内のテンプレートファイルを呼び出すという形にしました。同様に、footer.phpやsidebar.php、また、レイアウトファイルも/layoutの中に配置するようにしています。

テンプレートパーツ

ヘッダー、フッターなどの大枠はレイアウトファイルとして切り出されていますが、その中に配置される例えばパンくずとかヘッダーロゴとかグローバルナビゲーションなどのコンポーネントは1つ1つテンプレートパーツとして切り出しています。こうすることには2つのメリットがあります。

修正しやすい

テンプレートパーツにわけずに作っている場合、例えばグローバルナビゲーションを修正したいとなったら長ーい長いheader.phpの中からグローバルナビゲーションにあたる部分を見つけ出して修正をしなければいけません。単純にめんどくさいです。そういう場合、たいていインデントは深くなってしまうので可読性も落ちてしまいます。コンポーネントごとに切り出していれば1ファイルあたりのコード量は少なくなりますし、インデントもその中で揃えれば良いのでそのコンポーネントに集中して作業することができます。

子テーマで上書きしやすい

Mimizuku は子テーマを効率良く作成するためのフレームワーク的テーマですので、いかに子テーマで修正を入れやすいかというのが大切です。いくらレイアウトファイルを差し替えやすい仕組みを作っていても、全てをレイアウトファイルやheader.php・footer.phpに書いてしまっていては必要ない部分まで全て上書きされてしまい、逆に非効率です。コンポーネントごとに切り出していれば子テーマで変更したいテンプレートパーツだけ上書きができるようになるので上書きによる影響を最小限に留めることができます。

Sass で CSS を書くときもコンポーネントごとにファイルを分けるのが主流なので、同じ粒度でテンプレートも分ける、と考えるとわかりやすいかもですね。

CSS設計

Mimizuku は CSS 設計として FLOCSS を採用しています。詳しい説明は省きますが、FLOCSS では CSS をレイヤー分けします。

├ Foundation
├ Layout
└ Object
  ├ Component
  ├ Project
  └ Utility

Component はボタンなどの再利用可能な一般的なパターン、Project はプロジェクト固有のパターンの CSS がそれぞれ記述されます。Mimizuku は CSS フレームワークとして Basis を使用していますが、全ての再利用可能なコンポーネント単位は CSS フレームワークで提供されるべき、という考えで Component レイヤーは Basis で提供、そこでまかないきれないもの（一般化・抽象化できないもの）は Mimizuku 独自の CSS で提供、という分け方をしています。

また、命名規則にも特徴があります。Basis、Mimizuku ともにセレクタに接頭辞として_を付与しています。こうすることで子テーマで独自のセレクタを定義した場合に命名の衝突が起こらないようにしています。ちなみに、Habakiri では接頭辞のない Bootstrap がベースで Habakiri 独自の CSS にも接頭辞が無く、子テーマで何気なくつけたセレクタ名が既に存在していて邪魔になる、ということが何度かあったためこのような命名規則にした経緯があります。

functions.php

functions.phpがだらだら長くなるのも可読性が落ちるなと思いまして、設定系とか独自テンプレートタグとかは/app以下に保存し、それらのファイルをfunctions.phpからロードするようにしました。これはよく見ますが、ちょっとこだわったのは1つのメソッド（関数）ではなるべく1つのことしかやらないようにする、ということです。

例えば、CSS や JS を読み込ませるとき、次の感じが一般的ではないでしょうか？

public function __construct() {
    wp_enqueue_scripts( [$this, 'wp_enqueue_scripts'] );
}

public function wp_enqueue_scripts() {
    wp_enqueue_script('a', '/path/to/a.js' );
    wp_enqueue_script('b', '/path/to/b.js' );
    wp_enqueue_script('c', '/path/to/c.js' );
}

そこを Mimizuku では次のようにしました（実際のコードとは異なります）。

public function __construct() {
    wp_enqueue_scripts( [$this, 'wp_enqueue_scripts_a'] );
    wp_enqueue_scripts( [$this, 'wp_enqueue_scripts_b'] );
    wp_enqueue_scripts( [$this, 'wp_enqueue_scripts_c'] );
}

public function wp_enqueue_scripts_a() {
    wp_enqueue_script('a', '/path/to/a.js' );
}

public function wp_enqueue_scripts_b() {
    wp_enqueue_script('a', '/path/to/b.js' );
}

public function wp_enqueue_scripts_c() {
    wp_enqueue_script('a', '/path/to/c.js' );
}

「わ、めんどくさ！」と思われたかもしれません。まぁ実際めんどくさいんですが…。なぜこうしたかといいますと、このほうが子テーマから上書きする際に影響範囲を制限できるんじゃないか？と考えたからです。テンプレートパーツと同じ考え方です。

Mimizuku では上記のような設定系のコードは全部 class にしているので、子テーマでその class（設定）を直接使わずに一部変えたい、となったときはその class を継承した class を作ってメソッドやらプロパティを上書きするのが良いのだろうなと考えました。そうしたとき、1つのメソッド内で全部やってしまっていると一部だけ上書きしたいのに全部の処理を上書きしないとけない、みたいなことになってしまいます。非効率だしアップデートのときの影響も大きいので危険ですね。

とはいうものの、子テーマから class を継承する仕組みをまだちゃんと用意しているわけで、現状どれほどの効果につながっているのかは良くわかりません^^;

ということで、明日は Mimizuku の static ビュー機能について書きたいと思います。ではー