PHPはWordPressをサーバー上で動かす実行環境です。古い版を放置すればセキュリティ修正が終わり、新しいテーマやプラグインが対応しなくなります。一方で準備せずに切り替えると、公開画面だけでなくフォームや管理画面が止まる場合があります。更新は版の選択と互換性確認を一つの変更として扱います。

サポート期限から更新の優先度を決める

PHPの各リリース系列には、通常の修正期間と重大なセキュリティ修正だけの期間があり、その後はサポート終了になります。現在の対応系列と期限はPHP公式で確認します。レンタルサーバーが提供する版も確認し、終了済みの版なら先送りせず更新計画を作ります。固定した「最新版」という記事情報だけで判断しません。

WordPress公式の推奨環境も確認しますが、推奨版へ一度で上げることだけが目的ではありません。現在のサイトが動く対応版を選び、次の更新を続けられる状態にすることが目的です。サーバー側の提供終了日が決まっている場合は、検証・修正・本番反映に必要な期間から社内期限を逆算します。

適用範囲と現在の構成を記録する

現在のPHP版はサーバー管理画面とWordPressのサイトヘルスで確認できます。WordPress本体・テーマ・プラグインの版も同時に記録します。独自テーマや制作会社が追加したコード、フォームや外部APIも対象です。更新履歴が止まった部品は、対応と表示されていなくても検証が必要です。

サーバーによってPHPの設定範囲は契約全体・ドメイン・ディレクトリなどで異なります。一つのサイトを変える操作が別サイトへ及ぶかを先に確認します。cronやコマンド実行だけ別のPHPを使う構成もあります。公開ページが新しい版でも、定期処理が古い版のままという状態を残さないよう実行経路を整理します。

戻せる条件を作ってから検証する

更新前にWordPressファイルとデータベースを同じ時点で保存します。サーバーの自動バックアップがあっても、対象・保持期間・復元方法を確認します。PHPを元の版へ戻せる期間も事業者の仕様で確認します。旧版提供が終了する変更では、単純な切り戻しができないため修正版の準備が重要です。

検証環境は本番と同じテーマ・プラグイン・主要データを使います。ただし個人情報を無条件に複製せず、必要に応じて置換します。PHPだけを先に変更し、WordPress本体や多数のプラグイン更新と同時にしません。問題が出たとき、PHP互換性によるものか別更新によるものかを判断できるようにします。

検証では画面より業務処理を通す

トップページに加え、投稿・固定ページ・検索・ログイン・記事保存・画像追加を確認します。問い合わせフォームは送信完了だけでなく、データ保存・管理者通知・自動返信まで試します。予約や会員機能があれば、業務担当者が実際の導線を操作します。見た目が同じでも裏側の処理だけ失敗することがあります。

公開画面へPHPエラーを表示せず、ログへ記録します。非推奨警告と処理停止を分け、原因となるテーマ・プラグイン・独自コードを特定します。単にエラー表示を消して合格にしません。修正版への更新・代替機能への変更・コード修正のどれで対応するかを決め、同じテストを再実行します。

本番反映は変更と確認を一組にする

利用が少ない時間を選ぶだけでなく、確認担当と戻す判断期限を決めます。反映直前に変更されたデータを含むバックアップを取り、現在値と変更先を記録します。PHPを切り替えたらキャッシュの影響を除き、検証と同じ業務導線を確認します。監視とエラーログも反映時刻から見ます。

問題が重大なら元の版へ戻し、ログと再現手順を保存します。軽微な警告を本番で直し続ける場合も、期限と担当を置きます。複数サイトへ適用される設定なら、対象すべてを確認します。変更画面で新しい版が選ばれていることではなく、業務機能と定期処理が新しい版で完了することを反映の合格条件にします。

更新できないサイトは期限付きで分離する

古いテーマや独自システムが対応せず、すぐ修正できない場合があります。そのサイトに合わせて全サイトを古いPHPへ固定すると、影響範囲が広がります。サイトごとに版を分けられる環境へ移すか、改修まで一時的に隔離します。分離先でもサポート終了版を無期限に使う計画にはしません。

例外運用には終了日・責任者・改修見積もりを残します。公開停止や静的化が可能な古いサイトなら、PHP自体を動かさない選択もあります。更新を妨げる部品を台帳へ記録すると、次回は通知が来てから慌てずに済みます。PHP更新の完成形は一度最新版へ変えることではなく、サポート期間内で継続的に検証と更新を行える状態です。