公開期限プラグインとは、投稿ごとに日付を決めておき、その日時が来たら投稿のステータスやカテゴリを自動で変えるプラグインです。PublishPress Future(旧 Post Expirator)がよく知られていて、公開中の投稿を日付で下書きや非公開に変える、ゴミ箱へ移す、カテゴリを付け替える、といった動作を投稿にひも付けられます。日付が来たら状態を変える。それだけをやる道具で、それが要るなら十分に役に立ちます。
一方で「投稿に有効期限をつけたい」と探している人の中には、期限が来たら消したいのではなく、期限が来たら誰かに中身を見てほしい、という人が混ざっています。この記事では、その2つを、公開期限プラグインとコンテンツ更新管理(更新期限管理の側)を並べて整理します。作っている側が書く比較なので、どこが向いていてどこがそうでないかは、なるべく正直に。
なお、PublishPress Futureの細かい設定項目や版ごとの差はここでは扱いません。一般に知られている「日付で投稿の状態を変える」という役割の範囲で書きます。
重なっているところ
どちらも投稿に日付を持たせ、その日付を境に投稿の扱いを変えられます。公開中の投稿を下書きや非公開にできる、という点は重なる。どちらもWordPressの定期処理に乗って動くので、アクセスがほとんど無いサイトでは実行が遅れうる、という事情も似ています(コンテンツ更新管理はWP-CronWordPressが予約投稿や定期処理を動かす仕組み。サーバーの時計ではなく、誰かがサイトを開いたタイミングで動くため、アクセスの少ないサイトでは遅れることがある。の毎時処理で、判定は日単位。他のプラグインの実装はそれぞれのドキュメントを見てください)。
なので「終了日に非公開にしたい」という一点だけを見ると、どちらでもできる。違いはその前後にあります。
有効期限は「終わる日」、次回確認日は「見る日」

いちばん大きな違いは、日付の意味です。
公開期限プラグインの日付は、そのページの寿命が終わる日。来たら状態が変わり、それで役目を終える。キャンペーンの終了日や、イベントの開催日のように、終わりが最初から決まっているページに向いています。
コンテンツ更新管理の日付は「次回確認日」で、そのページの中身を人が見る日です。日付が近づくと担当者に通知が行き(14日前・7日前・1日前のように段階を複数持てる)、来たら担当者が中身を確認して「更新した」「変更不要」「対象外」のいずれかを登録する。承認者を立てていれば承認されるまで完了にならず、完了した日と更新頻度から次の確認日が自動で立ちます。3か月ごと、1年ごと、と回り続ける前提の設計で、終わりは想定していません。
つまり公開期限プラグインは「日付が来たら状態を変える」、更新期限管理は「日付が来たら人に確認させ、確認が終わったら次の日付を作る」。プラグインが動くのは日付が来た瞬間ではなく、その前後の人の作業を挟んだ全体です。
期限を過ぎたあとに起きること
公開期限プラグインでは、期限が来ると設定した状態変更が実行され、それが結果です。
コンテンツ更新管理でも、期限を過ぎたときの処理は選べます。投稿単位なら管理画面で警告のみ/下書きへ変更/非公開へ変更/指定URLへリダイレクトあるURLを開いたとき、別のURLへ自動で転送すること。ページを消す代わりに関連ページへ送ると、検索エンジンからの流入やブックマークを失いにくい。(301・302)。ただし既定は「何もしない」で、これは主機能ではなく、確認が滞ったときの保険という位置づけです。処理の内容も、投稿のステータスやリダイレクトまでで、本文やフィールドの値は書き換えない。
もう1つ、公開期限プラグインには無い挙動として「解除」があります。リダイレクトは、担当者が確認を終えると自動で解除されて元の表示に戻る。下書き・非公開にした投稿だけは自動では戻さず、「以前の公開状態へ戻す」を人が押します。「期限が来て隠した」ではなく「確認が終わるまで一時的にこう見せている」という設計で、この差が「有効期限」と「確認期限」の性格の違いをそのまま表しています。この処理の選び方は期限を過ぎた記事を下書き・非公開・リダイレクトにして戻す記事に詳しく書きました。
投稿より小さい単位と、確認した記録
公開期限プラグインは投稿を単位にします。コンテンツ更新管理は投稿のほかに、本文の中で専用ブロックで囲んだ範囲、ACFAdvanced Custom Fields。投稿に独自の入力欄(カスタムフィールド)を追加するプラグインの定番。無料版と有料のPro版がある。フィールド、カスタムフィールド投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。の4つを管理単位にしていて、1つの記事の中で「料金表は3か月ごと、注意事項は毎年」のように期限を分けられます。
それから記録。誰が担当で、いつ確認して、承認したのは誰で、通知はどこへ送ったか、が管理対象ごとの履歴に残ります。公開期限プラグインは日付で状態を変えることが仕事なので、「確認した人」「確認した記録」という概念がそもそもありません。求めていないものが無いだけで、欠点ではない。
終了日に消したいだけなら、公開期限プラグインで足りる

ここは自製品を勝たせない形で書きます。
キャンペーンページを終了日に非公開にしたい。それだけなら公開期限プラグインで足りますし、そのほうが軽い。コンテンツ更新管理は管理対象を作るたびに担当者・重要度・期限切れ処理が必須で、確認結果の登録という人の作業を前提にしています。「日付が来たら非公開」のためだけにこれを入れると、担当者は毎回「確認しました」を登録することになる。過剰です。
逆に、期限が来たら人に見てほしいページ——料金表、営業時間、製品仕様、法令関連の注意書き、採用条件のように、消すのではなく合っているかを確かめ続けるページ——には、公開期限プラグインの日付では足りません。状態を変えるだけで、確認する人も次の期限も記録も持たないからです。
同じサイトに両方入れることは考えられますが、同じ投稿の両方に日付を持たせるのは避けたほうがいい。コンテンツ更新管理の期限切れ処理は、実行前にすでに下書きや非公開になっていた投稿には手を出さず「処理不要」と記録するだけなので、別の仕組みが先に状態を変えていても壊れはしませんが、どちらが何をしたのか追いにくくなります。組み合わせて動かす検証もしていません。分けるなら、終了日が決まっている告知系の投稿タイプは公開期限プラグイン、定期的に見直す常設ページは更新期限管理、と投稿タイプやカテゴリで棲み分けるのが分かりやすいと思います。
更新期限管理という考え方の全体像——4つの管理単位、通知、期限を過ぎたときの処理、履歴——は公開して終わりにしないための記事にまとめています。
製品ページは コンテンツ更新管理 にあります。
