こんにちは。この記事は「 Movable Type Advent Calendar 2016 - Adventar 」の 6 日目の記事です。Movable Type のアドベントカレンダーで 5 年連続で 12 月 6 日に書かせていただいております。

今日でついに 40 歳になりました。2016 年は家族で New Zealand に引越したり、40 歳になったり、bit part にもメンバーが加わったりと節目の年となりました。これからもよろしくお願いいたします。

今年のアドベントカレンダーの記事は、先日の MTDDC Meetup TOKYO 2016 のセッションで相棒の mersy が紹介した「 MT7を先取り!? DataAPI と Riot.js で作るユーザフレンドリーなダッシュボード 」関係にしようと思ったのですが、ここのところ管理画面ネタばかりなので、今回はオモテ側のお話にしようと思います。

今回のお題は「Movable Type で作る静的な動的Webサイト」です。

静的な動的Webサイト

静的な Web サイトと動的な Web サイトの違いについて検索してみたところ下記の説明が分かりやすいです。

静的コンテンツは、index.html などのように、要求のパスに指定されたhtmlなどのデータがそのまま応答のデータとして送信される方式のWebページのことです。例えば、会社概要や事業内容など、誰が見る場合でも常に同じ内容を提供する場合に使われます。 　それに対し動的コンテンツとは、search.php?q=pentagon などのように、パスと共にクエリと呼ばれるパラメータが要求データとして送信され、これを受信したWebサーバは、スクリプトと呼ばれるプログラムに渡されたパラメータを指定して実行することで結果を生成し、それを応答のデータとしてブラウザに送信する方式のWebページのことです。
WWWの基本技術 - 静的コンテンツと動的コンテンツ より引用

Movable Type は、通常は再構築で静的コンテンツを書き出すタイプの CMS です。しかし、再構築時のサーバーの負荷を軽減したい、再構築時間を短縮したい、またはそもそもダイナミックにコンテンツを切り分けたいといった要望も多々あり、最近では、Movable Type にも動的コンテンツを生成することが求められます（最近に限った話ではないですけど）。

Movable Type でそれらの要望に答える方法はいくつかありますね。

• ダイナミックパブリッシング
• DynamicMTML
• Data API で取得したコンテンツでゴニョゴニョする

これらの中で僕がよく使っていたのが DynamicMTML です。これは強力な機能ではありますが、下記のようなデメリットもあります。

• 静的部分と動的部分のテンプレートが分かりにくい
• 規模の大きいサイトになると動作が重くなりがち
• プラグインが提供する MT タグがダイナミックパブリッシングにも対応してなければならない

これらに変わった解決策はないか、Movable Type の再構築という特徴を活かして何かできないか、というこで考えたのが「静的な動的Webサイト」です。

WordPress などの動的 CMS は、ざっくりいうとリクエストがあったときに PHP が処理して、データベースからデータを持って来て、それをテンプレートにあてはめてページを返します。こういった動的 CMS はとても便利な反面、データベースが落ちたら何も表示されない、といったリスクもあるので、そういったリスクを懸念して Movable Type が選択されるというとこもあります（もちろん他の理由もたくさんあります）。

この「静的な動的Webサイト」では、表示に必要なすべてのデータを HTML などの表示上の情報を含まない純粋なデータとして書き出します（ 静的 ）。そして、それを PHP の Twig というテンプレートエンジンで処理して表示しよう（ 動的 ）、というものになります。

これであれば、データベースが落ちても大丈夫ですし、いざという時は PHP が動くサーバーであれば簡単に退避できますし、CMS 機とフロント機を切り分けることもできますね。

メリット

この方式のメリットを考えてみると、下記のような項目が挙げられます。

再構築が軽い

基本的に表示に必要なすべてのデータを書き出すので、カスタムフィールドを追加したり、データの形式を変更したりなどといった運用中はレアな場合を除いて「すべて再構築」する必要がありません。

デザインの変更があっても、Twig のテンプレートを書き換えるだけで、「すべて再構築」する必要はありません。

管理画面のテーマ、テンプレートで管理しなくても良い

データと表示に関するものが完全に切り離されているので、Twig のテンプレートを Movable Type のテンプレート（管理画面）で管理する必要がありません。

もちろん全部管理画面のテンプレートに入れて管理しても良いですが、構築中、それって意外と手間がかかりますよね。最近ではテンプレート開発にも Git などが導入されているので、履歴は Git 任せで良いですし、お客様が更新したい場合は GitHub などで編集してもらって Webhook で pull するようにするとかどうですかね。

データベースが落ちても表示に影響ない

データファイルと表示のファイルが別々で、すべて実ファイルとして存在しています。なのでデータベースが落ちても影響ありません。

制作から表示までの処理の流れ

作り方を書いているとかなりの量になってしまうので、今回は流れだけを書きます。

制作時の流れは下記のような感じです。

• Movable Type のアーカイブテンプレートで個別記事やアーカイブの情報を書き出す（JSON, array）
• Movable Type のインデックステンプレートで必要な情報書き出す（JSON, array）
• Twig のインストール
• Twig テンプレートの作成

ちなみにデータは JSON である必要はなく、どちらかというと PHP の array にした方が処理がスムーズです。Movable Type のテンプレートから PHP で扱うデータとしては JSON が一番書き出しやすいのでそうしているだけです。

実際に僕がこの仕組みを取り入れた案件では array にしました。

表示の流れは下記のようになります。

• 画像などを除いたすべてのアクセスを1ファイルに集める（ index.php など）
• リクエストのURLを解析して、リクエストされたページを表示するためのデータと Twig テンプレートを取得する
• Twig でレンダリング

MVC でいうと

細かい議論は置いておいて、MVC でいうと Model が Movable Type、 View が Twig、 Controller が index.php というイメージです。個人的にはとてもスッキリしました。

まとめ

今回の話、そんなに目新しいことではないのですが、PHP 系で良い CMS がいくつもある中で、Movable Type の長所を活かしていける方法はないかと思ってやってみました。

もちろん、「いちいちデータファイルを書き出さないで Data API でキャッシュとかすればいいじゃん」ということにもなりますが、そこは MT、やっぱり再構築しましょうよ。

なんだかんだ言って、Movable Type の再構築、便利です。

最後、少し息切れした感じがありますが、以上です。この仕組みを簡単に取り入れられるようにテーマなどにして公開したいと思っています。