静的サイトで「記事を削除しても消えない」のはなぜか

1つめ: 削除を「サイトを作り直す合図」として拾えているか

この構成では、編集者が記事を保存すると、WordPressがそれを検知して「サイトを作り直してね」というフラグを立てます。書き出し担当のプログラムがそのフラグを見て、HTMLを生成し直します。

検知には、WordPressの save_post という仕組みを使うのが定石です。ただし素直に書くと、たいていこうなります。

add_action('save_post', function (int $post_id, \WP_Post $post, bool $update): void {
    if (wp_is_post_revision($post_id)) return;
    if (wp_is_post_autosave($post_id)) return;

    // ★ ここ
    if (!in_array($post->post_status, ['publish', 'future'], true)) return;

    update_option('site_rebuild_needed', time(), false);
    // …
}, 10, 3);

★の行は「公開中（publish）と予約投稿（future）以外は無視する」という意味です。下書きを保存するたびにサイト全体を作り直していたら無駄なので、条件としては妥当に見えます。

ところが、この1行が削除を取りこぼします。

WordPressで記事をゴミ箱に入れると、内部的には記事のステータスが trash に変わるという扱いになります。つまり「保存」の一種で、save_post は実行されます。

されますが、★で弾かれます。trash は publish でも future でもないからです。

結果、フラグが立たない。書き出しが走らない。サイトは何も変わらない。

しかも厄介なことに、追加と更新は完璧に動きます。だから通常の運用では気づけません。

2つめ: 配信先から実ファイルを消す仕組みがあるか

仮に1つめを解決しても、それだけでは足りません。

書き出したHTMLをストレージへ送る部分は、こういうコマンドを使うのが一般的です。

aws s3 sync "$EXPORT_DIR" "s3://${BUCKET}/" \
  --cache-control "public, max-age=60, s-maxage=60"

sync は「手元のフォルダとストレージの中身を同じ状態にする」コマンドです。ただしこのままでは「追加」と「上書き」しかしません。手元にないファイルがストレージに残っていても、消してくれません。

消したければ --delete を付けます。付ければ一行で解決します。

ただ、この構成では意図的に使っていません。

--delete は「手元にないものは向こうでも消す」という強い同期です。書き出し処理が何らかの理由で不完全だった場合、その不完全さがそのまま公開サイトに反映されます。極端な話、生成結果が0件なら公開サイトも空になります。

CMSと配信先が分離している構成では、書き出し側の異常を配信側へ波及させないという原則を優先すべきだと考えました。したがって同期は「追加・更新のみ」に限定しています。

安全側に倒した結果、削除は別途、明示的に実装する必要が出てきます。

削除を検知する

ゴミ箱と完全削除は別のできごとなので、検知点を2つ用意しました。

// 公開状態から外れたとき（ゴミ箱・下書き化を含む）
add_action('transition_post_status', function ($new_status, $old_status, $post): void {
    if ($old_status !== 'publish' || $new_status === 'publish') return;
    // …
}, 10, 3);

// 完全削除（ゴミ箱からの削除 / 直接削除）
add_action('before_delete_post', function ($post_id, $post = null): void {
    // …
}, 10, 2);

trashed_post ではなく transition_post_status を使ったのは、「公開 → 下書きに戻す」も公開面から消す必要があるからです。ゴミ箱だけを見ていると、下書きに戻したページが残ります。

完全削除に before_delete_post（削除の直前）を使っているのにも理由があります。deleted_post（削除後）では、もう投稿がデータベースに存在せず、URLを復元できません。消すべきURLが分からなければ消しようがないので、投稿が残っているうちに取得しておく必要があります。

「公開されていたときのURL」を復元する

ここに小さな罠があります。

WordPressで記事をゴミ箱に入れると、スラッグの末尾に __trashed が付きます。そのまま get_permalink() を呼ぶと、公開時とは違うURLが返ってきます。

function resolve_published_path(\WP_Post $post): string {
    $probe = clone $post;
    $probe->post_status = 'publish';
    $probe->post_name = preg_replace('/__trashed$/', '', (string) $post->post_name);

    $url = get_permalink($probe);
    // …
}

投稿オブジェクトを複製して「公開中」を被せ、__trashed を剥がしてからURLを解決します。下書きのプレビューURLを得るときによく使われる手ですが、削除にも同じ手が効きます。

ここを間違えると「存在しないURLを消しにいく」という無意味な処理になり、しかもエラーになりません。気づけないので、検証項目に必ず入れておくべきところです。

--delete は使わず、狙ったパスだけ消す

取得したURLは、いったんデータベースに記録しておきます。書き出しが成功した後で、記録されたパスだけを消します。

for _rel in $REMOVED_PATHS; do
  aws s3 rm "s3://${BUCKET}/${_rel}/index.html"
done

全体の --delete を使わないのが要点です。この方式なら、取りこぼしても既存ページを巻き込みません。書き出しが不完全でも、消えるのは「消せと明示的に記録されたページ」だけです。

前述の「書き出し側の異常を配信側へ波及させない」という原則を保ったまま、削除だけを成立させられます。

なお、ストレージから消してもCDNのキャッシュには残るため、そちらの削除もあわせて依頼します。ここは「見えてはいけないものが見えている」状態なので、有効期限切れを待たずに明示的に消しにいく価値があります。

部分ビルドをどう維持するか（設計上いちばん悩んだところ）

この構成の売りのひとつが部分ビルドです。記事を1本更新しても、サイト全体（約1600ファイル・4分）を作り直すのではなく、必要なページだけを数十秒で作り直します。

削除でもこれを維持したいのですが、素直にやると詰みます。

消した投稿のIDを再生成キューに積んでも、意味がありません。 書き出し処理は get_permalink() でURLを解決してページを取得しますが、その投稿はもう存在しないので、何も生成できません。

かといって毎回フルビルドに倒すと、部分ビルドという利点を捨てることになります。

ここで、書き出し処理の仕様を読み直しました。部分ビルドは「指定された投稿 + トップページ + その投稿タイプの一覧ページ + 同じ投稿タイプの公開済み記事すべて」を再生成する作りになっています。

最後の「同じ投稿タイプの記事すべて」が入っているのは、関連記事カードの存在が理由です。記事Aの詳細ページには記事B・C・Dのカードが並んでおり、そのカードにはタイトルやタグが焼き込まれています。記事Aだけ作り直しても、B・C・Dのページに残る「Aのカード」は古いままになります。

つまり部分ビルドの再生成範囲は、削除後に作り直すべき範囲とちょうど一致していました。

そこで、こうしました。

// 消した投稿と同じ投稿タイプで、"残っている"記事を1件だけキューに積む
$siblings = get_posts([
    'post_type'   => $post->post_type,
    'post_status' => 'publish',
    'numberposts' => 1,
    'exclude'     => [$post->ID],
    'fields'      => 'ids',
]);

if (!empty($siblings)) {
    queue_rebuild_post((int) $siblings[0]);
    update_option('site_rebuild_mode', 'single', false);
} else {
    // 兄弟が残っていない = 一覧が空になる。起点がないのでフルビルド
    update_option('site_rebuild_mode', 'full', false);
}

消えた記事の代わりに、残っている記事を起点にする。 これだけで、既存の部分ビルドの仕組みに一切手を入れずに削除へ対応できました。書き出し処理本体は無改修です。

今回いちばん気持ちよくハマったところでした。

揮発するコンテナとプラグインの置き場所

運用上の工夫をひとつ書いておきます。

この構成のWordPressはコンテナ上で動いています。コンテナは再起動のたびに中身がまっさらになるため、「プラグインを管理画面から有効化する」という運用が成立しません。再起動すると無効に戻ってしまいます。

そこで、今回のコードはmu-plugins（must-use plugins）に置きました。この場所のPHPファイルは有効化の操作なしに常時読み込まれます。有効・無効の状態をデータベースに持たないので、「起動のたびに有効化し直す」という手当てそのものが不要になります。

コンテナ環境でWordPressを動かすなら、素直にこちらを選ぶのが楽です。

運用操作も管理画面に載せる

あわせて、管理画面に「静的サイト配信」という画面を追加しました。

• 最終反映の時刻
• 未反映の変更があるかどうか
• 次に作り直される範囲（差分 / 全体）
• 公開面から削除される予定のページ
• 書き出し担当プログラムが生きているか
• 【差分を今すぐ反映】【サイト全体を再生成】ボタン

前回の記事で「コンテンツ更新の属人化を解消した」と書きました。同じ考え方を運用操作にも適用した形です。コンテンツだけ誰でも触れて、配信操作はエンジニアしか実行できないのでは、属人化が場所を変えて残るだけになります。

通常は保存した時点で自動的に反映されるので、この画面を使う場面はほとんどありません。ただ「反映されているか」が見えること自体に価値がありました。