WordPressのエラー

このエラーカテゴリーについて

# WordPressのエラー

WordPressの障害は、空白のページ、500 Internal Server Error、データベースに関する明示的なメッセージ、またはPHPメモリ枯渇の通知として現れることがあります。これらの症状がすべて同じ問題を示しているとは限りません。まず、訪問者に正確に何が表示されているか、WordPressダッシュボードに何が報告されているか、障害が発生する前に何が変更されたかを記録してください。

このカテゴリーのガイドを使って、目に見える症状と、WordPressスタック内で最も可能性の高い箇所を照合してください。プラグインの更新直後に発生した障害は、データベース接続メッセージやAllowed memory size ... exhaustedエラーとは、最初に確認すべき点が異なります。複数のコンポーネントを一度に変更することは避けてください。管理されたテストを行うことで、原因を特定しやすくなり、問題の再発も防ぎやすくなります。

よくあるWordPressのエラーパターン

プラグイン更新後の500エラー

プラグインの更新直後に500 Internal Server Errorが発生した場合、そのプラグインが最も有力な原因候補です。更新によってPHPの互換性問題や、アクティブなテーマ、別のプラグイン、またはホスティング環境との競合が表面化した可能性があります。

最も有効な確認方法は、利用可能な復旧手段を使って更新したプラグインを無効化するか、以前の状態に戻し、その後に影響を受けたリクエストをテストすることです。サイトが復旧した場合は、PHPエラーの詳細を確認し、関連するテーマやプラグインの組み合わせでそのプラグインのバージョンをテストしてください。すべての500レスポンスがホストに起因すると決めつけないでください。

詳しい診断については、[WordPressのプラグイン更新後に発生する500エラー](/wordpress-500-error-after-plugin-update)を参照してください。

WordPressのWhite Screen of Death

White Screen of Deathは、有用なエラーが表示されない完全な空白のレスポンスです。訪問者に対してPHPの致命的エラーが非表示になっている場合によく発生します。空白のページだけでは、問題がプラグイン、テーマ、PHPの処理、メモリ制限、破損したWordPressファイルのいずれにあるかを特定できません。

次のステップは、可能な限り訪問者にエラーを表示しない状態で、WordPressのデバッグ機能またはホスティング環境を通じて根本的なエラーを特定することです。メッセージによってコンポーネントや処理が特定できたら、その原因を無効化、復元、または修正してから再テストします。空白のページを自動的にデータベース障害と判断してはいけません。

診断の手順については、[WordPressのWhite Screen of Death](/wordpress-white-screen-of-death)を参照してください。

データベース接続の確立中に発生するエラー

Error Establishing a Database Connectionというメッセージは、WordPressがMySQLまたはMariaDBのデータベースに接続できなかったことを意味します。変更を加える前に元の値を記録したうえで、wp-config.phpにあるデータベース名、ユーザー名、パスワード、ホストの値を確認してください。

設定が正しいように見える場合は、ホスティング環境からデータベースサービスに到達できるか、またデータベースユーザーが必要なアクセス権を保持しているかを確認します。テーブルの破損も可能性の一つですが、データベースの修復は接続と設定の確認後に行うべきです。修復を変更する前に、利用可能なバックアップを保護してください。

手順ごとの詳しい解説については、[WordPress: データベース接続の確立中に発生するエラー](/wordpress-error-establishing-a-database-connection)を参照してください。

WordPressのメモリ枯渇エラー

Allowed memory size of X bytes exhaustedのようなエラーは、PHPプロセスが設定されたmemory_limitの上限を超えてメモリを使用したことを意味します。利用可能な上限を引き上げることでリクエストが完了できる場合はありますが、メモリ使用量が増えた理由までは説明できません。

エラーがプラグインやテーマの変更、インポート、バックアップ、メディア処理、その他の負荷の高い処理中に発生し始めたかを確認してください。サイトで利用できるメモリ設定を確認し、エラーの詳細から関係するリクエストやコンポーネントを特定します。同じ処理で繰り返しメモリが枯渇する場合は、上限を際限なく引き上げるのではなく、負荷の高い処理を調査してください。

当面の対処と長期的な診断については、[WordPressのメモリ枯渇エラー](/wordpress-memory-exhausted-error)を参照してください。

実践的なWordPressエラー診断プロセス

1. 症状を正確に記録する。 メッセージ、HTTPステータス、影響を受けたURLまたはタスク、ページが空白かどうか、ダッシュボードが引き続き利用できるかを記録します。
2. 発生時期を確認する。 直近のプラグインまたはテーマの更新、WordPressまたはPHPの変更、設定の編集、移行、インポート、バックアップ、ホスティング側のイベントを確認します。
3. PHP、アプリケーション、データベースの症状を切り分ける。 PHPの致命的エラーメッセージ、空白のページ、500レスポンスは、データベースへの直接的な接続エラーとは異なる切り口を示します。
4. ログまたはデバッグ出力を確認する。 一般的なブラウザエラーよりも、コンポーネント名、PHPファイル、処理内容、完全なエラーメッセージのほうが有用です。
5. 可能性の高い原因を一つずつテストする。 発生時期と最も密接に関係するコンポーネントを無効化するか以前の状態に戻し、その後に失敗したリクエストを再実行します。
6. 公開機能と管理機能の両方を確認する。 ホームページが表示されても、ログイン、公開、フォーム、インポート、その他の影響を受けたリクエストが正常だとは限りません。
7. 成功した変更を記録する。 別の更新や設定変更を行う前に、何を元に戻したか、または調整したかを記録します。

避けるべきこと

• 原因を切り分ける必要がある場合は、すべてのプラグインを無効化し、テーマも同時に変更しないでください。
• 500レスポンスをホスティングサーバーが利用できないことのみに起因すると決めつけないでください。WordPressのコードが発生させることもあります。
• メモリを消費している処理を特定せずに、PHPメモリを繰り返し増やさないでください。
• 元の値を保存し、利用可能なバックアップを検討せずに、データベース設定を上書きしないでください。
• 詳細なPHPエラーを必要以上に長く訪問者へ公開しないでください。
• ブラウザの更新を診断とみなさないでください。ログ、管理されたテスト、正確なエラーメッセージのほうが確かな証拠になります。

訪問者または管理者に表示されている症状に最も近いガイドから始めてください。目的はページを復旧することだけではありません。問題のある更新、非表示のPHP致命的エラー、データベースアクセスの問題、リソース制限を区別し、根本的な障害に安全に対処することが重要です。