更新前に保存する情報
現在の各バージョン、PHP版、有料製品のライセンス、直接変更したファイルを記録します。DBとファイルの両方を取得し、管理画面を使わずに戻す経路を確認します。ECや会員サイトでは、復元中に失われる受注・登録を避けるため、書込み停止や差分回収を計画します。
検証環境を先に使う
本番のコピーには個人情報が含まれる場合があります。アクセス制限、検索への露出防止、決済・自動メールの停止を先に設定します。検証環境があるだけで安全とは限らず、本番とのPHP・拡張機能・キャッシュ構成の違いも記録します。
管理画面からの基本的な進め方
- 「ダッシュボード > 更新」で対象と内容を確認する。
- 各製品の変更履歴で前提条件と既知の問題を確認する。
- 依存関係に合う単位で更新し、完了表示まで待つ。
- 更新ごとに主要機能を確認し、変更前後の版を記録する。
- 必要な層のキャッシュを消し、未ログイン状態でも再確認する。
更新中の連打やブラウザーの再読み込みは避けます。時間がかかる場合はサーバー負荷と処理状況を確認し、同じ更新を重ねて実行しないでください。
動作確認は表示と送信を分ける
トップ、代表的な下層、記事、検索、管理画面の保存を確認します。フォームは入力エラー・送信成功・受信・自動返信まで確認し、画面の完了表示だけで判定しません。スマートフォンと主要ブラウザーも対象にし、決済やログイン連携があれば専用の検証手順を用意します。
不具合が起きた場合の戻し方
作業を止め、時刻、エラー、更新対象を保存します。直前の変更を検証環境で切り分け、旧版への切替かバックアップ復元かを判断します。DBスキーマが変わる製品は、ファイルだけを戻しても正常化しない場合があります。セキュリティ修正を取り消すなら、代替制限と再更新期限も決めます。
完了後に残す作業記録
対象・作業者・日時・結果・確認した機能・保留事項・復旧の有無を記録します。更新通知が消えたことより、業務機能が正常で再発時に追跡できることを完了条件にしましょう。
作業記録を使った判断例
更新前の版、変更履歴、取得したバックアップ、作業開始時刻を一行にまとめ、製品ごとに結果を追加します。例えば更新直後にフォームだけ失敗した場合、公開画面の確認が済んでいても作業完了にしません。通信結果、スパム判定、メール配送を調べ、原因が更新と関係するか検証します。検証環境では同じ入力と同じ操作を使い、本番との違いを記録します。外部サービスが本番ドメインだけ許可する場合など、検証先で確認できない機能は残ります。その項目は本番反映時の限定テストへ回し、関係者と確認時刻を合わせます。
更新を中止・復旧へ切り替える基準
重大機能が動かない、原因の特定に予定時間を超える、データ整合性に疑いがある、といった条件を事前に決めます。担当者の判断だけで予定外の改修を続けず、責任者に状況と選択肢を伝えます。DB復元で失われる更新がある場合は、その差分と業務影響を説明して判断します。
本体とプラグインのどちらを先に更新しますか？
製品の必須条件と依存関係に従います。ある製品の新しい版が先に本体更新を要求する一方、現在の製品が新本体に対応しない場合もあります。対応する組合せと切替手順を検証してください。
全て最新版なら確認は不要ですか？
不要にはなりません。対応表示は特定の構成での全機能を保証しません。利用者が行う操作とログを確認し、必要な業務が続けられることを確かめます。