WordPress 4.9.2のsecurity updateは適用前に音声と動画の表示場所を確かめる

WordPress 4.9.2は、後回しにせず更新します。ただし、更新する前に確認するのは管理画面の版だけではありません。site内で音声や動画をどこに出しているか、更新後に誰が公開画面を開くかを決めます。security updateを見送る理由にはなりませんが、更新の後に困る画面を先に絞れば、必要な確認を短くできます。

WordPress 4.9.2は1月16日に公開されたsecurity and maintenance releaseです。WordPressに含まれるMediaElementのFlash fallback fileでXSS vulnerabilityが見つかり、多くの用途で不要になったFlash fileがWordPressから削除されました。Firefoxで投稿を保存できなくなるJavaScript errorなど、ほかのbugも修正されています。 WordPress.org

更新を止める判断と確認を先にする判断を分ける

security updateの通知を見たとき、「問題が起きそうだから更新しない」と考えるのは危険です。今回のreleaseはWordPress 3.7以降のversionに向けたsecurity releaseで、公式はすぐに更新するよう勧めています。公開中のsiteを守るための更新と、更新後の動作を確かめる準備は、どちらかを選ぶものではありません。

先に確認するのは、更新作業そのものではなく、影響を見つける場所です。会社案内の文章だけを出しているsiteなら、トップpage、問い合わせform、主要な固定pageを開く順で足ります。音声や動画を埋め込んでいるsiteなら、その一覧を加えます。投稿本文、固定page、widget、商品説明のどこで使っているかにより、確認すべき画面は変わります。

ここでいう確認は、古いFlash fileを探して自分で消すことではありません。WordPress本体の変更に合わせ、読者が使う再生画面や問い合わせの入口が表示されるかを見ることです。管理画面でmedia libraryが開けても、公開pageのplayerや、その前後に置いた案内まで読めるとは限りません。

音声と動画は使うpageから確認する

音声や動画を置いたsiteでは、media fileを一括で数える前に、読者が実際に開くpageを三つほど選びます。たとえば、最新のnews記事、サービスを説明する固定page、古い記事の順です。新しく作ったpageだけを見ても、過去の埋め込み方やthemeの表示が同じとは限りません。

各pageでは、次の順で見ます。まずbrowserでpageを開き、本文が途中で切れずに表示されるかを確認します。次にplayerが出る場合は、再生を始められるか、音声や映像の周辺にある説明と問い合わせへのlinkが残っているかを見ます。最後に、管理画面で同じ投稿や固定pageを開き、保存や更新の操作を普段どおり進められるかを確かめます。

再生が必要なcontentでなければ、更新直後にmedia libraryの全fileを確認する必要はありません。逆に、講座、作品紹介、採用案内のように再生そのものが読者の判断に関わるpageは、公開後に優先して見ます。file形式やplayerの仕組みを知らなくても、読者が見たい内容へ進めるかを基準にすれば、確認の順序を決められます。

更新方法と公開確認の担当を分ける

WordPress.orgは、DashboardのUpdatesから「Update Now」を選ぶ方法を案内しています。また、background updateに対応したsiteでは自動的に更新を始める場合があります。自動で更新されたかどうかにかかわらず、誰が公開画面を確認するかは別に決めます。更新した通知が来た人と、本文や問い合わせを確認できる人が同じとは限りません。

外部へ作業を頼む場合は、「WordPress 4.9.2へ更新してほしい」だけで終えません。対象site、更新を始めてよい時間、確認するpage、問題が出たときの連絡先を渡します。制作側は本体、theme、pluginの関係を調べます。siteを運用する側は、古い動画を残すか、service pageの案内が正しいか、問い合わせを誰が受けるかを決めます。更新を頼む仕事と、公開内容を決める仕事を分けると、確認漏れが減ります。

更新後に問題を見つけたら、画面を戻す前にURL、操作、表示された内容を記録します。「動画が見られない」だけでは、どのpageの、どのbrowserで、player自体が出ないのか、再生できないのかが分かりません。更新直後に確認したpageと問題のpageを比べれば、制作側も調べる場所を絞れます。

確認が済んだpageも、確認した時刻と見た内容を残します。トップpageと問い合わせpageが開いたのか、音声や動画を使うpageで再生を試したのか、投稿の保存まで見たのかを分けて書きます。「更新後に問題なし」とだけ残すと、次に不具合が出たとき、何を確認済みだったか分かりません。確認した範囲を残すことは、すべての画面が永久に正常だと保証するためではなく、次に調べる順番を失わないためです。

最初に決めるのは、更新をするかどうかではありません。security updateを適用し、読者が使うpageを誰が確認するかです。音声や動画を使うsiteでは再生画面を加え、使わないsiteでは主な案内と問い合わせの入口に絞ります。更新の完了を管理画面の表示だけで判断せず、公開中のsiteで必要な操作ができることまで確認します。