CMSと静的ファイル管理に関する考察。
公開日 : 2007-04-26 12:20:53
MTでサイト制作をしている時に「ゴミ」が出来てしまう件について調べているうちにBackgroundRebuilderにバグを見つけた。主にカテゴリー情報の保存についてのバグで、修正はだいたいできているので明日中にアップします。
何故この件が気になったかというと、サイト制作にCMSを使う場合、CMSごと納品してダイナミックパブリッシングで運用する時には問題ないが、「制作」のためだけにCMS使用して静的ファイルだけを納品する場合に問題になることがあるから。
制作過程で出来た「ゴミ」が一緒に納品されると困る。「このファイルは一体何?」
ゴミが出来るケースについては、先のエントリーでも書いた通りMTの例でいえば「DeleteFilesAtRebuild 1」をmt-config.cgiに指定してやることで基本的には回避出来る。
※ DeleteFilesAtRebuildについての参考情報
ところがやはりそれでも「ゴミ」が残るケースがある。
例えばエントリーのアーカイブマッピングにカテゴリーのパスが含まれている場合(例:%c/%i等)で、エントリーの主カテゴリーを変更して保存した場合。
- /cate1/example.html
- /cate2/example.html
また、同様にアーカイブマッピングにカテゴリーのパスが含まれている場合カテゴリーのbasenameを変更した時に旧フォルダが丸ごと残ってしまう。
- /old_cate/以下のファイル
- /new_cate/以下のファイル
詳しく調査したわけではないが、Blogの保存先を変更してもやはり残るのでないか。
アーカイブマッピングを修正した時にもファイルは残る。
また、先のエントリーに書いたように、エントリーの一覧からチェックしたエントリーを下書きに戻した際にもファイルは残る。一括編集画面でカテゴリーを変更した場合もファイルは残る。
現実的にはコマンドライン等から静的なHTMLを一括削除して再構築をかけるというような処理を最終段階で行うことになる。CMSで管理していない静的なファイルが混在している場合等は結構面倒。また場合によっては画像の保存場所なんかもぐちゃぐちゃになってしまう。
最初の設計が大切でディレクトリ構成なんかをきちんと固めてから作ろう、ってのは建前としては正解ですが現実的にはそうもいかないし、何より「何のためのCMSなの?」と言われかねない。
CMS側でのアプローチとしては、やはり吐き出された「静的ファイル」や「画像」等の管理機能を持たせることだろう。
1ファイル1レコード、1つのオブジェクトと結びついたテーブルをデータベースに持っておいて、前回吐き出されたファイルを保持しておき保存先が変更されたら(あるいはステータスがDraftになったら)ファイルを削除もしくは移動するという方法があると思う。
ただ、現状の例えばMovable Typeでは難しいかもしれない。アーカイブマッピングやテンプレートの組み合わせが複雑で、一つのエントリーが一つのファイルとは限らないし。それでも例えば以下のような考え方はどうだろうか。
MT::Permalink(MT::Objectのサブクラス)
- permalink_id
- permalink_type (Entry, Category 又は Blog)
- permalink_record_id (permalink_typeに対応したオブジェクトのID)
- permalink_blog_id
- permalink_uri (現在あるいは次に構築される静的ファイルのuri)
- permalink_uri_old (前回構築された静的ファイルのuri)
- permalink_parent_type (Category 又は Blog)
- permalink_parent_id (permalink_parent_typeに対応したオブジェクトのID)
- permalink_template_id (構築に使用されたテンプレートのID)
- permalink_status (既に削除と書き出しを行ったかどうか)
- permalink_modified_on (データが更新されたタイムスタンプ)
- permalink_build_on (ファイルが最後に書き出されたタイムスタンプ)
BuildFile のタイミングとか、MT::FileMgrが利用されるタイミングなんか(※ここがまだ実はよく分かっていない)で更新されるとともに、カテゴリーのbasenameとかblogのパスが変更された際に更新されるイメージ。
BuildFileの時点で、permalink_uriにあたるファイルが書き出されたらpermalink_uri_oldが(存在していたら)削除されるとか(正確には新たに生成されたファイルでないかどうかチェックする必要があるけれども)。
あるいは、画像やcss, jsファイル等のすべてのファイルをDBで管理してしまえば削除や移動が可能になるかもしれない。その分DBが肥大化してしまうわけですが。
もっとも現実的なアプローチは、制作過程ではダイナミックパブリッシング、納品時点では静的ファイルベースという方法でしょうか。ダイナミックであっても実際は静的HTMLのようなアドレスで制作途中のレビューが出来、実際はファイルは生成されていない状態。これでサイトが完成した段階で静的HTMLファイルを生成する。
これであれば静的ファイルとの混在も可能だろうし、変更があっても柔軟に対処できるだろう。
まぁ、理想を言えばきりがない。すぐにできる対処として考えつくのは
- ステータスが下書きのエントリーの静的ファイルが残っていないかチェックして残っていれば削除する、あるいはステータスが下書きになったらファイルを削除する
- エントリー等の保存時に、Permalinkが変更になっていたら古いファイルを削除するあるいは移動してから再構築する
- カテゴリーのbasenameやブログのパスが変わっていたらリネームする
といったところ。いずれにしても(高価な商用製品についてはわからないが)ファイルをうまく管理出来るCMSを追求していきたいと思う。
追記：そないに難しく考えずにファイル構築の際にページの文字列まるごととアドレスをデータベースに保存してmod_rewriteで動的に処理させればよいような気が…
わりとすぐに出来そう…
※↑ていうか、ダイナミックパブリッシングのキャッシュのしくみということね。
