タグ: PHP、PHP7、PHP8、PHP8、互換性、以降、Wordpress

WordPressの推奨環境がPHP8に！　互換性エラーを防ぐためのチェックリストと実践的移行ノウハウ

最近、Webサイト構築の定番である WordPress が、推奨する PHP のバージョンを上げつつあります。これを受けて「PHP 7 から PHP 8 に切り替えよう」と検討された方も多いと思います。
ただし、安易に「バージョン切り替え＝完了」ではなく、実装しているプラグインやテーマ、カスタマイズ部分によっては、PHP 8 への切り替えでエラーが出たり画面が崩れたりするケースがあります。
本記事では「私が実際に PHP 8 へアップグレードしようとしたら、実装の一部が対応しておらず調査・対策した」経験を元に、ノウハウを整理しました。たとえ実績の少ない開発でも、手順を整えておけば安心です。

1．主な作業の流れ

No.工程名主な目的・内容チェックポイント
2作業方針の確認作業範囲と進め方を明確化。対象環境や切替手順を決定。ステージング環境／バックアップの準備
3PHP7と8の差分確認主な仕様変更・互換性リスクを整理。影響範囲を洗い出す／公式移行ガイド参照
4チェック方法の確立テスト観点・確認手順を定義。どのツール・方法で検証するか決定
5チェックの実施実装・テーマ・プラグインを実際に検証。エラーログ・動作確認・機能テスト
6対処の実施問題箇所を修正・更新。プラグイン更新・コード修正・代替策検討
6最終確認全体の再確認と安定性テスト。表示・機能・ログ・速度の最終チェック

以下では、この流れに沿って各ステップを詳しく解説していきます。

２．作業方針：まず確認すべきこと

最初に、「どこを対象に、どのように切り替えるか」を決めることが非常に重要です。以下のような観点で作業方針を固めましょう。

  • 作業範囲の特定：運営中のサイト全体を対象にするか、一部（テスト環境・ステージング）から行うか。
  • 切り替え手法の確立：レンタルサーバーなどでは GUI で PHP バージョン切替が可能な場合もあります。ただし、GUI切替後も実行時のバージョンが想定と異なることがあるため、必ず確認手順を設けます。
  • リスク把握とバックアップ準備：テーマ／プラグイン／カスタムコードが PHP 8 に未対応の可能性あり。何かあったときに戻せるよう、バックアップ体制を整えておきます。
  • ステージング環境の活用：本番サイトを直接切り替えるのではなく、テスト環境で確認した上で本番移行するのが安全です。
  • スケジュールと役割分担：誰が何をいつまでに確認・対処するか明確にします。

このように「方針を整える作業」が、後工程での混乱を防ぎます。

３．バージョン差分の理解：PHP 7 ⇒ PHP 8

PHP 8 へ切り替える前に、PHP 7 と PHP 8 の違いを把握することが不可欠です。主な変更点を整理します。

3-1. 新機能／言語仕様の改善

例えば以下のような改善があります：

  • 名前付き引数（Named Arguments）やコンストラクタプロパティプロモーションなど、コード記述効率が向上。 (Liquid Web)
  • nullsafe 演算子（?->）など、ネストオブジェクトアクセスの安全性向上。 (bounteous.com)
  • ユニオン型（Union Types）など、型宣言の拡張により、より堅牢なコード設計が可能に。 (Lets Go Dev)
  • JIT（Just-In-Time コンパイラ）導入など、実行性能改善の下地あり。 (bounteous.com)

これらは “メリット” であり、将来的な保守性・性能に寄与します。

3-2. 互換性・注意すべき変更（リスク）

ただし、PHP 8 には互換性を壊す変更もあります。以下、代表的なものです：

  • 文字列と数値の比較挙動が変わっています。例えば、PHP 8 では “文字列” → 数値変換ではなく、数値 → 文字列に変換され比較されるケースがあります。 (Medium)
  • リソース型がオブジェクト型に返る関数が増え、「is_resource()」でのチェックが通らなくなる場合があります。 (Medium)
  • エラー／例外の扱いが厳しくなっています。例えば、ゼロでの除算が例外を投げるようになったり。 (Medium)
  • 多くの拡張機能や関数が非推奨または削除されています。切り替え前に公式マニュアルの “Migration” ガイドを参照すべきです。 (php.net)
  • プラグインやテーマ、それにカスタム実装が PHP 8 を想定していない可能性あり。例えば、引数の型や戻り値型、メソッドシグネチャが変わる場合があります。

このように、ただボタンを押して切り替えるだけでは “事故” が起こる可能性があります。

４．チェック／確認方法：実務的手順

では、実際にどのように確認を進めればよいか。「効率的にチェックをするための流れ」を整理します。

4-1. 確認観点の整理

事前に「チェックすべき観点」を整理しておくと作業がスムーズです。例えば：

  • 使用しているプラグイン・テーマ・ライブラリが PHP 8 に対応しているか／推奨バージョンは？
  • カスタムコード（functions.php や独自プラグイン等）が非推奨関数・構文を使っていないか？
  • データベース接続や PDO／mysqli などのドライバが新バージョンで問題ないか？
  • エラーログに “Deprecated” や “Fatal” が出ていないか？切替前に確認を。
  • GUIで切り替えた後、本当に PHP 8 で動いているか？（CLI や phpinfo() で確認）
  • ステージング環境でフロント画面・管理画面・投稿・メディアアップロード・キャッシュクリアなど主要機能が正常か？
  • 外部 API や Webhook連携、カスタムフィールド、テーマ内カスタマイズが影響を受けていないか？

4-2. 確認手順の確立

実践として以下手順を推奨します：

  1. ステージング環境を用意。現行 PHP 7 で動作確認済みの状態にしておく。
  2. バックアップ取得（ファイル・データベースとも）。
  3. GUI 等で PHP バージョンを PHP 8 に切り替え（レンタルサーバー等で可能な場合）。
  4. phpinfo() あるいは php -v（SSH 利用可なら）で切り替わっているか確認。GUIと実際のバージョンが異なるケースありです。
  5. ログを確認：エラー／警告が出ていないか、特にdeprecated・fatal。
  6. フロントエンドと管理画面を隅々まで操作：投稿作成／編集、メディアアップ、プラグイン設定、キャッシュクリア等。
  7. プラグイン・テーマを一つずつ無効化→有効化テストも有効。
  8. 必要であれば自動テスト・ユニットテスト・UIテストがあれば実行。
  9. 問題があれば該当コードを保護しつつ、本番移行日を調整。

この「チェックの実施」を丁寧にやることで、不慮のサイトダウンや画面崩れを防げます。

問題個所の抽出用シェルプログラムサンプル

以下は、sshでログインして、チェックしたいディレクトリ（サブディレクトリ含む）で、実行することで、問題個所抽出するコード(サンプル)です。環境に合わせてバージョン設定などの調整が必要です。

$>  PHP_BIN="/usr/bin/php8.1" find . -name "*.php" -type f -print0 | while IFS= read -r -d '' f; do head -c3 "$f" | grep -q $'\xEF\xBB\xBF' && { echo "BOM除去: $f"; sed -i '' '1s/^\xEF\xBB\xBF//' "$f" 2>/dev/null || sed -i '1s/^\xEF\xBB\xBF//' "$f"; }; "$PHP_BIN" -l "$f" 2>&1 | grep -v "No syntax errors" | grep . && { echo "構文エラー: $f"; echo; }; done; echo "チェック完了（PHP 8.1: $(/usr/bin/php8.1 -r 'echo PHP_VERSION;')）"
チェック完了（PHP 8.1: 8.1.32）

５．対処：問題が見つかったときの対応方針

チェックの結果、何らかの問題（エラー、崩れ、警告）が出た場合の “対応” を以下のように整理します。

5-1. プラグイン／テーマの対応

  • 利用中のプラグイン・テーマが PHP 8 非対応であれば、アップデート可能かを確認。開発者がサポートを打ち切っている場合は代替を検討。
  • テーマ・プラグインの開発版・互換版が提供されていれば、それに切替。
  • カスタマイズが多いテーマ（子テーマ含む）は、PHP 8 対応コードが含まれているか、開発元に確認。

5-2. カスタムコードの修正

  • 非推奨関数・構文を使っている場合：公式マニュアルの “Backward Incompatible Changes” を参照。 (php.net)
  • 例：文字列⇔数値比較の挙動変化、リソース → オブジェクト返却、除算ゼロの例外化など。 (Medium)
  • 型宣言や戻り値の型が厳しくなったため、関数の引数・戻り値を見直す。
  • 自動変換ツール・リファクタリング支援ツール（例：Rector）を活用するという事例もあります。 (Reddit)

5-3. 最速リカバリ手段も用意

  • 本番移行中に不具合が出そうな箇所があれば、切り戻し可能な状態（バックアップ／リカバリ手順）を確保。
  • 本番移行直後はアクセス数が少ない時間帯を選ぶのも有効。

5-4.　独自実装コードの修正

5-2.項と同じですが、ここでは実際に検出した事例を紹介しつつ、もう少し深堀してみましょう。
このページではつぎの１つだけを書きます、そのほかの詳細は別ページにまとめますので参考にしてください。

PHP 8 では、PDO::prepare() 後に execute() する前に beginTransaction() を呼び出すと、
PDOException: There is no active transaction が発生し、commit() 前に例外でスクリプトが終了 します。

この問題は4-2.項に書いた構文チェック（PHP -l *.php） の方法では検出できません。 php実行で動きが変わったことで検出はできますが、事後検出となってしまいます。エラーログでも検出できますが、例外catchして捨ててしまっていると情報が得られません。 このようなものもまとめて検出する仕掛けも用意したほうが良いでしょう。




６．最終確認と移行後のフォローアップ

移行が完了したら、以下の「最終確認」と「フォローアップ体制」を整えておきましょう。

  • フロント・管理画面ともに主要な操作をもう一度全体的に確認。
  • エラーログ・サーバーログを監視し、想定外の警告／エラーが出ていないか。
  • アクセス数の急変やページ表示速度の変化がないか、モニタリング。
  • プラグイン・テーマの更新状況を定期的にチェック。PHP 8 対応が正式にされていないものがあれば優先的に対応。
  • 将来バージョン（PHP 8.x → 8.y／9 が出た場合）にも備えた“アップグレード体制”をあらかじめ整えておく。

７．まとめ＆今後の視点

  • PHP 8 には多くのメリット（性能向上、モダンな構文、型安全性向上など）があり、可能であれば早めの移行がおすすめです。 (bounteous.com)
  • ただし、「すぐに切り替え＝安心」ではなく、既存実装・プラグイン・テーマ・カスタムコードが PHP 8 に対応しているかを丁寧に確認・修正する必要があります。
  • 本記事で紹介した「作業方針→差分理解→チェック手順→対処→最終確認」の流れを実践すれば、移行時のリスクを大きく下げることができます。
  • 今後、PHP 自体のバージョンアップ（例えば PHP 8.1／8.2 以降）も視野に入れ、「バージョンアップ可能な設計」「コードのモダン化（型宣言／非推奨箇所の排除）」を早めに進めておくと、将来的には“また大変”という状況を回避できます。
  • 最後に、移行後も「アクセス・表示速度・エラーログ」という観点を継続してモニタリングすることを強くお勧めします。