PHP 8.3「トップ404」問題徹底調査＋対応策｜happy-hypno.jp

📌 3行サマリー

根本原因が確定：「トップ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に何度挑戦しても本体非互換で必ず不具合が出る構造だった。
解決の鍵＝順序の逆転。「PHP上げ→WP更新」ではなく「WP更新（PHP 7.4のまま）→ 後日PHP 8.3切替」の2段階。WP 6.8はPHP 7.4〜8.4対応なので、現行PHP 7.4のまま安全にWP本体を最新化できる。
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/blog`	WP設定は/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-cache	7.8.1	✅ 最新系	問題なし
wordfence	8.2.2	✅ 最新系	問題なし
autoptimize	3.1.15.1	✅ 最新系	フロントHTML介入系だが最新
all-in-one-wp-migration	7.107	✅ 最新系	バックアップの要
yarpp（関連記事）	5.30.11	✅ 比較的新	フロント介入系・更新確認
broken-link-checker	2.4.8	✅ 比較的新	更新確認
wp-migrate-db	2.7.10	✅	更新確認
advanced-database-cleaner	4.2.0	✅	更新確認
wp-multibyte-patch	2.9.3	✅	日本語必須・軽量
wp-asset-clean-up	1.4.0.4	🟡 要更新	フロントHTML介入系・WP更新前に最新化
wp-external-links	2.65	🟡 要確認	フロントHTML介入系
tinymce-advanced	5.5.1	🔴 2020年で終了した旧名	後継「Advanced Editor Tools」へ更新 or 削除（Classic Editorあれば非必須）
akismet	4.1.8	🟡 古い（現5.x）	WP更新前に最新化
classic-editor	1.7.0	🟡 古い	WP更新前に最新化（WP6.8で編集画面維持の要）

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

🎯 対応策：2段階作戦（順序の逆転が核心）

Stage 0｜事前準備（30分・リスクゼロ）

ルート.htaccessの内容を控える（弘樹さんcPanel File Manager 2分）：public_html/.htaccess を開いて全文コピー→私に共有。ルート→/blog委譲の仕組みが確定し、PHP切替でcPanelが書き込むhandler行との干渉が起きても即復元できる保険になる。同様に public_html/blog/.htaccess も。
プラグイン5個の最新化（ユズキ・wp_plugin_update.py・1つずつ200確認）：tinymce-advanced→Advanced Editor Tools／akismet／classic-editor／wp-asset-clean-up／wp-external-links
フルバックアップ（All-in-One WP Migration・/blogと/info両方・弘樹さん管理画面 or ユズキ）

Stage 1｜WP本体 5.5.20 → 6.8系（PHP 7.4のまま・30-60分）

PHPは7.4のまま触らない（WP 6.8はPHP 7.4対応＝現環境で最新WPが動く）
WP管理画面「更新」→「今すぐ更新」ボタンで本体更新（zip WAF問題は管理画面内更新なら回避）
更新直後に wp_monitor.py 7項目＋トップ／ページ送り／個別記事／カテゴリ／attachment 301／canonical の実測検証（昨日確立した期待値表と照合）
異常時＝All-in-One WP Migrationで復元（実証済みの安全網）
✅ この時点で副産物：セキュリティ修正が6年ぶりに最新化・ブロックエディタ等の新機能はClassic Editorで従来通り

Stage 2｜PHP 7.4 → 8.3切替（後日・15分・WP 6.8なら完全互換）

弘樹さんがcPanel MultiPHP Managerで8.3へ切替
ユズキが即 wp_monitor.py＋トップ表示・ルート委譲の実測（Stage 0で控えた.htaccessと差分確認）
異常なら「7.4に戻す」で即復旧（1分・実証済み）→ .htaccess差分を見て原因特定→再挑戦
✅ 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変数ずつ

🗂 .htaccess 3ファイル完全解析（2026-08-18 13:17 弘樹さん外出先cPanel提供・Stage 0の①完了✅）

✅ 結論：PHP切替時の確認箇所は「ルートの.htaccess 1箇所」に確定

ファイル	中身	判定
`public_html/.htaccess`（ルート）	❶ルート→/blog委譲Rewrite（手書き・冒頭5行）❷cPanel生成PHP INIブロック❸cPanel生成ハンドラ `AddHandler application/x-httpd-ea-php74`	🟡 ❸が唯一のPHP 7.4ハードコード
`public_html/blog/.htaccess`	LSCACHE＋WP標準Rewrite（RewriteBase /blog/）＋noabort。AddHandlerなし	🟢 完全クリーン
`public_html/info/.htaccess`	LSCACHE＋WP標準Rewrite（HTTP_AUTHORIZATION行はWP 6.x世代標準）＋noabort。AddHandlerなし	🟢 完全クリーン

判明したこと

ルート→/blog委譲の正体＝ルート.htaccess冒頭の手書きRewrite（REQUEST_URI ^/$ のみ /blog/ へ内部委譲）。cPanelはこのブロックを触らないため、PHP切替で委譲自体が壊れる可能性は低い。
PHP 7.4のハードコードは2種：❶ハンドラ行（ea-php74）❷INIブロックの session.save_path ".../ea-php74"＋<IfModule php7_module>（PHP 8系ではモジュール名不一致で不適用になる）。両方ともcPanel生成ブロック＝MultiPHP切替時にcPanelが自動書き換えするはずの箇所。Stage 2直後にこの2種が ea-php83 系へ正しく書き換わったかを照合する。
7/9事故の機序が完全に描けた：切替でハンドラ書き換え→その上のWP 5.5本体がPHP 8.3非対応でFatal error→LiteSpeedのフォールバックで「/infoのblogname」異常表示。Stage 1（WP本体更新）で中間の非互換を消せばこの連鎖は断てる。

Stage 2当日の照合チェックリスト（このスナップショットと突き合わせ）

ルート.htaccessの AddHandler が ea-php83 系に書き換わったか（7.4残置なら手動修正 or cPanel MultiPHP INI Editorで再生成）
session.save_path が新PHPのセッションパスを指しているか
冒頭のルート→/blog委譲5行が無傷か（cPanelは触らないはずだが念のため）
/blog・/info の.htaccessが無変更か（diff）
wp_monitor.py 7項目＋トップ表示（happy-hypno.jp/ で/blogのフロントが出るか）

スナップショット保管先＝knowledge/happy-hypno-renewal/htaccess-snapshots/2026-08-18/（root / blog / info の3ファイル）

⚠️ リスクと安全網

リスク	確率	安全網
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経由の手動更新に切替

👤 役割分担：弘樹さんの作業は「ボタン3つ＋コピペ1回」だけ（2026-08-18 22:06 追記）

進捗状況（2026-08-18 22:00時点）

✅ Stage 0-①完了：.htaccess 3ファイル解析＋スナップショット保管（弘樹さん外出先cPanelから提供）
✅ Stage 0-②完了：プラグイン4件最新化（all-in-one-wp-migration・wordfence・wp-external-links・wp-migrate-db・各回200確認）。残り4個（tinymce-advanced・akismet・classic-editor・wp-asset-clean-up）は新版の動作要件がWP 5.5超のため更新リストに出ない＝Stage 1でWP本体を上げた直後に更新可能になる→Stage 1手順に組み込み済み
⏳ Stage 0-③（フルバックアップ）＝Stage 1当日の最初に実施

Stage 1当日（60〜90分ブロック・弘樹さんの手は約15分）

順	担当	作業	所要
①	弘樹さん	バックアップ：/blog管理画面 → All-in-One WP Migration → 「エクスポート」→「ファイル」を押して完了を待つ。/infoも同様	各5分
②	弘樹さん	WP本体更新：/blog管理画面 → ダッシュボード → 「更新」→ 「今すぐ更新」ボタンを押す → 進捗画面が終わるまで待つ ※ブラウザで進捗が見える形が最も確実なため弘樹さん担当（ユズキがHTTP経由でやると途中経過が見えずタイムアウト判断が遅れる）	5〜10分
③	弘樹さん	「更新終わったよ」と一言 → あとは待つだけ	—
④	ユズキ	wp_monitor 7項目・canonical・attachment 301・全ページ種別の実測検証	10分
⑤	ユズキ	残りプラグイン4個（tinymce-advanced→Advanced Editor Tools・akismet・classic-editor・wp-asset-clean-up）の更新＋再検証	10分

Stage 2当日（数日後・弘樹さんの手は約5分）

順	担当	作業	所要
①	弘樹さん	cPanel → MultiPHP Manager → happy-hypno.jp を選択 → PHP 8.3を選んで適用	2分
②	弘樹さん	cPanelファイルマネージャーで `public_html/.htaccess` を開いて全文コピー→ユズキに貼り付け（8/18と同じ操作・ハンドラ書き換わりの照合用）	2分
③	ユズキ	スナップショットとdiff照合（AddHandler ea-php83化・session.save_path・委譲5行無傷）＋wp_monitor＋トップ表示検証	5分
④	弘樹さん	万一異常時のみ：ユズキが「7.4に戻してください」と言うので、MultiPHPで7.4を選び直す（1分で全復旧・実証済み）	1分

まとめ：弘樹さん＝「エクスポート」「今すぐ更新」「PHP 8.3選択」の3つのボタン＋コピペ1回。ユズキ＝それ以外すべて（事前チェックリスト・各段階の実測検証・異常時の切り分け・プラグイン残更新・記録）。

Stage 1はご在宅の午前がおすすめ（万一の切り戻し判断が速い）。ご都合の良い日に「Stage 1 GO」で開始。

🚀 実行スケジュール案

今週どこかの午前（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/.htaccess と public_html/blog/.htaccess の全文コピーをお願いします。