WP-Stagingサイトが重大なエラーで表示されない原因と直し方
WP-Stagingの複製サイトにアクセスすると「このサイトで重大なエラーが発生しました」と表示され、デバッグログに call_user_func_array の TypeError が記録される場合、PHP 8系ではコアファイルの欠落や混在が致命的エラーへ変わる。PHP 7.4系へ一時的に切り替えて管理画面へ入り、WordPressコアの再インストールとプラグイン更新を行えば根本から直る。
WP-Stagingサイトが重大なエラーになる原因
デバッグログの最終行には call_user_func_array() が「Argument #1 ($callback) must be a valid callback」という趣旨の TypeError を投げ、_wp_register_default_icon_collections という関数が見つからないことが記録される。この関数は WordPress 本体の wp-includes/theme.php で定義されるもので、本来は必ず存在しているはずだ。
WP-Staging はライブサイトのファイルとデータベースをコピーしてステージングサイトを作る。このとき wp-includes 内のファイルが不完全にコピーされていたり、旧バージョンのコアファイルと新バージョンが混在したりすると、関数が未定義のまま WordPress の読み込み処理が進み、このエラーが発生する。
PHP 8.0 以降は call_user_func_array() に存在しない関数を渡すと、警告ではなく TypeError を投げて処理を停止する。PHP 7.4 までは警告を出して読み込みが続いたため、バージョンを下げると画面が復帰する。ただし原因であるコアファイルの欠落は残ったままなので、根本解決にはならない。
同じログに Wordfence や ThemeWhizzie の Deprecated 警告も出ている。これらは PHP 8 で廃止予定になった古い記法への警告で、単体ではサイトを落とさない。ただ PHP 8 非対応の古いコードが残っている証拠なので、更新で片付けておく必要がある。
debug.logに記録されたエラーを読み分ける
WordPress のデバッグ情報は wp-content/debug.log に保存される。今回のログには Deprecated 警告が数件並び、最後に Fatal error が1件出ている。サイトが落ちる直接原因は Fatal error の1件だけだ。まだログを有効にしていない場合は、wp-config.php を編集して次の3行を追加する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Fatal error の内容は「呼び出そうとした関数が見つからない」という意味だ。_wp_register_default_icon_collections が WordPress 本体に無いことから、コアの関数定義が不足していると判断できる。Wordfence の Non-canonical cast や ThemeWhizzie の Creation of dynamic property は、PHP 8 で非推奨となった書き方を警告しているにすぎない。
PHP 7.4系へ切り替えて管理画面に戻る
最初の応急処置として、サーバーの PHP バージョンを 7.4 系へ変更する。ホスティングの管理画面にある「PHP バージョン管理」や「PHP Selector」などから選択するのが一般的だ。IIS 10 で FastCGI を使っている場合は、php-cgi.exe のパスを 7.4 系へ変更する。切り替え後はステージングサイトを再読み込みして、管理画面に入れるか確認する。
PHP 8 系ではコールバック不足が TypeError で致命化し、PHP 7.4 系では警告として読み込みが継続する。この違いにより、バージョンを下げると一時的にサイトが復帰する。
ただし PHP 7.4 系はセキュリティサポートが終了している。常用するのは避け、次の手順で WordPress 本体とプラグインを整えた後、PHP 8 系へ戻すのが安全だ。
WordPressコアを再インストールして欠落ファイルを戻す
根本原因は WordPress 本体のファイルが不完全なことだ。管理画面に戻れたら、ダッシュボードの「更新」画面から現在のバージョンを再インストールするのが最も簡単だ。ファイルの欠落や破損が解消され、関数が再び見つかるようになる。
復旧手順の全体像は上のとおり。各ステップの詳細を以下に示す。
ダッシュボードからコアを再インストールする
管理画面の「ダッシュボード」→「更新」を開くと、「WordPress の最新バージョンを実行しています」の下に「バージョン XX を再インストール」というボタンが表示される。ここを押せば、同じバージョンのコアファイルが公式配布パッケージから取得され、欠落している wp-includes 内のファイルが上書きされる。
再インストール後にステージングサイトを更新し、重大なエラーが消えたかを確認する。もし管理画面にも入れない状態なら、次の FTP で対処する方法を試す。
管理画面に入れないなら FTP で wp-includes を上書きする
ステージングサイトにアクセスできない場合、FTP または SFTP でサーバーへ接続する。WordPress の公式サイトから同じバージョンのパッケージを取得し、その中の wp-includes と wp-admin フォルダを、壊れているステージング側へ上書きアップロードする。
wp-content フォルダは上書きしない。ここにはテーマやプラグイン、アップロード画像が入っており、上書きすると設定が消える危険がある。あくまでコアのファイルだけを入れ替えるのが安全だ。
ステージングサイトを作り直す判断
破損の範囲が広い場合や、エラーが複数回繰り返される場合は、WP-Staging でステージングサイトを作り直すのも有効だ。その際、除外設定やファイルコピーの途中で止まっていないか、保存容量が十分かを確認する。ライブサイト側が正常なら、再作成のほうが速く済むことも多い。
Wordfenceと使用テーマをPHP 8対応版へ更新する
Fatal error とは別に、Wordfence と ThemeWhizzie から Deprecated 警告が出ている。これは今すぐサイトを落とすものではないが、PHP 8 系で廃止された書き方を使っており、将来の PHP 更新で同じく致命的エラーへ変わる可能性がある。根本解決の段階でまとめて更新しておく。
Wordfence はプラグインの更新画面から最新版へ更新できる。テーマが市販テーマで更新が止まっている場合は、PHP 8 非対応の警告が出続けるため、テーマの差し替えや該当するウィザード機能の無効化を検討する。更新が終わったら PHP を 8 系へ戻し、ステージングサイトが表示されるか、デバッグログに Fatal error が出ないかを確認する。
よくある質問
PHP 7.4に戻すだけで問題は解決するのか
サイトは一時的に復帰するが、コアファイルの欠落や混在という原因は残る。PHP 7.4 系はセキュリティサポートが終了しているため、WordPress コアの再インストールで根本解決してから PHP 8 系へ戻すのが正しい流れだ。
管理画面にも入れないときはどうするのか
FTP または SFTP でサーバーへ接続し、WordPress 本体の wp-includes と wp-admin を公式パッケージから上書きする。その前に wp-config.php でデバッグログを有効にしておくと、上書き後もエラーが出る場合に原因を特定しやすい。
WordPressコアの再インストールでデータは消えるのか
ダッシュボードからの再インストールでは wp-content を触らないため、テーマやプラグイン、アップロード画像、データベースの内容は消えない。念のため実行前にバックアップを取るのが安全だ。
ステージングサイトを作り直した方が速いのか
ファイル破損の範囲が広い場合や再発を繰り返す場合は、WP-Staging で作り直す方が確実だ。その際は除外設定と保存容量を確認し、ライブサイト側が正常であることを先に確かめておく。
Wordfenceの警告をPHP 8のままで消せるのか
Wordfence を最新版へ更新すれば大半の Deprecated 警告は消える。テーマ側の警告が残る場合は、該当するウィザード機能を無効化するか、PHP 8.1 系を選んで一時的に警告を抑える方法もある。ただし警告を無理に隠すより、コードを更新する方が安全だ。
この記事のポイント
- call_user_func_array の TypeError はコアファイル欠落が PHP 8 で致命化したもの
- PHP 7.4 への切り替えは応急処置で根本解決ではない
- 管理画面から WordPress コアを再インストールして欠落ファイルを戻す
- Wordfence とテーマを更新し PHP 8 へ戻して確認する
- ステージング作成時の除外設定やファイルの完全性も確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WP Activity Log v5.6.4でアプリパスワード削除時に500エラーが出る原因と回避策
WP Activity Log v5.6.4を有効化したWordPressサイトで、プロフィール画面からアプリケーションパスワードを取り消すと「このサイトで重大なエラーが発生しました」と表示される場合、プラグインのアップデート待ちでは解決しない。原因はWP Activity Logが汎用のupdate_user_metaフックに対するメタキーの検証を怠っている点にあり、PHP 8ではcount()に文字列を渡すとTypeErrorが発生して致命的エラーになる。この記事では、エラーの仕組みから、手動での回避策、上位互換のためのコードパッチまでを具体的に示す。
エラーの全容と発火する条件
WP Activity Log v5.6.4に収録されたWP_User_Profile_Sensor::event_application_password_added()は、汎用のupdate_user_metaアクションにフックされている。関数シグネチャには$meta_keyが渡されているが、コールバック内でこれを一度も検証しない。代わりにHTTPリファラとREQUEST_URIだけを見て、アプリケーションパスワード変更のリクエストかどうかを判定している。
このため、ユーザーのプロフィール画面からアプリケーションパスワードを取り消すときに、REST APIへのDELETEリクエストが発行される。リファラチェックはプロフィールページを指し、URIチェックも/wp/v2/users/{id}/application-passwords/...を含むため、両方の条件を通過する。ここでBuddyBoss Appのようなプラグインが、同じリクエストのディスパッチ中にlast_activityというユーザーメタを更新すると、本来アプリケーションパスワードのメタを想定していたセンサーが誤ってそのtimestamp文字列を処理してしまう。
致命的エラーの発生箇所とスタックトレース
実運用のログには、次のような未捕捉のTypeErrorが記録される。PHP 8ではcount()の引数が配列またはCountableでない場合、警告ではなくTypeErrorがスローされる。WP Activity Logのコードは文字列をcount()に渡しているため、リクエストが500エラーになる。
スタックトレースを追うと、クラスの203行目でcount( $_meta_value )が呼ばれている。ここで$_meta_valueはtimestampの文字列であり、$old_valueは_application_passwordsの配列である。文字列をcount()に渡すとPHP 8ではTypeErrorが発生し、アプリケーションパスワードの取り消しは実行されないまま処理が失敗する。
第一の対処方法、プラグインの停止で被害を止める
まず、サイトが利用者から見て壊れている状態を早く解消するには、WP Activity Logを停止する。管理画面にアクセスできる場合は「プラグイン」画面からWP Activity Logを無効化する。アクセスできない場合はFTPでwp-security-audit-logディレクトリをリネームする。リネームするとWordPressがプラグインを検出できなくなり、自動的に無効化される。
第二の対処方法、一時的にPHPのエラー表示を止める
WP Activity Logを使い続けたい場合は、PHPのcount()エラーが致命的にならないよう回避策を施す。だが、これは根本解決ではなく症状を隠すだけだ。むしろ、エラー自体を修正するパッチを適用する方が安全である。ただし、プラグインのアップデートで上書きされることを理解した上で、運用上の措置として行うかどうかを判断してよい。
ソースコードを直接修正する根本対応
WP Activity Logの該当ファイルはwp-security-audit-log/classes/WPSensors/class-wp-user-profile-sensor.phpである。コールバックの先頭で、メタキーが_application_passwordsでない場合は早期returnするようガードを追加する。これが今回のエラーを確実に止める最小の修正だ。
public static function event_application_password_added( $meta_id, $user_id, $meta_key, $_meta_value ) {
if ( '_application_passwords' !== $meta_key ) {
return;
}
// 以下、既存の処理
}加えて、防御的措置としてcount()に渡す前に配列キャストを行うと、将来何らかの形で配列以外の値が混入した場合にも致命的エラーを防げる。メタキーガードだけでも今回の症状は解消するが、運用中のサイトでは両方の修正を施しておく方が堅牢だ。
} elseif ( count( (array) $_meta_value ) < count( (array) $old_value ) ) {修正後、コード上の同じパターンが他に残っていないか、deleted_user_metaやadded_user_metaへの登録も確認するとよい。同じクラス内で複数のフックが同様のリファラ＋URIチェックだけに頼っている場合、似た条件のリクエストで誤発火する可能性がある。
PHP 8環境で注意すべきcount()の挙動
PHP 7.xでは、count()に文字列を渡しても警告が出るだけで処理は継続されていた。しかしPHP 8ではTypeErrorとしてスローされるため、これまで表面化しなかったコードの前提ミスが致命的エラーとして現れる。WP Activity Logに限らず、WordPressプラグインの旧コードでは、更新順にこうした潜在バグが発覚することがある。
サイトをPHP 8系へ更新した直後に、特定の操作でのみ500エラーが出る場合は、エラーログにcount(): Argument #1 ($value) must be of type Countable|array, string givenのような記録が残っていないか確認する。該当する場合は、エラーを起こしているプラグインのコードが文字列をcount()に渡している可能性が高い。
- count()に文字列を渡すと警告のみ
- 処理は継続される
- 潜在的バグが表面化しない
- TypeErrorがスローされる
- 致命的エラーで500応答
- 操作が完了しない
よくある質問
WP Activity Logを無効化すると監査ログは消えますか？
無効化しても記録済みの監査ログはデータベースに残る。ただし、無効化している間に発生したイベントは記録されない。復旧後にプラグインを再度有効化すれば、既存のログを閲覧できる。
BuddyBoss Appが原因なのでBuddyBoss側を停止すれば直りますか？
BuddyBoss Appがユーザーメタを更新するタイミングが発火に重なっているが、根本的な誤動作はWP Activity Log側のフック設計にある。BuddyBoss Appが動いていなくても、別のプラグインが同様にRESTリクエスト中にユーザーメタを更新すれば同じエラーが起きる。
WP Activity Logのバージョンを下げれば回避できますか？
過去のバージョンが同じコードを含んでいる場合、単純なダウングレードでは解消しない。今回のクラスのコールバックを変更せずに添付された報告では、v5.6.5にも修正が含まれていないと指摘されている。信頼できる最新の修正が入るまでは、上記のコードパッチを適用するか、プラグインを停止する方が確実だ。
プロフィール画面でアプリパスワードを管理できる権限がないユーザーも影響を受けますか？
このエラーはアプリケーションパスワード管理を行えるユーザーに限らず、同じリクエスト経路でユーザーメタが更新される状況であれば発火しうる。ただ、発火条件としてプロフィール画面からの操作と、REST APIのURIにアプリケーションパスワードのパターンが含まれることが必要になる。
プラグインをアップデートしたら勝手に直りますか？
プラグインの開発者がメタキーガードを実装したバージョンをリリースすれば直る。ただし、現時点で修正が含まれているかはリリースノートとソースを確認する必要がある。修正が見つからないうちは、手動パッチか無効化で運用を守る。
この記事のポイント
- WP Activity Log v5.6.4の500エラーはPHP 8のcount()エラーが原因
- コールバックがメタキーを検証せず、アプリパスワードと無関係なユーザーメタで誤発火する
- メタキーガードを追加するコードパッチが根本解決になる
- 配列キャストを加えるとPHP 8の厳格なエラーに強いコードになる
- 修正版が出るまでは、プラグイン停止かパッチ適用で被害を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている