PHP8 時代の WordPress は“知らないと壊れる”—2025 年からの互換性チェック完全ガイド

2025 年現在、WordPress を運用している企業・個人サイトの多くが「いつか突然サイトが壊れる」リスクを抱えています。その最大の理由が、PHP の急速なバージョンアップと互換性問題です。特に、PHP 8.1／8.2／8.3 が主流となった現在、WordPress 本体は最新 PHP に対応している一方で、テーマ・プラグイン・独自コードが追従できていないケースが圧倒的に多くなってきました。

そして怖いのは、これらの互換性問題の多くが“普段は気付かないまま進行している”という点です。ある日サーバ会社が PHP を 7.4 → 8.2 にバージョンアップした瞬間、管理画面が真っ白になり、企業サイトが全停止する。そのような事故が 2024〜2025 年にかけて急増しています。

本記事では、WordPress を安全に運用するために必須となる「PHP8 時代の互換性チェック項目」を、可能な限り丁寧に、そして実務者の視点で深く掘り下げて解説します。単に「アップデートしましょう」という表面的な話ではなく、実際の現場で何が起きているのか、そしてどう見抜き、どう改善すればよいのかを詳細に解説します。

この記事は、WordPress の開発者だけでなく、企業サイトの運用者、制作会社、フリーランスのエンジニア、または「自社サイトが突然壊れた」経験を持つ方にもきっと役に立つでしょう。

PHP8 で最初に起きる WordPress 障害とは？
PHP8 時代の WordPress 互換性チェック（総合フルリスト）
PHP8 への移行で“確実に壊れやすいコード”とは？
“壊れる前に”やるべき実務的対策
これからの WordPress 運用に必須のマインドセット
まとめ

PHP8 で最初に起きる WordPress 障害とは？

PHP7 系から 8 系への移行で最も多いトラブルは、「非推奨関数の削除」や「型の厳格化」などによる Fatal error です。以下が代表的な症状です。

サイトが真っ白になり何も表示されない
管理画面に入れず wp-admin が 500 error を吐く
ContactForm7, Elementor, WooCommerce が突然動かない
テーマの functions.php が致命的エラーを起こす
json_decode や mbstring 系の関数で Warning → Fatal へ昇格
旧式の MySQL API（mysql_*）が完全に削除され落ちる

これらは「古いテーマ」「古いプラグイン」「独自に書かれた修正コード」が原因で起きることがほとんどです。

特に企業サイトでは、5 年前・10 年前に制作したテーマがいまだに稼働しているケースが多く、そこに埋め込まれた古い書き方が PHP8 で完全に非互換になっていることがよくあります。

PHP8 時代に突入した今、WordPress サイトを運用するなら、まずは「何が危険なのか」を具体的に知る必要があります。

PHP8 時代の WordPress 互換性チェック（総合フルリスト）

ここでは、PHP8 で WordPress サイトを安全に動かすために必要なチェックをすべて網羅します。これらの項目を順に確認することで、ほぼすべての互換性問題を把握できます。

チェック 1：WordPress バージョンは最新か？

WordPress 本体は PHP8.3 に対応しています。しかし、古い WordPress（5.9 以下）では PHP8 に対応しきれていないため、エラーが多発します。

WordPress コアは 最低でも 6.x 系 にしておく
テーマ／プラグインは古い WP で作られていると互換性が低い

WordPress 本体のアップデートを怠っている場合は、互換性リスクが非常に高くなります。特に 5.x 時代のテーマをそのまま使っているサイトは危険です。

チェック 2：テーマが PHP8 に対応しているか？

企業サイトで最も問題を起こすのが「独自テーマの古さ」です。以下を含むテーマは要注意です。

2018 年以前に作られたテーマ
header.php や footer.php の構造が古い
create_function を使っている
get_theme_mod の使い方が古い
isset より先に配列参照して notice を出す
undefined offset が頻繁に出る

テーマ開発者の中には、WordPress 5.0 以前の書き方に固執したまま、PHP 7 時代の知識で制作したケースも多く、それが PHP8 で致命的エラーを引き起こします。

チェック 3：functions.php に独自の危険コードが混ざっていないか？

もっとも多いのが「過去に追加されたカスタムコード」が原因の例です。制作会社が去った後、別の担当者がネット記事を見て functions.php にコードを貼り付け、それが PHP8 で動かない…というケースが大量にあります。

要注意コードは次の通りです。

remove_filter や add_filter の古い文法
PHP7 の古い無名関数の書き方
strtotime の誤った使い方
date 関連の指定ミス
PHP8 から strict になった関数の引数不整合

functions.php に知らないコードが入っている場合は、100% 精査すべきです。

チェック 4：プラグインの更新停止期間は？

プラグインはテーマ以上に互換性問題を引き起こします。

次の条件に当てはまるプラグインは危険です。

1年以上アップデートされていない
開発者がサポートを中止している
評価が低く、互換性の Issue が報告されている
PHP8 の互換性が公式に保証されていない

特に Page Builder 系（Elementor, Divi, WPBakery）は JS・PHP 両方の負荷と互換性問題を抱えがちで、インストール数が多いにも関わらず不具合報告も多い領域です。

WooCommerce も PHP8 でエラーが出やすく、発送設定や支払い関連プラグインとの組み合わせで Fatal になる例も頻繁にあります。

チェック 5：Deprecated（非推奨）警告が出ていないか？

PHP8 では「Deprecated → Warning → Fatal」への昇格が顕著です。

特に以下の関数は要注意です。

ereg, eregi 系（完全削除）
split, spliti（完全削除）
mysql_*（完全削除）
create_function（非推奨から削除へ）
implode 引数順逆
mbstring 系で引数が厳格に
filter_var の動作が厳格化

多くの WordPress 旧テーマはこれらを内部で使用しているため、PHP8 にアップデートした瞬間、エラーが噴出します。

チェック 6：WP_DEBUG を有効にしたことはあるか？

多くのサイトでは、「エラーが表示されていないだけ」で内部的には大量の警告が発生しています。

以下を wp-config.php に設定すると、PHP8 non-compat コードが判明します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

ログに Notice/Warning が出続けている場合は“未来の Fatal error 予備軍”です。

チェック 7：サイトの PHP バージョンは固定か？

レンタルサーバでは PHP のバージョンを手動で固定していない場合、メンテナンス時に自動的に PHP が上がることがあります。これが企業サイトにおける「突然のサイト停止」の主因です。

PHP7.4 → PHP8.1（自動アップグレード）
古いテーマが耐えられず管理画面が真っ白
その結果、会社の受付フォームが停止し問い合わせゼロに…

このような事故が現実に多発しています。

PHP8 への移行で“確実に壊れやすいコード”とは？

PHP8 は厳密な型チェックが強化されました。そのため、7 系まで“動いてしまっていた危険コード”が一斉に露出します。以下は特に壊れやすいコードです。

未定義の配列アクセス

$val = $arr['key'];

PHP8 はこれを厳しく扱います。。

bool が勝手に int に変換されるコード

strtotime(false);

これは PHP8 で Fatal になります。

null を渡してしまうコード

count(null);   // PHP8 では Warning → Fatal の可能性

非推奨関数の使用

create_function()
ereg()
split()

すべて削除済みです。

暗黙の型変換

PHP7までは許容されていた曖昧な型変換が PHP8 では Fatal に繋がります。

WordPress の古いフック書き方

add_filter('the_content', 'myfunc', 999, 1);
function myfunc() {  // 引数ミスマッチ
}

PHP8 では strict になり ArgumentCountError が発生しやすくなります。

“壊れる前に”やるべき実務的対策

ここからは WordPress サイトを健全に保つための具体的な対策を説明します。

本番環境のコピーで PHP8 テストを行う
いきなり本番で PHP バージョンを上げるのは危険です。
かならずステージング（検証環境）でテストします。
テーマのコードレビューを実施
functions.php
single.php
archive.php
404.php
header/footer/sidebar
テンプレート階層
独自の shortcodes
独自のクラス
これらのファイルは数千行に及ぶ場合が多く、プロのエンジニアでも時間がかかります。特に undefined offset、deprecated warnings、引数不一致は丁寧に見直す必要があります。
不要なプラグインを削除
動いているから OK ではありません。
不要プラグインは将来の大事故要因です。
Page Builder を使うサイトは要注意
Elementor
Divi
WPBakery
これらは内部で大量の JS/PHP を利用しているため、互換性・速度・INP 指標の面で問題を起こしやすい領域です。
クラシックテーマからブロックテーマへ移行を検討
ブロックテーマは軽量で、PHP8 に最適化されています。企業サイトでは段階移行が現実的です。
ログ監視を必ず行う
wp-content/debug.log
server error log
PHP error log
これらに Warning や Notice がある場合、その多くが将来 Fatal に変わる可能性があります。