WordPressのsecurity updateは管理画面の表示だけで終わらせず更新後のsiteを確認する

WordPressのsecurity updateは、管理画面に新しいversionが表示された時点で終わりではありません。更新後に公開page、問い合わせform、管理画面へ入り直し、必要なら元へ戻せる状態を確認します。更新buttonを押すことと、siteがそのまま使えることは別です。

WordPress 4.4.2の公式案内は、4.4.1以前に影響する二つのsecurity issueを修正し、すべての以前のversionから更新するよう案内しています。4.4.2では17件のbugも修正されています。自動background updateに対応するsiteでは、4.4.2へ更新が始まることも同じ案内で示されています。

更新した版と動くsiteを分けて見る

更新の成否は、次の二つに分けます。

自動更新が使われる場合も、この確認は省けません。自動でversionが変わることは、個別themeやpluginまで正しく動く保証ではないからです。

公開画面の確認では、トップpageだけを開いて終わらせません。よく見られる記事、固定page、画像を含むpage、問い合わせへの入口を開きます。themeが共通で読み込むheaderやfooterに問題が出れば、投稿本文が読めても全pageで同じ不具合が起きます。反対に、一部のtemplateやpluginでだけ起きる問題は、トップpageだけでは見つかりません。更新前に確認するURLを決めておけば、更新後に何を比べるかが分かります。

問い合わせformは、入力欄が表示されるかだけでは足りません。必要な項目を入力して送信し、送信後の画面と受信側のメールを確認します。送信が失敗しても画面に何も出ない場合や、送信完了と表示されても受信側に届かない場合があります。実際の顧客情報を使わず、確認用の内容で一件送って、誰が受信を確認したかを記録します。

更新前に戻す条件を用意する

security issueへの対応を先延ばしにしない一方で、公開中のsiteを無計画に止めないことも必要です。更新前にdatabaseとfileを戻せる状態へ置き、誰が戻すかを決めます。

backupは保存しただけでは戻せる状態か分かりません。どの日時のdatabaseとfileを組みにするか、保存先へ入れる人は誰か、問題が起きたときにどの手順で復元するかを確認します。古いbackupしかなく、更新後に作った投稿や問い合わせ記録が失われる場合もあります。戻すことを決める前に、失われる範囲と、更新したまま修正できる範囲を比べます。

更新前に確認するのは、WordPress本体だけではありません。使用中のtheme名、主要plugin、PHPやserverの環境が分からなければ、不具合が出てもどこから確認すべきかを絞れません。すべてのpluginを一度に更新する必要はありませんが、今回どこまでを変えたかは記録します。本体更新、plugin更新、theme修正を同じ日に重ねると、後から不具合の原因を分けにくくなります。

1. 更新するWordPressのversionと、更新日時を記録する。
2. databaseとWordPressのfileを、復元できる場所へ保存する。
3. 更新後に確認するpageとformを三つから五つに絞る。
4. 管理画面から更新し、versionを確認する。
5. loginして公開pageとformを操作し、問題があれば更新日時とerrorの表示を残す。

作業を外部へ頼む場合も、backupを置く場所、WordPressの管理者account、domainとserverの操作権限はsite側で確認します。更新の作業を頼むことと、復元できる情報を手放すことは別です。

外部へ依頼するときは、作業完了の報告に新しいversion番号だけを書かせません。更新日時、確認したURL、formの送受信結果、変更したpluginや設定、問題が出た場合の戻し方を受け取ります。これらが残っていれば、次の担当者も前回どこを確認したかを引き継げます。口頭で「問題ありません」と聞くだけでは、後から再確認できません。

すぐに戻す判断を曖昧にしない

更新後に本文が表示されない、loginできない、問い合わせを受けられない場合は、原因を調べながら公開siteを放置しません。記録した変更内容とbackupを使い、どの段階まで戻すかを判断します。

戻すかどうかは、画面に小さな崩れがあるだけで決めるものではありません。問い合わせを受けられない、管理者がloginできない、主要なページが開かない、誤った内容を表示するというように、事業や利用者に直接影響する問題を先に扱います。軽い表示の違いなら、影響するページを記録して修正できる場合があります。何が起きたら復元を優先するかを、更新前に決めておくと、問題が起きた場面で慌てて正常なデータまで戻すことを避けられます。

最初の一手は、現在のWordPress version、backupの保存先、更新後に開く三つのURL、formの送信先を一枚に記録することです。次のsecurity updateが出たとき、確認する人と順序を迷わずに済みます。

この記録は、更新作業の後に作る報告書ではなく、更新前に確認するための表です。先に空欄を用意しておけば、作業中に何を見落としているかも分かります。