WordCamp Tokyo 2016 で「本当に使えるテーマとはどのようなものかを考え続けた結果」というLTをやったけど全然間に合わなかったので補足記事を書きました

WordCamp Tokyo 2016

昨日 WordCamp Tokyo 2016 に参加しまして、「本当に使えるテーマとはどのようなものかを考え続けた結果」という LT をやりました。約20名が登壇する LT 大会ということで、結構な時間、さまざまな内容の LT が繰り広げられていました。今回は音の大きさを計測する機械?を設置して、歓声や拍手が大きかった LT については懇親会で再演する、ということで、皆さん作り込まれたネタですごい盛り上がりを感じました。で、僕はそんなにウケで勝負できる技量はないので、逆に全員ポカンとさせてやるぜ!と意気込んでガチ技術ネタで挑んだのですが、「考え続けた結果」とか言いながらそのオチの結果まで普通にたどり着きませんでした。だめじゃん…。

そもそも LT でやるにはかなり端折らないといけないネタで前提条件とか解説とかはすっ飛ばしていたので、そのあたり含め補足記事を。

テーマ制作をどのように効率化するか

WordPress でサイトを構築する仕事、となると一般的にはテーマを作るのが制作時間の主な時間を占めることにになるかと思います。で、やっぱりそこは時間がかかるので何とか効率化して時間を短縮したいと思うわけです。そして色々試行錯誤して Habakiri というテーマを作りました。なぜそういう設計にしたとかどういう工夫がしてあるとかは Habakiri Advent Calendar にまとめてあります。

実際に Habakiri は仕事で使っていまして、今までスクラッチであったりオリジナルのベーステーマであったりでやっていたときに比べかなり良い感じに構築が行えるようになりました。自分のために作ったテーマではあったのですがユーザーさんからも狙い通りの反応があり「やっぱりコンセプトは間違ってなかったな」とか思っていたのですが、何件か使っているうちに「おやおや、これは思ったほど機能していないんじゃないの…?」みたいなことが見えてくるようになりました。

カスタマイザー

まず1番はカスタマイザーです。カスタマイザーは管理画面からポチポチやるだけで色の設定をしたりレイアウトを変えたり色々な設定ができる機能があるのですが、その設定値はデータベースに保存されるためデプロイがどうしても難しくなります。個人ユーザーが自分のサイトを作るにはマッチするのですが、請負でどのようなデザインのサイトにも対応しようとするとカスタマイザーで用意された設定では不足だったり、逆に過多で設定項目を殺さないといけなかったり、逆に手間になることが多いということが見えてきました。

CSS

次はスライドのメインテーマですが CSS や HTML がそもそも邪魔、と思うようになるわけです。CSS フレームワークでも同様の問題があるのでよく使われる方はわかると思いますが、ベース(ここでは親テーマ)の CSS が強いとそれを上書きする CSS を書かなければいけなくなります。デザインがその CSS フレームワークや親テーマに沿ったものであればちょっとした追記で済みますが、請負だとそういう仕事ばかりではないのでがっつり上書きしなければいけないみたいになることもあります。

個人的に CSS の「上書き」は「新規追加」よりかなりストレスなので、ならいっそ親には必要最低限の CSS だけで良い。更に、生 CSS ではなく、良く設計された CSS メタ言語で書いて必要な部分だけインポートしたり、変数を上書きしてスッキリ初期スタイリングを行ったり、自動的に最適な値を返すミックスインを作って line-height や margin を何px とか一々測ったりするのを無くす、とかそういうことを考えるようになりました。その辺りまで含めてテーマだけで完結しようとすると少々ヘビーなので、僕の場合は Stylus/CSS フレームワークとして切り出して別リポジトリで管理しつつ、npm でテーマに含める、みたいな構成にしました。

HTML

HTML についても CSS と同様で親でがっちり決まっていると邪魔なわけです。ただ、これは CSS と違い、(レイアウトについて)構造だけ定義するとか上書きするとかいうことができません(スライド中にも書きましたが「いやいや子テーマでテンプレート上書きすればいいじゃんw」と安易に考えるのはデメリットもあるので注意が必要です)。では、どうすれば良いか、テンプレートと HTML を疎結合にして差し替え・切り替えを簡単にできるようにすれば良いわけです。つまり「親テーマはベースとなるデザインを定義するもの」ではなくて「テーマを効率的に作るための機能を持つもの」として使うという考え方です。

ここで大事なのは「親テーマにベースとなるデザインを定義するのは間違い」ということではないということです。あくまで僕のやりたいことを実現するためにはこういう設計が適していた、ということで思想の違いですね。個人ユーザーの方に普通に WordPress でサイトやブログを作ってもらおうということであれば、僕のこの思想のテーマは全くマッチしないでしょう…。

コントローラーを作る

で、どのようにテンプレートと HTML を疎結合にするのか、ということですが、通常であればテンプレートに直接 HTML を書くところを、間にコントローラーを挟んでそいつでレイアウトファイルとビューファイルを指定してレンダリングさせれば良いわけです。例えば、下記のような感じです。

before ( single.php )

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>…</head>
<body <?php body_class(); ?>>
<div id="container">
    <?php get_header(); ?>
    <div class="contents">
        <main>…</main>
        <?php get_sidebar(); ?>
    </div>
    <?php get_footer(); ?>
</div>
</body>
</html>

after ( single.php )

$layout = 'layout/right-sidebar';
$view   = 'template-parts/content/content';

Controller::set_layout( $layout );
Controller::set_view( $view, get_post_type() );
Controller::render();

right-sidebar.php の例

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<?php get_template_part( 'template-parts/head' ); ?>

<body <?php body_class(); ?>>
<div class="_l-container _l-container--sticky-footer _p-drawer _c-drawer">
    <?php get_template_part( 'template-parts/drawer-nav' ); ?>
    <?php get_header(); ?>

    <div class="_l-contents" role="document">
        <div class="_c-container">
            <div class="_c-row _c-row--margin">
                <div class="_c-row__col _c-row__col--1-1 _c-row__col--lg-3-4">
                    <main role="main">
                        <?php Controller::load_view(); ?>
                    </main>
                </div>

                <div class="_c-row__col _c-row__col--1-1 _c-row__col--lg-1-4">
                    <?php get_sidebar(); ?>
                </div>
            </div>
        </div>
    </div>

    <?php get_footer(); ?>
</div>

<?php wp_footer(); ?>
</body>
</html>

こうしておけば、例えばこのページとこのページはレイアウトが違うんだよ、みたいなときにレイアウトファイルだけをすっきり差し替えられますし、全ページ共通のレイアウトの修正等がある場合も少ない箇所の修正で対応できるようになります。そして、ヘッダー、サイドバー、フッター、コンテンツ部分(ビューファイル)もレイアウトファイルと同じように差し替えがしやすい仕組みを用意しておけば、かなり自由に変更が効くようになります。

オチ

そして、大事な結果です。「本当に使えるテーマとはどのようなものかを考え続けた結果」どうなったのか。

一般的なテーマと構造が違い過ぎるため実務投入する勇気がありません。完。

どうもありがとうございました。ということで試してみようじゃないかという男気あふれる方はぜひ使ってみて感想など書いて頂けるとすごく嬉しいです。僕のサイトもなる早で乗り換えたい所存…

WordCamp Tokyo 2016 は昨日で終わりではなく本日もコントリビューターデイ・ハッカソンが開催されています。

そういえば結局昨日は座談会部屋と LT 部屋にずっといてセッションは全然見なかったので、WordCampTV でセッション動画が見れることを楽しみにします(昨年の動画も全部は上がっていないみたいなので、それも見れるようになると良いなぁ…)。

  • ブックマーク
  • Feedly

この記事を書いた人

キタジマタカシ

長崎在住、フリーランスのWordPress テーマ / プラグインデベロッパー。 多数のプロダクトをオープンソースで開発・公開しています。現在は WordPress 有料テーマ Snow Monkey を開発・販売しています。