WordPress 4.7へ更新するときはテーマとプラグインの確認順を先に決める

WordPress 4.7へ更新するときは、新機能を試す前に、いま使っているテーマとプラグインで重要な操作を確認します。更新できた表示だけでは、公開サイト、投稿、フォーム、管理画面が以前と同じように動くかは分かりません。更新作業と動作確認は一組です。

WordPress 4.7には、Customizerの初期設定支援、video header、個人ごとの管理画面言語、REST APIのcontent endpointsなどが加わりました。全てのサイトが各機能を使うわけではありません。しかし、独自テーマやプラグインが既存の画面、hook、データへ触れているなら、使わないつもりの変更にも影響を受けることがあります。

更新する理由と、新機能を使う理由を一つにしません。securityや互換性のために本体を更新する作業と、video headerやREST APIを導入する作業では、確認する範囲が違います。更新後に表示が変わったとき、どちらの変更が原因か分からなければ、復旧にも時間がかかります。まず既存siteが以前と同じように使えることを確認し、新機能は別の日程と記録で試します。

themeやpluginの名前だけで影響を判断しないことも必要です。問い合わせform、予約、会員用page、外部のmail送信、画像の処理など、siteごとに止まると困る操作が違います。更新前に「このpluginは有効」と記録するだけでなく、そのpluginが何の操作を支えているかを書きます。問題が起きたときに、無関係なpluginまで止めずに確認するためです。

確認する順番を公開サイトの重要度で決める

説明用の仮例として、管理画面で投稿を更新し、問い合わせフォームで受信するサイトを考えます。最初にCustomizerの新機能を見るより、公開ページ、フォーム送信、受信、投稿更新を確認します。ここに問題があれば、新機能の設定を増やして原因を広げません。

更新前には、現在のWordPressの版、テーマ、プラグイン、主要な設定、確認するURLを書き出します。更新後に不具合が出た場合、何を更新し、どの画面が変わったかを追えるようにするためです。テーマやプラグインの修正を委託している場合も、この記録はサイト側で持ちます。

記録には、利用中のthemeが親themeか子themeか、独自に追加したpluginやcodeがあるかも残します。管理画面の一覧に同じようなpluginが並んでいても、実際には一つだけがform送信やheaderの出力に関わっていることがあります。制作会社が以前に追加したfileや、server側の設定が影響している場合もあります。分からない項目は推測で埋めず、未確認として残します。

更新する人と、公開を確認する人が別なら、確認表を渡す順番も決めます。更新した人が「完了」と伝えても、事業側が問い合わせの受信や商品pageの条件を確認していなければ、site全体の確認は終わりません。技術的な更新を任せることと、利用者へ見える案内の確認を任せることを分けます。

更新前の記録は復旧手順と混同しない

更新前の記録は、復旧作業そのものではありません。まず、更新前に何が動いていたかを残すためのものです。復旧する必要が出たとき、元の版を用意できても、どのページと操作を確認すれば戻ったと判断できるかが分からなければ、作業は終わりません。

確認表には、URLだけでなく、操作と期待する結果を書きます。たとえば、問い合わせページなら「入力して送信する」「完了画面が出る」「受信先へ届く」を分けます。投稿なら「下書きを保存する」「公開日時を指定する」「公開ページで画像と本文を読む」を分けます。同じ画面を開くだけでは、使えることを確かめられないからです。

この表は、作業者へ丸投げするためのものでもありません。公開を判断する側が、何を確認したか、どこが未確認かを把握するための記録です。確認できない項目があれば、更新完了ではなく、未確認として残します。

確認表を作るときは、操作を広く書きすぎません。「フォームを確認する」ではなく、代表pageで必須項目を入力し、送信し、完了表示を見て、受信先へ届くことまで分けます。「投稿を確認する」ではなく、下書きの保存、画像の追加、公開pageの表示を分けます。操作と期待する結果を一対にしておけば、途中で止まった場所を共有できます。

公開pageの確認では、ログイン中の画面だけを見ません。管理者として開くと見えるmenuやpluginの案内が、一般の利用者には見えない場合があります。ブラウザを新しく開き、公開URLから本文、画像、link先を確認します。headerやfooterの共通部分を直した更新なら、top pageだけでなく記事や固定pageも選びます。templateごとに出力が違うためです。

更新の確認と新機能を入れる作業を分ける

WordPress 4.7の新しい機能を使うなら、基本の更新確認が終わってから別の作業として始めます。たとえばvideo headerを追加する、Custom CSSを使う、REST APIを使う作業を、版の更新と同じ日にまとめると、表示が変わった理由を切り分けにくくなります。

確認項目は、機能名から選びません。サイトが止まると困る順に選びます。たとえば、問い合わせが主な入口ならフォーム送信と受信を先に置きます。更新を担当する人が確認結果を口頭で伝えるだけでは、後からどの確認が済んだか分かりません。URL、操作、確認日時、結果を一枚に残します。

更新直後に問題がなくても、時間を置いて予約投稿、メール、画像、検索などを確認する必要があります。これは更新時の表示だけでは、予定した時刻に動く処理や、外部から戻る結果まで確認できないためです。日をまたいで確認するものは、更新直後の表と分け、確認する日時を先に決めます。

更新後に確認する時刻を決めるときは、siteの実際の使われ方に合わせます。夜に予約投稿が動くなら、そのあとで公開pageを確認します。問い合わせmailを受けるなら、送信直後だけでなく、受信側で内容を読めるかを確認します。画像を追加するなら、管理画面の表示だけでなく、公開pageで大きさやlinkが崩れていないかを見ます。更新直後に見えない処理を、未確認のまま完了としません。

問題が出たときは、直前に行った確認へ戻ります。いつ、どのURLで、どの操作をし、何が表示されたかを残し、更新前の状態と比べます。いきなり本体、theme、pluginを何度も替えると、原因と結果の関係が分からなくなります。利用者が使う入口を守りながら、影響する場所を一つずつ絞ります。復旧のために戻す場合も、戻ったあとに同じ確認表で動作を確かめます。

更新確認の途中で問題が出たときは、さらに新しい設定を加えません。最初に、問題が出るURL、操作、時刻、表示を記録します。次に、更新前後で変えたものを確認します。テーマやプラグインを無差別に止める前に、確認表で重要な操作を守りながら、影響する範囲を絞ります。

最初の一手は、現在のサイトで毎日または毎週使う操作を五つ書き出し、更新後に同じ順番で確認することです。新機能を使うかどうかは、その確認が終わってから決めます。