WordPress 4.7.3のsecurity updateは適用した版と公開中の操作を分けて確認する

WordPress 4.7.3はsecurity releaseです。4.7.2以前に影響する六つのsecurity issueと、4.7系の39件のmaintenance fixが含まれます。対象のsiteでは、更新の通知を見たか、自動更新が始まったらしいかでは判断しません。実際に4.7.3が適用されたことを確認し、そのあとで利用者が使う画面と、管理者が行う操作を分けて確かめます。

更新を急ぐことと、確認を省くことは別です。security releaseでは、問題の説明を読んで自分のsiteに当てはまるかを推測するより、公式が対象とする版を確認し、戻す手段を確保して適用する方が先になります。一方で、管理画面の更新画面が完了を示しても、画像、問い合わせ、投稿保存まで以前どおりに使えるとは限りません。版の確認と業務の確認を一組にします。

WordPress 4.7.3は使っている機能だけでは判断しない

WordPress 4.7.3の公式発表は、4.7.2以前に影響する問題として、media file metadata、redirect URLの検証、plugin削除、YouTube embedのvideo URL、taxonomy term名、Press Thisを扱う処理を案内しています。cross-site scriptingやcross-site request forgeryに関する修正も含まれます。

ここで、Press Thisを使わない、YouTube videoを貼らない、pluginを削除する予定がないから更新しなくてよい、と決めるのは早すぎます。WordPress本体は、公開page、media library、管理画面、theme、pluginが同じ土台の上で動きます。個別の問題を自分のsiteで再現して安全性を判断するのではなく、対象の版を使っているなら更新を先にします。

ただし、security issueを広く説明しても、siteの確認範囲は決まりません。公開している情報を読むためのpage、連絡を受けるform、担当者が内容を更新する管理画面を、事業への影響が大きい順に選びます。更新する作業と、何を守るために確認するかを分けると、慌てて無関係な設定まで変更せずに済みます。

自動更新の通知と適用済みの確認を混同しない

公式発表は、automatic background updateに対応するsiteでは、4.7.3への更新が始まることも案内しています。これは更新を早く行う助けになります。しかし、siteごとにautomatic background updateが使えるか、実際にその時点で完了したかは、通知文だけからは分かりません。

最初に管理画面へ入り、WordPressのversionを確認します。4.7.3なら、更新した日時と確認した人を記録します。4.7.2以前なら、更新を実行できる人、backupの場所、復旧の判断をする人を確かめてから手動で更新します。hostingから届くmailや管理画面のnoticeは判断材料になりますが、更新済みの証明の代わりにはしません。

説明用の仮例として、会社案内、サービスpage、問い合わせformをWordPressで公開しているsiteを考えます。制作を頼んだ会社が保守しており、site側の担当者は更新完了のmailを受け取ったとします。この場合、mailだけを転送して終わりにはしません。担当者または保守会社が管理画面で4.7.3を確認し、確認した時刻を残します。そのあと、公開側の確認を誰が行うかを決めます。

保守を外部へ頼む場合も、更新する権限と確認する責任を一人へ曖昧に集めない方がよいでしょう。技術担当はversion、backup、theme、pluginを確認できます。事業側は、料金、営業時間、問い合わせ先、申込みの案内が公開画面で正しいかを確認できます。どちらかだけでは、site全体の確認になりません。

更新を見送る必要がある事情があれば、理由と実施する時刻を残します。「互換性が心配なので後で行う」だけでは、いつ誰が対応するかが決まりません。backupを取れない、管理者accountが不明、公開中の業務へ影響が大きいといった事情は、更新を放置する理由ではなく、先に解決する作業として扱います。

公開pageは利用者の入口から確認する

versionの確認を終えたら、loginしていないbrowserで公開siteを開きます。管理者として表示される画面だけでは、一般の利用者が読む本文、menu、image、link先を確認できないからです。top pageが開けば十分ではありません。siteの目的に直結する入口を選び、操作が最後まで進むかを見ます。

たとえば、問い合わせを受けるsiteなら、サービスpageから問い合わせpageへ移動し、入力欄、必須項目の案内、送信後の表示、受信先までを確認します。送信testは実際の依頼と混ざらない内容にし、送った時刻と受信した結果を残します。formが表示されることと、mailが担当者へ届くことは別の確認です。

画像を使うsiteなら、top pageだけでなく、写真を掲載した記事や資料pageを開きます。表示できることを確認したら、管理画面で既存の公開pageを書き換えず、下書きを一つ開きます。画像を選択できるか、本文を保存できるかを見ます。testのために公開中の画像を消したり、料金や案内を書き換えたりする必要はありません。影響を出さない下書きで操作を確かめます。

mail、予約、外部serviceとの連携のように、確認結果がすぐ返らない機能もあります。その場合は、更新直後に終わらせず、いつ誰が結果を見るかを決めます。たとえば夜間に動く予約投稿は、指定時刻のあとに公開pageを開きます。確認できていないものを「問題なし」と書かず、未確認として残します。

問題が出たときは追加の変更を止める

更新後に表示の崩れ、formの送信失敗、管理画面の操作不能を見つけたら、すぐに別のplugin更新やCSSの修正を重ねません。変更を増やすほど、4.7.3の更新、theme、plugin、serverのどれが関係するかを追いにくくなるためです。

最初に残すのは、問題が出たURL、操作順、時刻、表示されたmessageです。画面が白い、送れない、とだけ伝えても、原因を確認する人は再現できません。たとえば問い合わせformなら、どのpageから開いたか、どの項目を入れたか、送信後の画面がどうなったか、受信mailが届いたかを分けます。公開pageなら、本文、画像、menu、linkのどれが読めないかを記録します。

次に、更新前に確認したbackupと復旧手順を見ます。戻す判断は、表示だけで決めず、利用者が連絡や申込みをできないか、管理者が必要な情報を更新できないかで決めます。作業を委託していても、domain、hosting、WordPress管理者、backupの保存先をsite側で把握していなければ、緊急時に判断が遅れます。更新作業を任せることと、戻せる状態を持つことは別です。

WordPress 4.7.3の最初の確認は、管理画面のversionを見て、公開siteで最も大事な入口を一つ通すことです。そこから画像、投稿保存、時間差で動く機能へ確認を広げます。更新済みという表示だけで完了にせず、使い続けられる状態まで確かめます。