100%GPL のメディア/ブログ向け WordPress 有料テーマ Snow Monkey を公開したので、実現したかったことや技術的なことなどいろいろ

WordPress の有料テーマをつくって販売したいとかねてから言い続けておりましたが、やっと公開できる状態になりました。テーマの特徴やら何やらは、マニュアルとデモを兼ねた公式サイトを見ていただくとして、ここでは概要と、有料テーマをつくる上でいろいろ考えたことを書きたいと思います。

実現したかったこと

100% GPL で、さらに、購入しなくてもコードを見たり試したりすることができる状態にしたい

まずこだわったのは「100% GPL で、さらに、購入しなくてもコードを見たり試したりすることができる状態にしたい」ということでした。

そもそも 100%GPL とはなにか

WordPress コミュニティではすでに知らない方はいないんじゃないかと思いますが、コミュニティ外の方だと知らない方が多いのではないかと思いますので一応説明を。WordPress はライセンスが GPL となっているため、WordPress のテーマやプラグインも自動的に GPL となります。それは WordPress の機能を利用するから、という理由からくるものなので、WordPress の機能とは関係のないモノ、例えば画像や CSS なんかは GPL にする必要はありません。ただ、そうは言っても画像や CSS も GPL になっていないと使うユーザーは自由を制限されちゃうよね、ということで PHP だけじゃなく画像や CSS などテーマ/プラグイン内に含まれるものは全部 GPL ですよ、というものを100% GPL、そうじゃなくて PHP は GPL だけどそれ以外は独自のライセンスですよ、というものはスプリットライセンス、と呼ばれています。

なぜ 100%GPL にしたのか

で、コミュニティ的にはそういった開発者やユーザーの自由を守る 100% GPL を応援・推進しようということで、コミュニティイベント(例えば WordCamp)でスピーカーやスポンサー、スタッフになれるのは公開しているテーマ/プラグインが 100% GPL になっている人・企業のみとなっていたりします。参加はもちろん誰でも自由です。僕が 100% GPL としたのはスピーカーやスタッフになれないから、というのもありますが、ユーザーが自由に使えるという部分に共感しているし、そういうオープンソース的思考が好きだからです。

なぜ購入しなくてもコードを見たり試したりすることができる状態にしたかったのか

もちろんテーマを使いたいという方にはご購入していただきたいわけですが、購入しないと使えない、コードを見ることができない、というのはちょっとどうなの?と思うところがあって、もうテーマ自体を GitHub で公開しちゃうことにしました。

やっぱりそれなりに高いお金を出して買うわけですから、買う前に試してみたいだろうし、開発する人ならコードみたいじゃないですか。仕事で有料テーマをいくつか触る機会があり、やはりというか、WordPress をやっている人にはほぼ常識になってきているとすら感じていますが、コードがひどいものが多かったです。インデントが無かったりスペースとタブが混在したりしていて単純に読みづらいもの、外部から入力があるデータをサニタイズせずにそのまま出力してしまっているもの、全ての有料テーマを見たわけではないので全てを否定するわけじゃありませんが、少なくとも僕が見たなかでこれはまともだなと思ったものはありません。

でもネット上を見回してみると、有料テーマ vs 無料テーマみたいな記事が結構あって、どれもこれも有料テーマが良いと書いてある。.org にホストしてあるテーマ(いわゆる無料テーマ)は掲載を承認してもらうために厳格なルールがあるので、有料テーマと比べると機能が見劣りすることがあります。ただこれはテーマを切り替えても機能が使えなくなることを防ぐ(見た目はテーマ・機能はプラグイン)という思想からくるものなのでまぁそれは置いておくとして、「有料テーマは無料テーマより安全」とか「(有料テーマの中でも)海外テーマは危険なので国内テーマを使いましょう」とか、いやいや、コード1行でも読んだ?みたいなデタラメな記事が結構あります(で、テーマへのリンクはアフィリエイトリンクだったりするわけですね…)。.org にホストしてあるテーマはレビュアーのチェックを必ず受けるので、コードの読みやすさも一定のレベルにありますし、バリデーション/サニタイズのチェックもされているので、そんなデタラメなテーマよりかなり安全に使用できます。

で、何が言いたいかというと、有料テーマより無料テーマが素晴らしいということじゃなくて、こういう問題ってコードが(より多くの)人の目に晒されているか、(より多くの)人が見ているか、というところがポイントなんじゃないかなと思うのです。そういう考えで、僕は「買わないと見せられません」ということはナシで、買わなくても誰でも見ることができるという状態にすることにしました。

なるべく WordPress の機能を活かして、なおかつ、基本的なことがすぐに実現できるテーマ

基本的なことがすぐに実現できるということには力を入れました。Web 制作をしていると、これは絶対にやる、ということが結構ありますよね。OGP だとか、Google Analytics だとか、シェアボタンの設置だとか、ちょっとニッチなところだとページトップに戻るボタンだったりとか、記事下のプロフィールボックスとか。「プラグインを入れればすぐにそれらも実現できる」というのが WordPress の魅力なわけですが、もう絶対 100% やるのであればプラグインを探して検討してインストールするのもめんどくさいのでテーマに入れちゃっていいじゃん、というのが僕の考えです(プラグインテリトリーのルールがあるので .org に掲載してもらいたい場合は全部 NG です)。ということで、これは僕はほぼ毎回やるぞというのは全部入れました。具体的に何が入っているかは公式サイトをご参照ください。

で、これらをオリジナルのオプション画面でやるのではなく、ほとんどをカスタマイザーでできるようにしました。ほとんどの項目はとりあえずカスタマイザーをみれば設定できる、という状態にしました。

単純に、一度有料テーマをつくって販売してみたかった

です。.org に掲載されたテーマの作者って数年前と比べるとだいぶ増えたなという感じがあります。でも有料テーマはどうでしょうか。前述したようなデタラメなテーマがいくつか目立っているだけで、コミュニティの中から有料テーマがどんどん出てきているという印象は今のところありません(ちなみにリキッドデザイン株式会社さんの有料テーマは 100%GPL です。WordCamp Kyoto でいろいろお話を伺うことができて参考になりました。)。じゃあ Habakiri で世間をわっと驚かせた僕が有料テーマもやってみようじゃないかと、そういうことです(すみません、でしゃばりすぎました土下座)。100% GPL で、全部 GitHub で公開しちゃった状態でどれだけ売れるのかというのを試してみたかったというのが結構大きいですね。

今後の展開がしやすい仕組みを整える

Snow Monkey だけ一生懸命つくって、第2段、第3段のテーマはまた1から頑張ってつくる、そして数が増える度にメンテ工数も掛け算になり、最後は手に負えなくなってやめる。こういうことになるのだけは避けたいと考えました。今回つくった機能が今後他のテーマにも簡単に流用できたり、修正する場合も最小限の手間で済むように設計やテンプレートの仕組みなど工夫しました。詳しくは後述します。

デザインコンセプト

WordPress のテーマを大きく2つにわけると「ブログ用」「Web サイト用」があります。海外では「Web サイト用」が主流のように思いますし、僕としても「Web サイト用」をつくりたいという気持ちがあったのですが、やはり「Web サイト用」は「ブログ用」に比べて工数もかかりますし、複雑になるので不具合もでやすいです。僕はこれで終わりにせずに第2段、第3段とリリースしていきたいと考えているので、第1段目からいきなりリリースに時間がかかってしまうのは避けたいと思いました。また、日本の有料テーマは「ブログ用」のものが多く、日本で勝負するならそのほうが需要があるのかなと考え、まず最初は「ブログ用」でいくことにしました。

では、どういうデザインでいくか。正直僕はデザインは請負でもやっていないですし、それほど自信もありません。なので、他の有料テーマには無い路線であれば勝負できるかなということで、他の有料テーマがどういう感じなのかを調べることからはじめました。全てを調べ尽くしたわけではないですが、僕のみた感じだと、ポップな感じであったり親しみのある感じのものが多い、という印象だったので、そういう路線はさけてモダンでクリーンなイメージでいくことにしました(そのほうが装飾も「薄い」ので、カスタマイズしやすいだろうという考えもありました)。

で、普通のブログ用だと他の有料テーマに多分勝てないだろうなと思ったので、写真を全面に出してメディアサイトでも使えるようなイメージでやることにしました。写真がないとハマらないというデメリットはありますが、これくらい思いきらないと多分インパクトも残らないものになると思うので、画像は全記事に必ず入れてくれ!という想定でつくりました。

プラグインテリトリー

ということで、そろそろ技術的な話も書きたいと思います。.org のテーマハンドブックにはプラグインテリトリーという項目があります。「テーマを切り替えても機能が使えなくなることを防ぐ(見た目はテーマ・機能はプラグイン)」ということですね。で、僕の有料テーマ Snow Monkey ではこのプラグインテリトリーを当たり前に侵害しています。例えば「Snow Monkey ではシェアボタンがデフォルトで設定できますが、テーマを変えるとシェアボタンが無くなるのでシェアできなくなるよ」ということです。あと「Analytics の設定をしたけどテーマを変えたら設定がなくなるのでアクセス解析ができなくなった」とか。それらをプラグインでやっておけばそういう問題は起こらないわけです。でも僕はそれをわかった上でプラグインテリトリーを破りました。利便性の問題と、解決法を思いついたからです。

利便性の問題

制作者みたいに WordPress に慣れている人であれば、見た目はテーマ・機能はプラグインという思想もしっくりくるだろうし、操作も慣れたもので特に何も思わないかもしれませんが、非制作者の方にとっては必要に応じてプラグインを探して検討してインストールする、というのはすごく難しいということを聞きました。僕自身、難しいとは思いませんが、すごくめんどくさいとは思います。テーマに最初から入っているなら時間はかなり短縮されるわけですから、それならそのほうが良いです。ただ、必要性がないものまで入っていたり、とても複雑な機能・大きい機能が入っているとメンテナンスやセキュリティの問題もあるので必ず検討・取捨選択は必要だと思います(NPM や Composer みたいに、テーマとプラグインを良い感じで依存解決できれば最高なのですが…)。

解決法

解決法については何度かブログに書いたので、もう知ってるよという方もいらっしゃるかもしれません。一言でいうと、各機能をそれぞれ小さなライブラリとして切り出して、全部 Composer でインストールできるようにしちゃうというアイデアです。Snow Monkey では、シェアボタンや、SEO まわりなど、すべての機能は全部それぞれのライブラリに分割して GitHub と Packagist で公開しています。だから、僕のテーマを使うのをやめて自作のテーマにしようとなっても、ライブラリを composer install すれば同じように使えちゃうというわけです。で、カスタマイザーの設定値も、テーマを切り替えても残しておいたほうが良いものについては theme_mod ではなく options に保存するようにしているので、それを使うようにすればそのまま設定を引き継いで利用することが可能です。

これらのライブラリは今後新しい有料テーマを開発するときも入れるようにするので、そうすれば僕のテーマであればどれに変更しても再設定の必要なくそのまま機能を引き継いで使用できるというメリットもあります。

さらに、それぞれのコードが各テーマにコピペされた状態であれば、その部分をアップデートするとなったとき、必ずどれかのテーマに漏れが発生するでしょう。人力でやるわけですから。でも Composer で管理しておけば、実際にコードをアップデートしなければいけないのはそのライブラリだけなので、それをアップデートしてしまえば、あとはテーマ側ではコマンドをいくつか叩くだけ。僕自身更新が超楽になりますし、どのテーマを使っても最新の機能が反映されているというのはユーザーにとってもかなりのメリットだと思います。

また、まだ実現はできていないのですが、それぞれのライブラリをプラグイン化して、テーマを切り替えてもそのプラグインをそれぞれ入れればとりあえず引き続きその機能が使える、という状態にしたいなと考えています。それができるのも Composer と Packagist があるからです。素晴らしい!

ビルド・リリース

これ、WordPress でテーマを作ったことがある人にはあるあるだと思うのですが、themes/my-theme の直下ってものすごくファイル散らかりますよね。テンプレートファイルは直下に置かないといけないし、.gitignore とか gulpfile.js とか設定系のファイルもまざってごちゃごちゃになるし…。Composer 対応のライブラリでは、直下には設定ファイル類だけを置いて、コードは src というディレクトリに配置する、というのがスタンダードですが、そういうようなことを WordPress テーマでも実現したいと考えました。請負でつくるものだと納品してしまえばそんなに触ることもないのでまだ良いですが、公開していると日々修正やアップデートをしなければいけないので、そうしなければめんどくさくて仕方がないです。

ということで、開発はこういう構成でおこなって、リリース版はこういう構成でビルドされるようにしました。最初は設定ファイルなど不要ファイルを削除しただけで開発版そのままの構成でリリースできないか試行錯誤しましたが、やっぱりテーマ直下にテンプレートや style.css がないとどうにもならないといういくつかの問題に直面したので、最終的に開発版とリリース版で構成を変えるようにしました。環境をつくるまでがかなり大変でしたが、環境ができてからはかなり快適になりました。ビルドとリリースは Travis CI で行っています。実際の処理はこの辺

テーマ設計(テンプレート構成)

これも過去に記事を書いたことがあるのでご存じの方はご存知かもしれません。そうです、Mimizuku です。Mimizuku はもともと子テーマをつくるための親テーマというコンセプトだったのですが、全ての機能を Composer のライブラリに切り出したことでめちゃくちゃ薄いテーマになったので、スターターテーマ(それ自体をカスタマイズするテーマ)にコンセプトを変えました。そしてそれをベースに Snow Monkey を開発した経緯があります。

で、本題に戻ります。WordPress のテンプレートファイルってget_header()とかget_footer()とか書いてそれ自体がページ全体を表示するテンプレートになっていますよね。だからテンプレートの数が増えれば増えるだけそういった共通部分の重複も増えます。重複が増えるということはメンテがし辛いということなので、そういった共通部分は切り出してレイアウトファイルとし、中身の部分だけをビューファイルとして管理したほうがメンテナブルだし効率的です。ということで、Snow Monkey では page.php などのテンプレートファイルがコントローラーの役目を果たし、レイアウトファイルとビューファイルを指定してページがレンダリングされる、という構成になっています。

ショートコード

有料テーマにはボタンや吹き出しなどコンポーネントのショートコードがたくさん揃っていることが多いです。これはこれで HTML を書けない人でも簡単に見栄えするコンポーネントを記事中に配置できるので便利だとは思うのですが、テーマを変えたときに問題が発生します。そのテーマがショートコードを HTML に変換しているので、テーマを変えたらショートコードがショートコードのまま画面に表示されてしまうのです。つまりテーマの変更が超大変になります。

ただ、そういったボタンや吹き出しなどのコンポーネントは便利だから使えるようにしたい。そこで Snow Monkey ではショートコードではなく、HTML そのものをエディタに挿入できるようにしました。

これでも、CSS はテーマに依存してしまうので、テーマを切り替えたらごそっとデザインは抜け落ちてしまいますが、HTML 自体は残るので意味不明なショートコードが画面に並ぶということは避けられます。変更後のテーマに CSS を追加すれば自分の好みのデザインでまたデザインを適用することが簡単にできるわけです。

また、任意の HTML コードもビジュアルモードのままで簡単に挿入できるようにしました。ビジュアルとテキストを行ったりきたりするのがかなりストレスなので、これめちゃくちゃ便利だと思うんですけどね、どうでしょう?

オリジナルウィジェット

WordPress にはウィジェットという便利なものがあります。ドラッグ・アンド・ドロップするだけで所定の位置にコンポーネントを配置できるアレです。関数名(register_sidebar())からもわかるように、もともとはサイドバー用に用意された機能だと思うのですが、めっちゃ便利だということで、記事上とか記事下とか、ヘッダーとかフッターとか、そこら中にウィジェットエリアがあるテーマも珍しくなくなりました。ただ、標準で用意されているウィジェットって、やっぱりサイドバー用だよなぁという感じのものが多く、せっかくフロントページとかにウィジェットエリアがあってもあまり活用できません。

そこで、Snow Monkey では最近の Web サイトでよくみかけるコンポーネント(特徴とかが3つ並びになってるやつとか)をウィジェットで設置できるようにしました。フロントページにウィジェットエリアがあるので、結構これだけでそれっぽいページがつくれちゃったりします。

例えばよく見る特徴とかが3つ並びになってるやつ(PR Box という名前にしています)は、表示する項目が ACF のリピーターフィールドみたいに増やしたり減らしたりできて、PC・タブレット・スマホサイズでそれぞれ何カラムで表示するか設定できたりします。良いでしょ?

PR Box ウィジェット

ショーケースウィジェット

あと自分で天才的なひらめきだと思ったのはランキングウィジェットです。有料テーマを調べているとテーマにランキングウィジェットがあって「プラグインだと重いという声があるので自分で実装しました」とか書いてあるのを見たことがありますが、重くなるのはプラグインのせいじゃなくて、アクセスがある度にデータベースに insert をかけることと大量のデータを集計することが原因なので、プラグインであろうがテーマであろうがどっちにしろ重くなります。ということで Google Analytics の API でランキングをつくってくれる Simple GA Ranking というプラグインがあったりもするのですが、そこで僕はひらめいたわけです。別に実際のアクセスを自動的に集計して反映しなくてよくね?と。普通に自分で並べればいいわけです。1位はこれ、2位はこれと。実際、どこかのページにランキングが載っていたとして、それが本当に自動集計してリアルタイムの結果を表示しているなんてわからないですよね?なら別に手動でいいじゃんと。はい。

コード品質

.org のテーマのようにレビュワーのチェックを受けるわけではないので、常に CodeSnifferPHPMD のチェックを行うようにしています。コーディングルールのチェックはもちろんサニタイズ漏れも指摘してくれますし、かなり便利です。何箇所か手抜き(チェック除外)しているところがあるのと、ユニットテストを書いていないライブラリがあったりするので、その辺もおいおい何とかしたい…。

どこで販売するか

Woocommerce + Stripe を試してみたところ思いのほか簡単に構築できたのでそれが良いかなーと思っていたのですが、僕が経理に使っている MF クラウドと Stripe の連携が無さそうで、となると経理がすごくめんどくさくなりそうなので、既にアドオンなどを販売している BASE でテーマも販売することにしました(こっちは連携できる)。ただ BASE は自動返信メールの内容をカスタマイズできないのがちょいと痛いんですよね…。めちゃくちゃ売れるようになったら Woocommerce + Stripe にして経理を外注したい…。

サポートについて

本番サイトで使用する場合はもちろん購入いただきたいですが、フルオープンで公開している以上、そこからダウンロードして本番サイトで使う人も一定数でてくるよなぁと思います。なので、使い方がわからないとかそういったサポートについてはご購入者の方のみにおこなうようにします。開発者の方が、これバグじゃない?とかこうしたほうが良くない?みたいなことがある場合は GitHub に issue でもプルリクでも頂けると非常に喜びます。

ワンクリックアップデート

.org のテーマを使っている場合と同じように管理画面からワンクリックアップデートできるようにしています(Snow Monkey が有効化されている場合だけアップデートのチェックが動くので.org のテーマと全く同じ体験かというと若干違います…)。有料テーマ含め、野良テーマだとアップデーターが仕込まれておらずアップデートは FTP で、みたいなものがあったりします。そうなると面倒でセキュリティフィックスを含むリリースがあってもアップデートをしないということがあるだろうと思います。だから管理画面からワンクリップでアップデートできる機能は必須だと考えています。

今後の予定

機能の作り込みはかなりできて、それを Composer で他テーマに流用する仕組みも整えたので、まだ第2段、第3段とつくっていきたいと思います。まだ次のことは考えていませんが、今回のテーマがメディア・ブログ用だったので、Web サイト用もつくりたいなぁ。

Snow Monkey ももうバグはないだろうと思ってリリースしましたが、実際に使っていただいた中で、いくつか不具合報告をいただいているので、しばらくアップデートが続くと思います。まだ文字サイズとか余白の感じとか悩むところもありますし。もちろんセキュリティフィックスは入れますので、絶対に自動アップデートをオフにしたり、テーマを直接カスタマイズしたりはしないでください!

おまけ: Snow Monkey という名称について

「モンキーレンチ」のリブランディングを長崎のデザイナーPRISM!さんにお願いしました」でも書きましたが、統一感をだすためにプラグインは工具の名前を、テーマは猿の名前をつけるようにしました。で、猿の名前をずっと検討していたら、ニホンザルは英語で Snow Monkey と呼ばれているということで、Mac の Snow Leopard みたいでカッコイイし、日本人がつくっているからニホンザルというのもぴったりだなということで Snow Monkey に決めました。次は何にするか悩む…。

MW WP Form

MW WP Form はショートコードベースのフォームプラグインです。多くの機能を持っており、例えば、多くのバリデーションルール、問い合わせデータの保存、そしてグラフ機能集計などを使用することができます。

さらに詳しく
Habakiri

Habakiri

Bootstrap ベースのシンプルな WordPress テーマ。レスポンシブ、多くのカスタマイズ機能。圧縮された CSS・JS を使用する高速化対策。Microformats 対応。Sass、クラスベースの functions.php。

さらに詳しく
basis-stylus

Basis

軽量なレスポンシブ Stylus/CSS フレームワーク。Flexbox ベースのグリッドシステム、疎結合なコンポーネント、バーティカルリズム。

さらに詳しく