WordPress 4.6のstreamlined updatesは画面を移動しなくても更新後の確認を省かない

WordPress 4.6では、pluginとthemeの更新、install、deleteの途中でも、管理画面の同じpageにとどまれます。作業中の画面遷移が減ることは便利です。しかし、更新buttonを押したあとに同じ画面が見えていることと、公開siteが正しく動くことは別です。

4.6のstreamlined updatesは、Shiny Updatesをpluginとthemeへ広げるものです。更新処理の結果やerrorを管理画面で確認しやすくなります。ところが、themeのtemplate、pluginのform、外部serviceとの通信、画像、cacheまで、その画面だけで確認できるわけではありません。更新後の確認対象を、管理画面と公開siteで分けます。

更新作業が短く見えるほど、確認を省きやすくなります。plugin一覧へ戻されないので、次の更新buttonをすぐ押せるからです。しかし、複数の変更を続けて入れたあとにformが止まれば、どの更新が影響したかを追う時間が増えます。画面遷移が減ったことを、更新の責任が減ったことと取り違えません。

更新画面の成功表示と公開siteの状態を分ける

更新後に見るものは、versionだけではありません。

説明用の仮例として、contact form pluginを更新する場合を考えます。更新画面に成功表示が出ても、送信buttonを押したあとに通知mailが届かなければ、問い合わせを受けられません。管理画面のplugin一覧、公開form、送信後の通知を別の確認項目にします。

formの確認は、入力欄が表示されるかだけでは足りません。必須項目を入れて送信できるか、送信後の画面に案内が出るか、受ける側のmailboxに通知が届くかを順に見ます。返信先を入力する欄があるなら、通知mailの返信先も確認します。更新前に届いていたmailが更新後も同じように届くかは、公開formを開かなければ分かりません。

themeを更新する場合は、トップpageだけを確認して終わりにしません。記事page、固定page、archive、検索結果、404 pageのように、別のtemplateを使う画面を開きます。headerやfooterのlink、画像、navigation、問い合わせへの導線も確認します。トップpageが正常でも、個別記事でsidebarが崩れる、archiveで見出しが出ないといった問題は別に起こります。

外部serviceを使うpluginなら、管理画面の設定が残っているかも見ます。アクセス解析、mail送信、地図、予約、決済などは、pluginが有効になっているだけでは確認できません。外部へ実際の注文を送るtestが難しい場合は、少なくとも設定画面、接続状態、error表示、公開画面の入力までを分けて確認します。できなかった確認は、更新完了と混ぜずに記録します。

cacheを使っているsiteでは、更新後に以前の画面が表示されることがあります。管理画面で更新が成功しても、公開URLで古いCSSやtemplateが残っていれば、確認した画面が最新とは限りません。更新後にcacheをどう扱うか、どのURLを開き直すかを決めます。見えている画面と更新したfileの状態を同じものと決めつけません。

同じ画面で更新できても変更単位を混ぜない

更新操作が軽くなると、複数のpluginやthemeを続けて更新しやすくなります。それでも、問題が出たときに原因を追えるよう、変更単位を決めます。緊急のsecurity updateと、見た目を変えるtheme更新と、使っていないpluginを消す作業は、同じ手順で一度に処理するものではありません。更新の理由と戻す必要がある場合の影響を分けます。

1. 更新するpluginまたはthemeと現在のversionを記録する。
2. backupの保管先と戻す判断を確認する。
3. 一つ更新してから、管理画面と公開siteを確認する。
4. 問題がなければ次の対象へ進む。
5. 更新日時、対象、確認結果、戻した場合の理由を残す。

更新前の記録には、対象名とversionだけでなく、確認するURLと操作を入れます。contact form pluginならform送信、gallery pluginなら画像一覧、themeなら主要templateの表示というように、更新対象ごとに確認を決めます。どの画面を見るかが決まっていなければ、更新後に何が元と違うかを比較できません。

4.6のrelease candidateでは、更新処理についてfailure message、error handling、custom update notificationの後方互換、JavaScript eventの修正も案内されています。更新画面へ独自の通知やJavaScriptを加えているthemeまたはpluginは、成功時だけでなくerror時もtestします。更新に失敗したとき、画面に何が出るか、再試行する前に何を確認するか、途中で止めた場合にsiteが読めるかをtest siteで確認します。

更新後に問題を見つけたときは、その場で別のpluginを更新して解決を試しません。まず、何を更新した直後に、どのURLで、どの操作ができなくなったかを記録します。次に、戻す対象とbackupの状態を確認します。原因が分からないまま複数の変更を重ねると、復旧しても何が直ったかが分かりません。更新を進める判断と、止める判断を別に持ちます。

更新の実行と復旧判断を分ける

外部の保守担当者が更新を実行できます。しかし、backupをどこに置くか、公開siteに不具合が出たとき誰が戻すか、更新を止める判断を誰がするかは、siteを所有する側が把握します。同じ画面にとどまる操作性は、復旧の責任を小さくしません。作業を依頼している間に連絡が取れない場合、誰が公開siteを止めるか、誰が問い合わせ対応をするかも決めます。

保守担当者へ頼むときは、更新対象、更新前version、実行する時間、backupの保管先、確認URL、確認操作、問題が出たときの連絡先を渡します。保守担当者は更新処理と管理画面、公開画面を確認します。siteを所有する側は、問い合わせ、予約、販売など、止められない機能の優先順位を確認します。更新後に表示が少し変わったことと、受注を止める不具合を同じ重さで扱いません。

最初の一手は、更新したい対象を一つだけ選び、更新前version、確認するURL、確認操作、backupの保管先、戻す担当を一枚に書くことです。更新後は、更新画面、管理画面、公開site、formまたは外部連携を順に確認します。確認できる状態を作ってから更新します。streamlined updatesは更新buttonを押す手間を減らしますが、siteを使い続けられるかを確かめる手間までなくしません。