Movable Type ブログの物理的なディスク構造

著者がMovable Typeで保存を押すと、公開エンジンは訪問者のデータベースクエリを待つためにテキストを保管しなかった。サーバーのディスクに直接物理的なファイルを書き込み、同期的な静的生成をデフォルトの公開方法として頼っていた。

Movable Typeは静的ファイルを普遍的互換性のあるものと見なしていた。この環境では、すべてのアーカイブやインデックス、投稿ページをフラットなHTMLとしてレンダリングすることで、基本的なウェブサーバーが継続的なアプリケーションコードを実行しなくてもトラフィックを配信できるようにした。すべてのコンテンツ変更はストレージボリュームに直接的な物理的結果をもたらした。投稿を更新したり、誤字を削除したり、読者のコメントを受け取ったり、入ってきたリンクを記録したりすると、ソフトウェアは自動的に対応する静的ページを再生成した。

公開はデフォルトで同期的に実行されたため、ウェブインターフェースはファイルをオンデマンドで生成した。エントリーを投稿するユーザーやコメントを残す訪問者は、アプリケーションが応答を返す前にシステムがそのディスク出力を完了するのを待たなければならなかった。

同期的なファイル生成とFileInfoマッピングテーブル

再構築は日常的なサイト管理の中心にあった。それはデータベースレコードを公開ドキュメントに変換する中心的なメカニズムだった。管理者がサイト全体の公開ルールを調整したり、URLの構造を変更したり、動的テンプレートと静的テンプレートの組み合わせを変更したりするたびに、システムはフルリビルドを必要とした。

その再構築プロセス中、Movable Typeは内部のFileInfoテーブルを更新した。このデータベーステーブルは仮想URLを物理的なコンテンツパスに直接マッピングし、公開されたすべてのページがサーバー上の指定場所に配置されるようにした。マッピングがテンプレートと同期しないと、管理者がサイト全体で新しい再構築を開始するまでURLが壊れた。

データベースレコード／編集
 │
 ├──> 再構築エンジン実行
 │ ├──> FileInfoテーブル更新（仮想URLからコンテンツへのマッピング）
 │ └──> 物理的な.htmlファイルを同期的にディスクに書き込み
 │
 └──> サーバー設定ファイル出力（.htaccess、mtview.php）

静的なアプローチは、複数のアーカイブタイプを持つサイトが単一の投稿のために複数のファイルを書き込まなければならないことを意味した。エンジンは個々のエントリーページ、月次日付ベースのアーカイブ、カテゴリリスト、フロントページのインデックスを同時にレンダリングした。著者が古い見出しを変更すると、ソフトウェアはその投稿を参照しているすべてのインデックスとアーカイブページを探し出して書き換えなければならなかった。

TrackBackの検出とPingのワークフロー

アーキテクチャはブログ間通信を外部のJavaScriptフィードではなく、同じ静的再構築パイプラインに結びついた統合的なテンプレートコンポーネントとして扱った。Movable TypeのTrackBackメカニズムは異なるドメインの著者が関連するコメントを互いに通知することを可能にした。

自動検出を可能にするため、ドキュメントはサイト編集者に公開テンプレートに`$MTEntryTrackbackData$`タグを挿入するよう指示した。このタグはメインインデックス、カテゴリアーカイブ、日付ベースのアーカイブ、個々のエントリーアーカイブのテンプレートに配置されるべきだった。エンジンがそれらのページを再構築すると、外部のブログツールが投稿のTrackBackアドレスを検出するために必要なメタデータが埋め込まれた。

Pingを送信することは、公開インターフェース内で特定の手動ワークフローに従った:

1. 著者は別のブログ書きの投稿からユニークなTrackBack Ping URLを探し出してコピーした。
2. 著者はそのアドレスをMovable Typeのエントリーエディタ内の「URLs to Ping」フィールドに貼り付けた。
3. 著者はエントリーを保存し、それが静的構築シーケンスをトリガーした。
4. アプリケーションは、エントリーが静的ファイルを再構築し、ウェブ全体に通知を送信した後に「Pinging...」ステータス画面を表示した。

TrackBackを受信する場合は逆のプロセスが実行された。入ってくるネットワークpingがデータベースに登録され、公開エンジンが影響を受けるエントリーの静的HTMLページを書き直して、新しい外部引用がサイトに表示されるようにした。

コメントと通知の過負荷に対する防御的な制御

すべての公開送信がサーバーサイドのファイル操作をトリガーしたため、コメントとTrackBackの処理はインストールに操作的な負担をかけた。自動化されたスクリプトがブログを送信で溢れさせると、公開キューファイルが繰り返し再構築された。

Movable Typeはこの自動化された活動を調整するためコントロールを導入した。システム設定は管理者がスパムフィルターの積極性を調整したり、指定した日数後に自動的にスパムコメントを削除するようにソフトウェアを設定することを可能にした。

アイデンティティ検証のため、ソフトウェアのドキュメントはTypeKey認証を有効にすることを推奨した。管理者はTypeKey検証を有効にしてコメント投稿者の身元を確認し、新しいTypeKeyコメント投稿者の発言がサイト再構築をトリガーする前に手動でモデレートすることを選択できた。

その時代の主要なドキュメントは特定の操作上の変化を数値化していない。歴史的な記録は中間バージョン間の特定のデフォルト変更を保存しておらず、その期間のサーバー移行のコストも数値化していない。ドキュメントが確認しているのは技術的な緩和設計だ:同期静的書き込みを強制する前に送信をフィルタリングする。

動的公開が静的ルーツを保持した理由

何千ものHTMLファイルの書き込みに費やす時間を削減するため、Movable Typeは動的公開モードを導入した。テンプレートを動的レンダリングに切り替えても、ソフトウェアは静的ファイルから切り離されなかった。

動的モードで実行している場合でも、Movable Typeはまだ2つのファイルをサーバーディレクトリに静的に書き込んだ:`.htaccess`と`mtview.php`だ。`.htaccess`ファイルは入ってくるHTTPリクエストをインターセプトし、それをPHPレンダリングエンジン経由でルーティングし、`mtview.php`はその場でページを組み立てるために必要な環境をロードした。

動的モードは再構築コマンドを排除しなかった。Movable Typeはまだサイトの初期公開時や、管理者が公開設定、テンプレート割り当て、ディレクトリ構造を変更するたびに手動再構築を必要とした。エンジンは着信リクエストが解決されるべき場所を追跡するため、静的な構成と動的な構成の両方でFileInfoテーブルを維持した。

生き残ったサイトでの技術的な残滓の識別

移行されていないアーカイブの検査は、エンジンがその出力をどう組織化したかを明らかにする。静的生成は物理的なフォルダとファイルを作成したため、結果のサーバーパスは直接テンプレート構成を反映した。生のディレクトリ構造を調べる読者は、スタンドアロンのHTMLファイルが`.htaccess`や`mtview.php`のようなサーバー設定ファイルと並んで存在するのを見つけるだろう。

生き残ったアーカイブのテンプレートは、個々の投稿ページやカテゴリインデックス内に生の`$MTEntryTrackbackData$`タグやそのレンダリングされたメタデータブロックを保持していることが多い。これらのマーカーは、日付ベースのディレクトリ上の静的ファイル拡張子と組み合わせて、個人出版が一度に一つの再構築でディスクにフラットなファイルを書き込むことによって定義されていた時代を記録している。アーキビストのための開かれた技術的疑問は、これらの静的FileInfoマッピングが何十年ものサーバーアップグレード後もどれだけ無傷で残っているかだ。