WordPress 4.9.1でRSSを使うsiteは本文の更新とenclosureを分けて確認する

WordPress 4.9.1へ更新したsiteでRSSやAtom feedを使うなら、投稿本文が表示されることだけで終わらせず、添付fileへ進むURLとfeedの内容を分けて確認します。feedは記事を知らせる入口です。音声や動画のfileを受け取る人がいるなら、本文と添付fileの案内が食い違わないことも必要です。公開page、feed、fileの三つを同じ画面として扱いません。

WordPress.orgは11月29日、4.9.1でRSSとAtom feedのenclosure属性を適切にescapeするsecurity fixを案内しました。これはfeedを使うすべてのsiteで添付fileを用意すべきだという意味ではありません。RSSを配信しているなら、更新後にどの投稿がfeedへ出るか、fileを置くならどのURLへ進むかを確認する理由になります。

本文の公開とfeedの配信は別の入口である

投稿を公開すると、読者はsiteの一覧、記事URL、RSS readerなど異なる入口から内容を受け取ります。本文だけを直しても、feedに載る見出しや要約、添付fileへの案内が古ければ、読者は別の説明を読みます。RSSがあることと、更新の意味が正しく伝わることは別です。

仮に、音声の案内を記事と一緒に配信する場合を考えます。記事本文には内容、対象、再生方法、問い合わせ先を書きます。feedのenclosureが指すfileも、同じ内容を受け取れるURLにします。fileを差し替えたなら、本文の説明、file名、公開先、古いfileへのlinkを確認します。これは実在のpodcastではなく、確認する対象を分けるための仮例です。

添付fileを置く人と内容を承認する人を分ける

enclosureへ入るfileを制作会社がuploadできても、事業者が内容を確認しなくてよいわけではありません。録音、動画、資料の内容が古い、公開してはいけない情報を含む、link先の条件が変わった場合は、fileが正常に開いても配信を続けられません。fileの操作、内容の確認、公開の承認を分けます。

外部へ運用を頼む場合は、feedのURL、fileの保管先、更新するaccount、公開前に確認する人を残します。URLを知っているだけでは、fileを差し替えたり止めたりできません。委託先のaccountだけに元fileがあり、事業者が保管先を知らない状態も避けます。作業を頼むことと、配信内容の正本を渡すことは別です。

添付fileの形式や容量も確認します。音声や動画を配信するときは、readerで再生できるかだけでなく、利用者が通信量や保存先を判断できる案内を置きます。fileを軽くすることと、必要な内容を削ることを同じにしません。長い説明は本文へ置き、feedでは何が入っているfileかを分かるようにします。読者が取得してから内容を確かめるしかない状態を避けます。

複数の記事で同じfileを使う場合も、どの記事が正しい説明かを決めます。古い記事のenclosureを残したまま新しいfileへ差し替えると、読者はどの案内を信じればよいか分かりません。共通の資料を更新したなら、その資料を案内する記事、feed、download先を一覧にし、古い説明をどこまで残すかを決めます。fileを更新する仕事と、記事を更新する仕事を別の担当へ任せるなら、連絡する順番も決めます。

reader側に古い内容が残る場合もあります。その可能性を理由に、本文とfeedの更新を止めません。更新日時、変更内容、正しいURLを公開pageで示し、次に確認する人が判断できるようにします。配信の反映を待つ間に内容を何度も書き換えると、どの版を確認したのか分からなくなります。急ぎの訂正と通常の更新を分けます。

feedを止めるときも読者の入口を残す

RSSやAtom feedを使わなくする判断をした場合も、URLをすぐ消して終わりにしません。feed readerから来る人が読む公開page、過去の添付file、更新案内をどう扱うかを確認します。siteの機能を減らすことと、既に渡したURLを放置することは別です。必要なら本文へ更新先を案内し、引き継ぐ人がfeedの存在を把握できる記録を残します。

更新後は、管理画面の投稿一覧だけを見ません。公開した記事URLを開き、RSS readerまたはfeedのURLで同じ投稿を確認します。添付fileがあるなら、別のbrowserで開き、読者が取得できるかを見ます。site内のlink、feed、fileを同じ日に全部替える必要はありませんが、どこが最新の案内かを決めずに古いfileを残しません。

更新の記録にfileの役割を残す

feedのenclosureを使う場合、file名だけを記録しても役に立ちません。何の記事に付けたfileか、何を伝えるためのfileか、誰が差し替えるかを残します。記事を非公開にしたとき、fileを残す理由があるのか、feedから消えているかも確認します。古い記事だけを残し、読めないfileへ人を送る状態は避けます。

4.9.1のupdateはsecurity fixです。feedの確認を理由に適用を遅らせません。先にupdateし、更新後に公開page、feed、添付fileを順に見ます。不具合が出た場合は、WordPress本体、feedを作るplugin、fileの保管先、readerのどこで起きるのかを分けます。原因を決めずにfileを置き直すと、必要なURLまで変えてしまうことがあります。

最初の一手は、RSSへ出ている投稿を一件選び、記事URL、feedの案内、添付fileのURLを並べることです。WordPress 4.9.1の更新は、feedがあることを確認するだけでなく、読者がどの入口からも同じ内容へ進めるかを見る機会にします。