更新前に見る四つの条件
変更履歴、必要なPHP・WordPress版、既知の不具合、ライセンスを確認します。依存プラグインやアドオンがある場合は互換表も必要です。「最終更新が新しい」「インストール数が多い」だけでは、自社の構成での正常動作は保証されません。
バックアップはプラグインのファイルだけでは足りない
更新時に設定値やDBテーブルを変更する製品があります。DB、対象製品、テーマ、アップロードファイルなど、復旧に必要な一式を保存します。更新直前の受注や送信履歴が戻し作業で失われないように、作業時間と書込みの扱いも決めます。
更新と確認を小さく繰り返す
- 検証環境で、現在版の主要機能を確認する。
- 更新対象を一つ、または依存する一組に限定する。
- 更新し、エラーとバージョンを確認する。
- その製品が担当する機能と、関連する保存・送信を試す。
- 本番へ同じ手順で反映し、結果を記録する。
フォーム系プラグインの確認例
入力必須項目、確認画面があればその遷移、スパム対策、メール到達、添付ファイル、完了画面を確認します。テスト用データを使い、通知先にテストと分かる件名を付けます。見た目が同じでも、外部APIへの接続失敗がないか確認が必要です。
失敗したら追加変更を止める
管理画面へ入れるなら対象だけ停止します。入れない場合は、サーバー管理者が対象フォルダー名を一時変更するなどの復旧を検討します。ただしセキュリティ・会員制御・決済機能の停止は公開範囲や取引に影響するため、先にアクセス制限を判断します。停止で直っても、単独故障か組合せによる問題かを追加調査します。
旧版へ戻した後にも対応が必要
戻した版に脆弱性がある場合、復旧は暫定対応です。公開機能の制限、修正版の確認、代替製品の検討を行い、再更新の期限を設定します。バックアップから戻す操作も、本番で初めて試すことがないようにしておきましょう。
更新後のテスト表を作る例
フォーム系なら「入力エラー」「認証成功」「メール到達」「添付」「完了遷移」、SEO系なら「タイトル」「canonical」「robots」「サイトマップ」、画像系なら「新規アップロード」「既存画像」「生成サイズ」を確認します。製品名ごとではなく、担当する業務機能ごとに試験を書くと、後継製品へ変更しても使えます。新しい版で設定項目が増えた場合は、以前の設定をそのまま引き継いでよいか確認します。既定値が変わる、外部通信が追加される、DB更新が必要になるといった変更は、単なる表示確認では分かりません。
複数サイトを管理する場合
同じ製品でもテーマやPHPの条件が違えば結果は異なります。代表サイトで確認したあと、構成が同じ範囲を特定し、各サイトで最小限の動作確認を行います。一つのサイトの成功を、全サイトの検証結果として記録しないでください。
更新に失敗した製品を入れ直してもよいですか？
削除時に設定やテーブルが消える製品があります。まずファイルの欠損か、互換性か、権限の問題かを調べ、アンインストールの動作を確認します。データを保全してから再配置の方法を選びます。
古い版をどこから取得すればよいですか？
公式配布元や正規の契約先から取得します。出所不明のZIPを復旧用に使わず、ライセンスと改変の有無を確認してください。