WordPress 4.8.2のsecurity updateは後回しにせず更新後に使う画面を確認する

WordPress 4.8.2はsecurity updateです。更新を別の改修とまとめて後回しにせず、まず適用する日と確認する人を決めます。更新後は、管理画面へ入れるかだけで終わらせません。公開中のpage、記事の編集、画像やlink、問い合わせの入口など、そのsiteで実際に使う画面を確かめます。更新する作業と、siteがこれまでどおり運用できることの確認を分けます。

WordPress.orgは、4.8.2を以前のversionに対するsecurity releaseとして公開し、直ちにupdateするよう案内しています。4.8.1以前には九つのsecurity issueがあり、4.8 seriesのmaintenance fixも六件含まれます。対応するautomatic background updateを使えるsiteでは、4.8.2への更新も始まっています。自動でupdateされた可能性があっても、実際にどのversionが動いているかと、公開画面が正常かは別に確かめます。

security updateと機能追加を同じ作業にしない

security updateを適用するとき、見た目の変更、new pluginの導入、themeの改修、記事の大量更新まで同じ時間に進めると、不具合が出たときに原因を分けにくくなります。今回はWordPress本体を4.8.2へ更新する作業として扱い、予定していた機能追加は別にします。急ぐべきことと、まとめて作業したいことを混ぜません。

説明用の仮例として、会社案内と問い合わせformをWordPressで運用するsiteを考えます。担当者は4.8.2を適用する前に、現在のversion、active theme、active plugin、直近のbackup、問い合わせを受けるmail addressを記録します。更新後にformが送れない場合、WordPress本体の更新なのか、同じ時間に替えたpluginやmail設定なのかを調べるためです。記録は、更新を遅らせる理由ではなく、問題が出たときに戻るための準備です。

WordPress.orgの案内には、oEmbed discovery、visual editor、fileを展開する処理、plugin editor、Customizer、link modalなどに関するsecurity issueが含まれます。すべてのsiteがこれらを同じように使っているとは限りません。しかし、使っていない画面だけを理由にsecurity updateを不要と決めません。siteが使う範囲を確認することと、WordPress本体を最新のsecurity releaseへ上げる判断を分けます。

今回の案内では、$wpdb->prepare()に関するissueについて、WordPress core自体が直接vulnerableではない一方、pluginやthemeが意図せずvulnerabilityを作らないようhardeningを加えたと説明されています。この説明を、すべてのpluginとthemeが安全だという保証には読み替えません。本体の更新、pluginとthemeの更新、独自codeの確認は別の作業です。

更新直後は実際の操作を順に確かめる

更新後に最初に確かめるのは、表示されたversionです。管理画面の更新画面だけでなく、更新が完了した記録と公開画面を確認します。自動更新だった場合も、連絡mailだけを根拠にせず、siteへ入って現在の状態を見ます。更新できたという記録と、読者がpageを開けることは別です。

次に、siteの役割に合わせて操作します。会社案内だけのsiteなら、top page、主な固定page、menu、画像を開きます。記事を更新するsiteなら、visual editorで下書きを一つ開き、保存して表示を確認します。問い合わせを受けるsiteなら、実際の送信を試せる範囲でformから送信し、完了画面、受信mail、送信先を確認します。通販や予約を扱うsiteなら、商品または予約の入口から、注文や受付を確定する前の画面までを確認します。

確認は、すべてのpageを手で読み直すためのものではありません。更新によって止まると事業に影響する操作を先に選びます。たとえば、営業時間を編集する人が毎週管理画面へ入るなら、その編集画面を確認します。外部articleへのlinkを多く使うsiteなら、linkを追加する画面と公開側のlinkを確認します。誰も使わない設定画面を順に開くより、日常の運用と読者の入口を優先します。

不具合を見つけたときは、すぐに本体のversionを戻すと決めません。どのpage、どの操作、どのaccountで起きたか、更新前後に何を替えたかを記録します。制作会社へ頼む場合は、表示の問題、編集の問題、mailの問題を分けて渡します。復旧の作業を委託しても、domain、hosting service、backup、WordPress管理者accountの所有者が不明では、判断が遅れます。

自動更新と手動更新の確認を分ける

automatic background updateに対応するsiteでは、管理者が操作する前にupdateが終わっていることがあります。これは確認を不要にする仕組みではありません。自動で替わったsiteも、version、公開画面、運用上重要な操作を確認します。自動更新を止めているsiteなら、誰が案内を受け、誰が適用を承認し、誰が更新後を確認するかを決めます。

更新通知を制作会社だけが受け、事業者側が知らない状態も避けます。security releaseの情報を受け取る人、hosting serviceへ入れる人、WordPressを更新する人、公開画面を確認する人、問い合わせを受ける人を対応させます。一人へすべてを集める必要はありませんが、連絡先が不明なままでは緊急時に動けません。

本体updateの前にbackupを取る場合も、fileを保存しただけで復旧できるとは決めません。何を保存したか、どこにあるか、誰が戻すか、戻したあと何を確認するかを決めます。backupは更新を永遠に先延ばしにする理由ではなく、必要なときに復旧を選べるようにするものです。

最初の一手は、現在のWordPress versionを確認し、4.8.2を適用する人と更新後の公開確認をする人を決めることです。そのうえで、siteで止められない操作を三つだけ書き出し、更新後に順に試します。security updateは、画面上のbuttonを押すことだけで完了しません。