WordPress 4.7.2のsecurity updateはREST APIを使うか迷わず復旧手順を決めて適用する

WordPress 4.7.2はsecurity releaseです。WordPress 4.7.1以前には複数のsecurity issueがあり、WordPressは全ての以前のversionからの更新を強く勧めています。REST APIを自作themeやpluginから直接呼んでいないsiteでも、更新を見送る理由にはなりません。先にbackupと復旧の方法を確かめ、更新後に公開pageと管理画面を確認して適用します。

security updateでは、更新を急ぐことと、何も確かめずにbuttonを押すことを混同しないでください。更新によって問題を減らすために、戻す必要が出た場合の手順、確認するURL、修正を頼む担当者を先に決めます。これは更新を遅らせるための準備ではなく、問題が起きたときに判断を止めないための準備です。

WordPress 4.7.2は一つの機能だけの修正ではない

WordPressの公式発表は、4.7.1以前に複数のsecurity issueがあると案内しています。Press Thisのtaxonomy termを割り当てる画面、unsafeなdataを渡したときのWP_Query、投稿一覧、REST API endpointに関する問題が含まれます。siteがPress Thisを使わない、独自のWP_Queryを書いていない、REST APIを意識していないという理由だけで、影響がないと決めつけません。

WordPress本体の機能は、theme、plugin、管理画面、公開側の処理とつながっています。REST API endpointを直接使わない通常のsiteでも、WordPress本体の更新対象から外れるわけではありません。個別の脆弱性を自分のsiteで再現して確認するより、公式のsecurity releaseを適用し、更新後にsiteが必要な動作を保っているかを確認する方を先にします。

説明用の仮例として、WordPressで会社案内、サービスpage、問い合わせformを公開しているsiteを考えます。制作会社が以前に作ったthemeとform pluginを使っていて、site担当者はREST APIを使った覚えがない場合でも、まずversionを確認します。次に、backupがどこにあり、復旧を誰へ頼めるかを確認します。そのうえで4.7.2へ更新し、top page、問い合わせpage、管理画面の投稿編集を見ます。

この確認で重要なのは、REST APIの言葉を理解したかではありません。公開しているsiteを、更新後にも利用者が使え、担当者が管理できる状態に戻せるかです。technicalな説明を読んで更新を保留するより、確認範囲を絞って適用します。

更新前に残すのはfileだけではない

更新前のbackupには、WordPressのfileだけでなくdatabaseのdataが必要です。投稿、固定page、設定、利用者、formの内容などはdatabaseに入る場合があります。fileをコピーしただけで、公開前の状態へ必ず戻せるとは限りません。hostingのbackupが何を含み、いつ作られ、誰が復元できるかを確認します。

また、復旧のためには内容だけでなく、復旧後に何を確かめるかが必要です。次の情報を一枚にまとめます。

1. 現在のWordPress versionと更新する日時。
2. backupの場所と、fileとdatabaseを含むかどうか。
3. hosting、domain、WordPressの管理画面へ入れる担当者。
4. 更新後に開く公開URLと、送信を試すform。
5. 問題が起きたときに修正を頼む連絡先と、元へ戻す判断をする人。

この五つがあれば、更新中に表示が崩れたときも、どの画面で何が起きたかを説明できます。「siteが見られない」だけでは、hostingの障害、themeの表示、pluginの送信、loginの権限のどれを調べるか決まりません。top pageが開かないのか、contact formを送れないのか、管理画面へ入れないのかを分けて残します。

外部へ保守を委託している場合は、作業を頼むことと、backupやaccountを見られることを別にします。制作会社が更新できても、domain、hosting、database backup、管理者accountをsite側で把握していなければ、委託先が変わったときに復旧を判断できません。security updateのたびに手探りで連絡先を探さないよう、所有と管理の情報を残します。

更新後の確認は公開側から始める

更新が終わったら、最初に管理画面だけを見て終わりにしません。loginしていないbrowserでtop pageを開き、主要なmenuをたどります。画像、stylesheet、JavaScriptが読み込まれ、本文とlinkが読めるかを見ます。次に問い合わせformがあるなら、test用の内容を送信し、完了画面と受信先を確認します。

投稿を更新するsiteでは、管理画面へloginし、下書きを一つ開きます。本文の編集、画像の選択、下書き保存を確認します。すでに公開している重要なpageを、確認のために書き換える必要はありません。公開済みの内容へ影響を出さない下書きを使い、編集画面が正常に動くかを見ます。

確認で問題を見つけたときは、原因を推測して本番のfileを直接書き換えません。更新前のbackupへ戻すか、themeまたはpluginの修正を待つかを、公開への影響と復旧の手順で判断します。security updateを適用したことと、問題が起きたときに無計画に変更を重ねることは別です。

最初の一手は、管理画面でWordPressのversionを確認し、backupの場所と復旧担当者を一行で書くことです。その情報を確認してから4.7.2を適用し、公開URLとformを順に開きます。