WordPressのbeta版は本番へ入れずtest siteでthemeとpluginを確認する

WordPressのbeta版は、公開中のsiteへ入れません。test siteへ複製し、theme、plugin、問い合わせform、管理画面を確認します。新機能を早く試すことと、利用者が見るsiteを止めることは別です。

WordPress 4.5 Beta 1の公式案内は、beta版をproduction siteで動かさないよう案内し、test siteで試すことを勧めています。同版ではCustomizerのresponsive preview、theme logo support、selective refresh、image generationの変更などが示されています。

beta版を試す目的は、新機能を先に使うことではありません。正式版へ更新する前に、自分のsiteで壊れやすい場所を見つけることです。themeが独自のtemplateを使っている、pluginが投稿画面へ項目を追加している、問い合わせformが外部のmail設定へ依存しているという場合は、WordPress本体だけを空のsiteで試しても、本番の確認にはなりません。

本番siteをそのまま複製できない場合も、確認したい機能を小さく再現します。たとえば、同じthemeと主要pluginを入れ、代表的な記事、固定page、問い合わせformを一件ずつ置きます。すべてのcontentを持ち込むことが目的ではありません。本番で止まると困る操作を、test siteで同じ順に通せるようにすることが目的です。

本番siteとtest siteは同じ確認対象を持つ

test siteは、新しいWordPressを入れるためだけの空のsiteではありません。本番で使っているtheme、plugin、設定、代表的なcontentがそろって初めて、更新後に何が変わるかを確認できます。

本番のdomain、広告account、mail送信先をtest siteへそのままつなぐ必要はありません。test中の送信や計測が、本番の数字や問い合わせへ混ざらないように分けます。

特にformは、本番の問い合わせ先へ確認用の送信を流さないようにします。test siteから送った内容が顧客対応のmailboxへ届けば、担当者は本物の問い合わせと見分けにくくなります。送信先を確認用に分けるか、本文へtestであることを入れます。送信が成功したと表示されることと、受信先で確認できることは別なので、画面と受信側の両方を見ます。

広告やアクセス解析も同じです。本番用の計測IDをtest siteへ置くと、試したpageviewや操作が本番reportへ混ざります。beta版で表示を確かめたいだけなら、広告を実際に配信する必要はありません。何を送信し、何を送信しないかを分け、testの数字を事業の数字として読まないようにします。

試す順番を更新前から決める

1. 本番siteのWordPress version、theme、plugin一覧を保存する。
2. 別のURLか、外部から入れない環境へtest siteを作る。
3. 本番のthemeと必要なpluginを同じ状態へ置く。
4. beta版へ更新し、代表pageと管理画面を開く。
5. form、画像upload、投稿、menuを操作し、問題があれば再現手順を残す。

themeやpluginを自作している場合は、どのversionを試したかも記録します。beta版の表示が崩れたとき、WordPress本体、theme、plugin、設定のどれが変わったのかを分けて追えます。

問題が見つかったら、「表示が崩れた」とだけ残しません。どのURLを開いたか、どのaccountでloginしたか、どの操作をしたか、期待した結果と実際の結果、画面に出たmessageを記録します。themeを切り替えたら直るのか、特定pluginを止めたら直るのかを確認する場合も、本番siteではなくtest siteで行います。切り分けのために本番の機能を止めれば、調査と利用者への影響が混ざります。

画像の確認では、uploadできるかだけを見ません。記事へ入れた画像が必要なsizeで表示されるか、既存の画像が欠けないか、mobile幅で意図した位置に出るかを確認します。投稿画面の変更がある場合は、題名、本文、アイキャッチ、公開日時のように日常で使う項目も開きます。新機能を試す画面だけでなく、いつもの更新ができるかを見ます。

beta版の確認を本番更新の代わりにしない

beta版で問題が見つからなくても、正式版への更新で確認を省けるわけではありません。beta版は開発中のsoftwareであり、正式版まで変更されることがあります。testの目的は、公開siteを先に止めず、問題になる場所を見つけて備えることです。

正式版が出たときは、beta版で確認した結果をそのまま結論にせず、正式版のversion、更新内容、test siteの状態を改めて確認します。beta版で使ったthemeやpluginが、その後に更新されていれば条件も変わります。本番へ入れる前に、beta版で見つけた問題が残っているか、直ったか、新しい問題が出ていないかを同じ操作で見ます。

test siteを残す場合は、誰が更新し、どこまで本番とそろえるかも決めます。何年も前のpluginやcontentが残ったtest siteでは、現在の本番を確認できません。反対に、本番のデータを無条件でコピーし続ければ、問い合わせや利用者の情報を必要以上に持ち出します。test siteへ置く情報、更新する時期、使い終えたときの扱いを、運用として決めます。

外部の制作会社へ依頼するなら、本番更新の前にtest siteで何を確認したかを受け取ります。theme、plugin、form、画像、管理画面のどこを通し、問題があればどう直す予定かが分かれば、本番へ入れる判断をsite側でも確認できます。beta版を入れたという報告だけでは、公開siteが安全に更新できる根拠になりません。

最初の一手は、本番siteで最も重要な三つの操作を選ぶことです。たとえば問い合わせ、記事の閲覧、管理画面からの投稿です。その三つをtest siteでも同じ順序で試します。