前回書いた静的サイトジェネレータ「Phest」導入のメリット5の続編です。
前回は初期コーディング時に導入した際の話を書きました。
今回は既にあるサイトのリニューアルや、商品追加などのある程度規模の大きい更新に対してPhestを使ってみた時の話です。

リニューアルや更新はもしかしたら初期構築よりややこしいかもしれません…
既存のソースを理解し、影響範囲を常に意識しながら作業する必要があります。
だいたい既存のソースをある程度ひっぱってきてテスト環境を作り、変更したファイルを書き留めながら進めます。
小さい規模だとこのやり方でいいのですが、規模が大きくなってくると手に負えなくなってしまいます。

なので、Phestで楽になりましょう！

もくじ

• そもそも静的サイトジェネレータとは？
• メリット1:変更のあるファイルのみをまとめておき、編集できる
• メリット2:既存のcssファイルに対して、sassを導入しやすい
• メリット3:大量生産系の作業に特化している
• メリット4:静的サイトジェネレータ「Phest」導入のメリット5であげたメリットも使えます
• 既存サイトにPhestを組み込む際の導入手順
• まとめ

• そもそも静的サイトジェネレータとは？
• メリット1:変更のあるファイルのみをまとめておき、編集できる
• メリット2:既存のcssファイルに対して、sassを導入しやすい
• メリット3:大量生産系の作業に特化している
• メリット4:静的サイトジェネレータ「Phest」導入のメリット5であげたメリットも使えます
• 既存サイトにPhestを組み込む際の導入手順
• まとめ

まず前提として、他にもやりかたはたくさんあると思います。
svnなどでバージョン管理をするのもひとつの手なのですが、
CMSが導入されていたりすると最新ファイルを常にsvnで管理することはできません。
CMSがあるならローカルに落とす意味ないのでは…と思うかもしれませんが、テスト用の環境（テスト用のCMSや、SmartReleaseなど）がないとローカルで環境を作ってクライアントに確認を取るしかありません。
なんだか、CMSで効率化しているのか、手間を増やしているのかわからなくなってきますね！

そもそも静的サイトジェネレータとは？

テンプレートファイルを元に、プログラム的にhtmlファイルを生成する手法が静的サイトジェネレータです。
考え方はCMSと似ています。
CMSと大きく違うのは、データベースを必要とせずサーバーがなくても動作する点です。

メリット1:変更のあるファイルのみをまとめておき、編集できる

Phestは上の図のようになっています。
テンプレートファイルをまとめた/source/ディレクトリ、ビルドで出力されたファイルが入ってくる/output/ディレクトリ、さらにその中にテスト用の/local/ディレクトリと本番用の/production/ディレクトリが入っています。
この"ビルド"をうまく使うことで、変更のあるファイルのみを一箇所にまとめて作業することができます！

メリット2:既存のcssファイルに対して、sassを導入しやすい

Phestにはsassのコンパイル機能がついています。
scssファイルをまとめるディレクトリなどを新たに作る必要はなく、
既存のcssの拡張子をscssにするだけでビルド時にコンパイルしてくれます。
なので一瞬で導入できます。

※/local/ではCompact、/production/ではCompressedでビルドするので注意

メリット3:大量生産系の作業に特化している

YAMLとSmartyを組み合わせることで、大量生産系の作業がとっても楽になります。
単票ページもアーカイブリストも条件付きリストもいけます。
これはリスト出力のサンプルです。

YAML

Smarty

CMSで構築されているのであれば、MTテンプレートタグで書けばいいのでは？と思いましたか？
フリーエリア内に共通要素が入ることもあったり、同じテンプレートの過去記事には反映したくなかったり、
MTの改修は予算的にできなかったりなど様々な理由で手動でやらなくてはいけないことが多々あります。
不思議ですね！

メリット4:静的サイトジェネレータ「Phest」導入のメリット5であげたメリットも使えます

ヘッダ、フッタをincludeは当然できます！
本番ビルド時には相対パスを絶対パスに変換、などもお手のものです。
詳しくは静的サイトジェネレータ「Phest」導入のメリット5で見てくださいね！

既存サイトにPhestを組み込む際の導入手順

手順1:config.yml

/mysite/source/内にあるconfig.ymlを編集します。
buildclearを0にしてください。
1にすると、/mysite/output/local/フォルダの中身をビルドのたびに削除してしまうので、今回は不向きです。

手順2:既存サイトのファイルを、/mysite/output/local/にすべて格納する

図でいうと青いファイルです。
htmlファイルだけでなく、画像やcss、jsなどもすべて移しましょう。
画像は重いので、必要なものだけ移せるといいです。

手順3:編集するファイルを/mysite/output/local/から/mysite/source/content/にコピーする

htmlファイルやcssファイルなど、変更予定のあるファイルを/mysite/source/content/にコピペしましょう。
後でもその都度対応できるので、その時にわかっているものだけでいいです。

手順4:パスを変更する

ちょっとここ面倒です！！が、乗り切りましょう。
元から相対パスなら変更する必要ないです。

絶対パスの部分を{$_top}に置き換えてください。
この「{$_top}」タグを使うと、階層に応じて自動でトップフォルダからの相対パスが入ります。

※タグを使う場合は「.tpl」ファイルである必要があるので、「.html」ファイルの拡張子を「.tpl」に変更しましょう。
※元のパスが/からのパスだった場合、{local}{$_top}{/local}というように記述すると「local」でビルドした時は相対パス、「production」でビルドした時は/からのパスになるのでおすすめです。

これで準備完了です！！
/mysite/source/content/内にあるファイルを編集したり、新たにファイルを追加したりして「local」でビルドすると、/mysite/output/local/に吐き出されます。
よってローカル環境で、変更のあるファイルだけを一箇所にまとめた状態で、リニューアルや更新の作業ができます！！
すぐにプレビューできるので、嬉しいですね。

まとめ

一番大きかったのが、既存ファイルとは別に変更するファイルを管理できることで、
反映ファイルを極力少なく…ルールをわかりやすく…メモを取りながら…という大きな不安要素を蹴り飛ばしてマークアップに集中できたことです。
その作業にいかに集中できるか、という環境を作ることはとても大事ですね。

それなりに癖もあり、出力ファイルがどうなるのかも理解してないとリスクが高くなったりしますが、
静的サイトジェネレーターを運用で導入するという負担の下げ方もある、ということを知ってもらえたらと思います。