サーバー会社からPHP更新のお知らせが来ても、WordPressの更新と何が違うのか分からないことがあります。PHPはサーバーで処理を動かす言語で、WordPress本体やテーマ、プラグインの多くがその上で動きます。サーバーの設定画面で版を選べても、サイト全体がその版に対応しているかは別に確かめる必要があります。
まず現在の構成を記録する
現在のPHP、WordPress本体、テーマ、プラグインの版を確認します。管理画面の情報だけで足りない場合は、保守担当やサーバー管理者へ依頼してください。独自に制作されたフォーム、外部の予約システム、定期実行するプログラムなども対象に加えます。トップページがWordPressでも、一部だけ古いPHPのプログラムが残ることがあります。
管理画面の版と、定期実行など別の実行経路で使う版が一致しない環境もあります。担当者は、公開ページ、管理画面、定期処理のそれぞれで何が動いているかを確認するとよいでしょう。一般の更新担当者が設定値を推測して変えるのではなく、分からない項目を調査対象として一覧に残します。
サポート状況と互換性を別に考える
PHP公式のサポート一覧では、各系統のサポート期間を確認できます。現在表示されているから今後も安全に使い続けられるとは限りません。一方、サポート中の版であれば、すべての古いプログラムがそのまま動くとも限りません。移行先を選ぶ際は、サポート状況とサイトの互換性を両方確認します。
期限は変わる可能性があるため、過去のブログ記事の数字だけで決めず、実施時に公式情報を確認してください。サーバー会社が独自の延長対応を案内している場合も、標準のサポートと同じ意味か、費用や対象は何かを読みます。延長策があっても、改修を進める時期を決めるための猶予として扱う方が計画しやすくなります。
テーマとプラグインの対応を調べる
各製品の配布元や更新履歴で、移行先のPHPへの対応を確認します。対応情報が古い、配布が終了している、独自修正が加わっている場合は追加調査が必要です。新しい版へ更新すればよい場合もあれば、代替機能への変更や独自コードの修正が必要な場合もあります。互換性チェックのツールだけで動作確認を完了させないようにします。
PHPマニュアルの付録から移行ガイドなどを参照できますが、技術的な差分の判断は担当者と行います。警告が出ることと、処理が停止することは影響が違います。公開画面に警告が見えなくても内部で記録されている場合があるため、検証時にはログを含めて確認する方針を立てます。
本番と近い環境で一通り操作する
検証用の環境を用意し、予定するPHPと必要な更新を適用します。検証環境にはアクセス制限を設け、顧客情報の扱いを整理してください。フォーム、検索、画像アップロード、記事保存、資料生成、定期処理など、実際の仕事で使う操作を試します。外部送信や注文が発生する操作は、安全な試験方法を用意したうえで行います。
検証結果はページの画像だけでなく、実行した操作と期待する結果で残します。送信完了と出ても受信できなければ、問い合わせ業務としては完了していません。定期処理がある場合は、その実行を待つか手動で安全に確かめる手順も必要です。通常の閲覧だけでは見えない仕事を確認表へ入れることが、PHP更新の準備で役立ちます。
戻せる条件と変更する順序を決める
サーバー会社の画面で旧版へ戻せる期間や条件を確かめ、ファイルとDBの復元方法も用意します。PHPを戻しても、同時に行ったプラグイン更新やデータ変換まで元に戻るとは限りません。必要な変更の順番、作業を止める条件、復元の担当者を決めておきます。
サーバー会社の提供終了日が迫ってから調査を始めると、改修案を比較する余地が少なくなります。改修して動的な機能を残す、使っていない機能を整理する、更新の少ない案内サイトをHTML化するなど、用途に応じた選択肢があります。PHP更新の費用だけで比較せず、今後の更新方法と保守の負担まで含めて考えましょう。
古い独自フォームが残る場合の例
WordPress本体は更新されていても、別のフォルダーに独自フォームが残っている場合を考えます。表側の入力画面だけでは、どのプログラムへ送信しているか分からないことがあります。フォームのURL、処理先、受付メール、保存データの所在を技術担当者に確認してもらいましょう。WordPressの対応情報だけでサイト全体の互換性を判断しない理由がここにあります。
検証では、通常入力だけでなく必須不足や形式の誤りを試します。エラーを出す経路だけで古い処理が動くこともあるためです。添付、文字変換、PDF生成などを使う場合は、必要な拡張機能や外部の実行処理も調べます。一般の担当者が技術名をすべて覚える必要はありませんが、普段どんな仕事に使っているかを漏らさず伝えることが役立ちます。
フォームを新しい仕組みへ置き換える場合は、入力項目と受付後の業務が変わらないか確かめます。古い仕組みが動かないからと、担当者へ相談せず項目を削ったり、個人情報の保存先を変えたりしないようにします。安全性、費用、操作、契約の条件を比較して選びます。PHP更新の調査が、運用全体を整理するきっかけになる場合もあります。
検証環境での確認は、本番と異なる部分を明記します。外部メールを止めているなら受信の確認は別途必要です。予約システムを試験用へつないだなら、本番の接続条件も公開時に確認します。「検証済み」という一言にまとめず、何をどの条件で試したかを残してください。未確認の経路があれば、公開後の確認担当と時刻を決めます。
切り替え当日の判断を用意する
作業開始前に、本番の必要なデータと設定を保全し、最新の状態から戻せるか確認します。検証で使った古いDBを、そのまま本番へ上書きする方法は避ける必要があります。検証後も本番に投稿や受付記録が増えている可能性があるためです。変更する対象と、触らないデータを担当者が明確にした手順で進めます。
PHPの切り替え後は、最初に公開側が取得できるかを見て、次に編集と業務機能を試します。重大な問題があれば中止する条件を共有しておきましょう。調査のために停止時間をどこまで延ばしてよいかは、技術担当だけで決められない場合があります。利用の多い時期や受付の代替方法も含め、事業側の判断者を決めておくことが重要です。
問題が出たときに旧版へ戻す場合も、戻した後の確認が必要です。設定が戻っても、同時に変えたファイルやデータが残っている場合があります。切り戻しの完了条件を、公開ページが開くことだけへ限定しないようにしてください。何を実行し、どこまで戻したかを記録して、次の調査に使える状態を残します。
更新後に一定時間を置いて動く定期処理は、その実行結果を確認してから作業範囲の完了を判断します。すぐ確認できない処理があるなら、残る確認事項として共有してください。時間が経ってから問題が出た場合も、版と作業記録があれば切り分けやすくなります。PHP更新は設定を一度変える行為ではなく、必要な仕事が継続するか確かめる工程です。
更新後は業務が続けられるか確認する
本番切り替え後は、公開ページ、編集、問い合わせ、定期処理を確認します。時間を置いてからしか動かない処理もあるため、作業直後と次回実行後で確認を分けます。版、変更内容、確認した範囲、未確認の項目を記録して、完了の範囲を曖昧にしないようにしましょう。
エルスタの保守・管理サポートでは、PHP更新への影響を調査し、必要な改修を確認して進めます。最初に必要なのはパスワードではなく、現在のURL、届いた通知、困っていることです。構成の調査を行ったうえで、更新だけで対応できるのか、別の改善が必要なのかを整理します。
