🔬 PHP 8.3「トップ404」問題 徹底調査+対応策

happy-hypno.jp(/blog・/info)|作成 2026-08-18 10:35 JST|AI秘書ユズキ
📜 過去事故2件の精密再構成 🌐 本番構造の実測 🔌 プラグイン14個の棚卸し 📚 WordPress公式互換表で裏取り

📌 3行サマリー

  1. 根本原因が確定:「トップ404」はPHP切替の失敗ではなく、WP 5.5.20 本体がPHP 8に一切対応していないため。WordPress公式互換表で、PHP 8対応はWP 5.6から・PHP 8.3完全互換はWP 6.8からと明記。WP 5.5のままPHP 8.3に何度挑戦しても本体非互換で必ず不具合が出る構造だった。
  2. 解決の鍵=順序の逆転。「PHP上げ→WP更新」ではなく「WP更新(PHP 7.4のまま)→ 後日PHP 8.3切替」の2段階。WP 6.8はPHP 7.4〜8.4対応なので、現行PHP 7.4のまま安全にWP本体を最新化できる。
  3. 7/9事故の管理画面500の犯人(Search Regex)は削除済み。残る懸念はルート委譲の.htaccessのみ→事前にcPanelで内容を控えておけば崩れても即復元可能。

📜 過去事故の精密再構成(work-log実記録より)

2026-07-08 深夜
PHP 8.2 1回目 → /info がWSOD(真っ白)
犯人=Search Regex 2.4(search.php 322行 E_PARSE)。WSOD保護メールで特定→/infoから削除。
2026-07-09 07:40
PHP 8.3 1回目 → 「トップがブログに」+/blog管理画面500
症状=フロントHTTP 200(テーマ自体は動く)・/info全200・/blog管理画面500トップがフロントページを出せず崩れ。7.4即戻しで全復旧(データ無事)。管理画面500の犯人=/blogにも残っていたSearch Regex 2.4.1→削除済み
2026-07-09〜
「トップ404問題」として保留(味見T13)
管理画面500は犯人退治済みだが、トップ表示崩れの真因は未特定のまま「PHP 8.3化保留」に。← 今日この真因が確定した。

🔬 本日の実測で判明した構造

サイト配信構造(curl+REST API実測)

項目実測値含意
happy-hypno.jp/(ルート)の配信元/blogのWP(generator: WordPress 5.5.20・テーマagarikaizen2・canonical→/blog/)ルート→/blog委譲はサーバ側の仕掛け(ルートの.htaccess rewrite等)
/blogのWP設定(REST API)siteurl=home=https://happy-hypno.jp/blogWP設定は/blog完結。ルート表示はWPの設定外=.htaccessが崩れるとトップが行き場を失う
/infoのWP設定siteurl=home=https://happy-hypno.jp/info(WP 6.4.8)ルート委譲が壊れた時のフォールバック先になった可能性(「/infoのblognameが出た」記録と整合)

🔴 根本原因の確定:WP 5.5.20はPHP 8に一切対応していない

WordPress公式の互換表(Make WordPress Core)より:

  • PHP 8.0対応はWP 5.6から(ベータサポート)= WP 5.5はPHP 8系のサポート対象外
  • PHP 8.3はWP 6.4でベータサポート・WP 6.8で完全互換(2025年7月に昇格)
  • WP 6.8の対応PHP範囲=7.4〜8.4 = 現行PHP 7.4のままWP 6.8に更新できる

つまり7/9の「トップ表示崩れ」は、プラグインでも.htaccessでもなくWP本体のPHP 8.3非互換が主因の可能性が最も高い。Search Regexを削除しても、WP 5.5のままではPHP 8.3再挑戦は構造的に失敗する。「PHP切替を先にやる」という順序そのものが間違いだった。

🔌 /blog 現行プラグイン14個の棚卸し(本日read-only実測)

プラグイン現行版WP6.8/PHP8.3互換備考
litespeed-cache7.8.1✅ 最新系問題なし
wordfence8.2.2✅ 最新系問題なし
autoptimize3.1.15.1✅ 最新系フロントHTML介入系だが最新
all-in-one-wp-migration7.107✅ 最新系バックアップの要
yarpp(関連記事)5.30.11✅ 比較的新フロント介入系・更新確認
broken-link-checker2.4.8✅ 比較的新更新確認
wp-migrate-db2.7.10更新確認
advanced-database-cleaner4.2.0更新確認
wp-multibyte-patch2.9.3日本語必須・軽量
wp-asset-clean-up1.4.0.4🟡 要更新フロントHTML介入系・WP更新前に最新化
wp-external-links2.65🟡 要確認フロントHTML介入系
tinymce-advanced5.5.1🔴 2020年で終了した旧名後継「Advanced Editor Tools」へ更新 or 削除(Classic Editorあれば非必須)
akismet4.1.8🟡 古い(現5.x)WP更新前に最新化
classic-editor1.7.0🟡 古いWP更新前に最新化(WP6.8で編集画面維持の要)

→ 🔴1個+🟡4個をWP本体更新の前に最新化(既存の wp_plugin_update.py で1つずつ・各回200確認・実証済み手順)。

🎯 対応策:2段階作戦(順序の逆転が核心)

Stage 0|事前準備(30分・リスクゼロ)
  1. ルート.htaccessの内容を控える(弘樹さんcPanel File Manager 2分):public_html/.htaccess を開いて全文コピー→私に共有。ルート→/blog委譲の仕組みが確定し、PHP切替でcPanelが書き込むhandler行との干渉が起きても即復元できる保険になる。同様に public_html/blog/.htaccess も。
  2. プラグイン5個の最新化(ユズキ・wp_plugin_update.py・1つずつ200確認):tinymce-advanced→Advanced Editor Tools/akismet/classic-editor/wp-asset-clean-up/wp-external-links
  3. フルバックアップ(All-in-One WP Migration・/blogと/info両方・弘樹さん管理画面 or ユズキ)
Stage 1|WP本体 5.5.20 → 6.8系(PHP 7.4のまま・30-60分)
  1. PHPは7.4のまま触らない(WP 6.8はPHP 7.4対応=現環境で最新WPが動く)
  2. WP管理画面「更新」→「今すぐ更新」ボタンで本体更新(zip WAF問題は管理画面内更新なら回避)
  3. 更新直後に wp_monitor.py 7項目+トップ/ページ送り/個別記事/カテゴリ/attachment 301/canonical の実測検証(昨日確立した期待値表と照合)
  4. 異常時=All-in-One WP Migrationで復元(実証済みの安全網)
  5. ✅ この時点で副産物:セキュリティ修正が6年ぶりに最新化・ブロックエディタ等の新機能はClassic Editorで従来通り
Stage 2|PHP 7.4 → 8.3切替(後日・15分・WP 6.8なら完全互換)
  1. 弘樹さんがcPanel MultiPHP Managerで8.3へ切替
  2. ユズキが即 wp_monitor.py+トップ表示・ルート委譲の実測(Stage 0で控えた.htaccessと差分確認)
  3. 異常なら「7.4に戻す」で即復旧(1分・実証済み)→ .htaccess差分を見て原因特定→再挑戦
  4. ✅ WP 6.8×PHP 8.3=公式完全互換の組み合わせなので、7/9とは前提が根本的に違う

なぜこの順序なら「トップ404」が再発しないのか

7/9の失敗は「PHP 8.3非対応のWP本体の上でPHPだけ上げた」ことが主因。2段階作戦では:

  • Stage 1でWP本体の非互換という最大の変数を消してからStage 2に進む
  • Stage 2で仮に問題が出ても、残る変数は.htaccessのhandler行干渉のみ=Stage 0の控えと突き合わせて数分で特定・復元できる
  • 各Stageの間に日を置けるので、切り分けが常に1変数ずつ

⚠️ リスクと安全網

リスク確率安全網
WP 5.5→6.8のビッグジャンプでテーマ非互換低(agarikaizen2は自作クラシックテーマ・テンプレート階層APIは6.8でも不変)All-in-One WP Migrationで丸ごと復元
旧プラグインがWP 6.8で誤動作低〜中(Stage 0で5個最新化してから更新)1個ずつ停止で切り分け(プラグイン停止はサイト無害・実証済み)
DBスキーマ更新の失敗極低(WP標準の自動処理)事前フルバックアップ
PHP切替で.htaccess handler行干渉→ルート委譲崩れ中(7/9で類似症状)Stage 0の.htaccess控え+7.4即戻し(1分復旧・実証済み)
mixhost WAFがWP本体更新を403で弾く低(管理画面内更新はzipアップロードと別経路)失敗時はWP-CLI or 弘樹さんcPanel経由の手動更新に切替

🚀 実行スケジュール案

  • 今週どこかの午前(60-90分ブロック):Stage 0+Stage 1を連続実行(ユズキ主導・弘樹さんは.htaccessコピーとバックアップ確認のみ)
  • 数日様子見(WP 6.8で安定確認・GSC/表示に異常ないか)
  • 翌週(15分):Stage 2のPHP 8.3切替(弘樹さんcPanel操作+ユズキ即検証)
  • 成功後:flowverse.jpのPHP 8.3化([[project_flowverse_php8_migration_pending]]・SOLARISテーマ更新とセット)も同じ型で回せる

「Stage 0 GO」で事前準備から始めます。その際、cPanelで public_html/.htaccesspublic_html/blog/.htaccess の全文コピーをお願いします。