キタジマ タカシ Snow Monkey アドベントカレンダー3日目の記事です。昨日は公式テーマディレクトリのレビューアであるミルコンさんが参加してくれました。
こんなとこまで見たの！というようなところまで目を通していただいたようで、しかもWP Customizer Framework という、僕的にもそうそう、そうでしょ！そうなんですよ！というところが評価されていたのでとても嬉しかったです。WP Customizer Framework については後日記事を書きたいと思います。あと、
そもそも .org に来るテーマはだいたい品質がお察しのものばっかりなので
というのが意外で驚きました。僕が最初に申請をだしたときはすごくレベルが高くて恐れ多い場所、というイメージだったので、そういう状況であればもっと気軽に申請できそうですね（レビュワーさんにとってはすごく大変でしょうが^^;）。申請した時点で自動チェックが行われますが、そこである程度コーディングスタンダードとかもチェックしたほうができると良いのかもしれませんね。
ということで3日目の記事です。なるべく序盤は技術系じゃない記事を書こうと思っていましたがもうさっそくネタに困って技術系記事を書いてしまっています！ということで、今日は Snow Monkey の基本的な構造がどうなっているかについて書きたいと思います。
プラグインテリトリー
WordPress にはプラグインテリトリーという思想があります。これは、テーマでやるべきこととプラグインでやるべきことを明確にわけて、これはプラグインでやること（プラグインテリトリー）だからテーマには持たせないでね、という思想のことです。どういうものがプラグインテリトリーに該当するかというと、シェアボタンとか、OGP とか、見た目に関する部分以外の機能的な部分になります。
そして、公式テーマディレクトリはプラグインテリトリーを侵しているテーマは承認されません。そうすることで、公式ディレクトリを利用するユーザーは、公式ディレクトリにあるテーマを使う限り、テーマを変更することで必要だった機能が使えなくなったりすることなく、自由にテーマを変更できるようになるメリットがあります。
というところまでが前置き。で、Snow Monkey はプラグインテリトリーを完全に侵害しています。これは以前にも書いたので詳しくは省略しますが、プラグインを複数入れる煩雑さや統一された設定画面を提供することで利便性を高める等の理由でわざとそうしています。ただ、そうすることでユーザーが自由にテーマを変更できる利便性や安心感を失って良いのかというと話は別です。僕は公式ディレクトリにテーマを掲載しているわけではありませんので、あくまで「モンキーレンチのプレミアムテーマを使う限りは」自由にテーマを変更できれば良いと考えますが、完全にロックインしてしまって他のデベロッパーのテーマに移るのが不可能というのもまた WordPress の思想に反すると思いますので、ある程度 WordPress の思想には則った形で、利便性を考えてあえてプラグインテリトリーを侵す、という選択をしました。
Composer の活用
では、どうするのか。僕は Composer を使うことでそれを解決しようとしています。Composer の概要についてはこちらの記事がわかりやすいです。
プログラマーじゃない方にわかりやすく説明すると「必要な jQuery のプラグインを良い感じにインストールしてくれるもの」みたいな感じです。この「良い感じに」というところがミソです。普通に jQuery のプラグインとかを使おうとした場合、zip でインストールしてきたものを解凍してディレクトリに放り込むというのがよくあるやり方だと思いますが、これだとプラグインがアップデートされたときにそれを反映したい場合はまた zip で落としてきて云々とやらなければいけません。また、バージョン管理を考えたとき、プラグインはプラグインで作者が管理しているはずなのに、自分のリポジトリ内でもそのプラグインを管理してしまう（本当であれば自分で管理する必要のないコードは極力除外してスリムなリポジトリを保ちたい。そのほうが管理しやすいので。）という二重管理の問題も発生します。
実際の構成
Snow Monkey には例えば以下のような機能があります。
- シェアボタン
- OGP
- CSS によるギャラリー＆ライトボックス
そしてそれらを全て個別の Composer ライブラリに切り分け、それを取り込む形にしています。
snow-monkey ├ composer.json └ vendor # Composer ライブラリが格納されるディレクトリ ├ wp-share-buttons # シェアボタン ├ wp-ogp # OGP ├ wp-pure-css-gallery # CSS によるギャラリー & ライトボックス
composer.json というのが、Snow Monkey はどのライブラリに依存していますよ（動作のために必要としていますよ）ということを記述したファイルです。Snow Monkey のリポジトリではこのファイルだけを管理すれば良くなります。実際のコードはここで管理する必要がありません。これだけ見ると、ただ手間が増えただけで一体何のメリットがあるんだ…という感じがしますよね。実際、これらのライブラリを Snow Monkey で使うだけならほぼメリットはありません。と、いうろころで、前述したプラグインテリトリーの問題とつながってきます。
僕は Snow Monkey だけでなく、デザインテイストの違ったテーマを今後複数リリースしていきたいと考えています。そうしたとき、例えば「このテーマには OGP はいらないな」とはならないと思うんです。どのテーマにだって絶対に必要ですよね。ということは、上記の wp-ogp（のコード）はどのテーマにも必要になってくるということです。もしそのとき Composer を使わなかったら、どのテーマにもこの wp-ogp に該当するコードが含まれることになり、つまり、もし wp-ogp に該当する部分にバグがあったり、機能追加をしたいとなったら、全てのテーマでその部分の修正を行わなければなりません。「いや、それが普通でしょ？」と思う方もいらっしゃるかもしれませんが、このようなやり方は 100000% ミスを生みます。もし1つのテーマでだけ1回修正をいれるのを忘れてしまったら、もし1つのテーマでだけ修正する箇所を間違えてしまったら…こういうことが数度続けばもはや同じ機能なのに同じコードを保つことは難しく、それぞれで違うバグが発生してしまうことになります。そうするとテーマを変えても同じように使えると思っているユーザーの利便性を損ないますし、開発する側にとっても「めんどくさ、もうやーめた…」となりかねません。
Composer を使えばテーマのリポジトリで管理しなければならないのは、そのコードそのものではなく composer.json ファイルだけです。composer.json にこのライブラリを使いますと1行書けば良いだけなので、コードをまるっと管理するより明らかに簡単です。つまり前述したようなミスが起こる確立をグッと減らすことができ、かつユーザーも安心してテーマを切り替えることができる、というわけです。
他のデベロッパーのテーマに切り替えるときも活きてくる
ここで「Composer を使うことでモンキーレンチのテーマを使う場合は同じ機能を同じように使えるということはわかった。でも他のデベロッパーのテーマに変えたらもうダメでしょ？」と思われたと思います。その通りです。ただ、Composer を使っていることで、この問題も解決できるようになります。その Composer ライブラリのみを取り込んだプラグインを作れば良いのです。Composer は WordPress テーマ固有の機能というわけではないので、テーマだけではなくプラグインに機能を取り込むこともできるのです。つまり、その機能だけを取り込んだプラグインを作ってしまえば、他のデベロッパーのテーマに切り替えたとしてもそのプラグインを同時に有効化すれば、その機能を殺さずに他のデベロッパーのテーマも使用できる、というわけです（現実的には、各ライブラリは設定画面は提供しないので子テーマ等で多少調整が必要だと思います）。
僕は Snow Monkey で利用するために開発した Composer ライブラリは全て公開していますので、ご自身でそのライブラリを取り込んだプラグインを作ることは可能です。まだ用意はできていませんが、そのうちそれぞれのライブラリごとのプラグインもつくって販売するようにするつもりです。そうすれば「他のデベロッパーのテーマに移った後もこの機能は使い続けたい」というものがあれば、そのプラグインだけ購入すれば引き続きその機能を使用することができるようになるというわけです。
Snow Monkey と Mimizuku
ここまで Snow Monkey と Composer について書きましたが、ここで、もう一歩踏み込んだ話をしたいと思います。先日の記事で「Mimizuku は子テーマ開発のためのフレームワークで、それを試してみたくて Snow Monkey をつくりはじめた」ということを書きました。でも Snow Monkey は子テーマではありません。Mimizuku は現在子テーマ開発のためのフレームワークではなく _s のようなスターターテーマとなっています（※もちろん、親テーマとして使うこともできます）。実際に使ってみると子テーマは思っていたよりは大変ということがわかった、というのもありますが、ここにも Composer の大きな影響があります。
Mimizuku は Snow Monkey のベースとなっているテーマですので、Snow Monkey と同じように各機能は Composer のライブラリを取り込む形で実装されています。「ベース」ということは Snow Monkey より薄いテーマであり、実際のところ、Mimimizuku は必要なライブラリを読み込んで、あとはサンプル程度に HTML が入っている、くらいの感じの超薄薄なテーマになっています。そして、読み込んでいる Composer のライブラリはどれも必須なものばかりということで、それらをさらに1つの Composer ライブラリ（コア）にまとめてそれを読みこむ形という、ポータブルな実装になっているのです！図に表すとこんな感じ。
Mimimzuku
└ mimizuku-core
├ wp-breadcrumbs
├ wp-oembed-blog-card
├ wp-view-controller
├ wp-share-buttons
├ ...
つまり、実際には Snow Monkey は wp-share-buttons などの個別のライブラリを読み込んでいるのではなく、mimizuku-core という Mimizuku のコアになる各機能がパッケージングされたライブラリを読み込んでいるのです。もちろん、mimizuku-core に直接機能が実装されているわけではなく、ここでも composer.json でライブラリが指定してあるだけです。
次回は
というところで結構長くなってきたしネタの枯渇が心配なので、一旦終わりにして次回に温存したいと思います。もし Snow Monkey についてこういうことが知りたいなどあればぜひお知らせください。また、使ってみたとか、そういう記事でもとても嬉しいのでぜひお気軽にご参加ください（切望
