WordPress ホワイト スクリーン オブ デス エラー (WSoD) を修正する方法

公開: 2023-01-10

WordPress サイトをロードすると、空白の白いページが表示されるだけでイライラします。 これは一般に、 WordPress ホワイト スクリーン オブ デスエラーと呼ばれます。

このガイドでは、具体的にサイトのエラーの原因を突き止める方法と、それを修正する正確な方法について説明します。

  • WordPress で死の白い画面が表示されるのはなぜですか?
  • ステップ #1 - サイトのキャッシュをクリアすることから始めます
  • ステップ 2 – PHP エラー ログを確認する
  • ステップ 3 – デバッグ モードを使用してエラーを特定する
  • ステップ #4 – WordPress と PHP のメモリ制限を増やす
  • ステップ #5 - 最後に行った変更を思い出す
  • ステップ #6 – プラグインの無効化
  • ステップ #7 – サイトのバックアップを復元する
  • デバッグ オプション: テーマの潜在的な問題を確認する

WordPress で死の白い画面が表示されるのはなぜですか?

WordPress ホワイト スクリーン オブ デス エラーに出くわすと、特にイライラします。その名前が示すように、表示されるのは白い画面だけだからです。 何が原因で、どこを調べればよいかについての情報はありません。

White Screen Of Death エラーの例 (wsod)

サイトのエラーの原因を特定し、すべてをバックアップして実行する方法に入る前に、最も一般的な原因の内訳を次に示します。

  • PHP コード エラー (多くの場合、最近行われたプラグインの更新)
  • PHP メモリ制限を使い果たす

注:特定の WordPress ホスティング プロバイダーでは、プラグインからのスクリプトまたはプロセスが突然より多くのリソースを必要とする場合にリソースを制限し、サイトを調整する方法に基づいて、これらの問題に遭遇する可能性が高くなります。 ホスティングプロバイダーでそれが簡単に発生する場合は、より優れたWordPress ホスティングプロバイダーへの移行を検討する時期かもしれません。大規模なマーケティングキャンペーンを実行した場合、簡単にクラッシュするホストはサイトをオフラインにする可能性が非常に高いためです。一度に大量のトラフィックを処理するなど。

それでは、これ以上苦労することなく、Web サイトの WSoD エラーを修正する方法を見てみましょう。

WordPressの死の白い画面を修正する方法

ステップ #1 - サイトのキャッシュをクリアすることから始めます (キャッシュ プラグインを含む)

これが本番サイトである場合、キャッシュが適切に配置されている可能性があります。そうでない場合は、おそらく必要です。 これは強く推奨されますが、ブラウザーまたはサーバーにキャッシュされたバージョンを見ているため、サイトで実際に何が起こっているかを確認できないことを意味する場合があります。

注:これには、追加のキャッシング レイヤーも含まれます。 たとえば、プラグインのキャッシュ -サーバーレベルのキャッシュに加えて、プラグインを必ずクリアしてください。

WordPress のキャッシュをクリアしたら、ブラウザのキャッシュもクリアする必要があります。

ブラウザのキャッシュをクリア

WordPress 管理エリアにアクセスできなくなった場合: WP-CLI を使用してキャッシュをクリアすることができます。 SSH 経由でサイトに接続した後、まず、Servebolt 上のサイトのサイトのディレクトリに移動します (例は、以下の 1 行目に含まれています)。 その後、キャッシュをフラッシュし、必要に応じてテーマとプラグインのアクティベーションを除外します:

cd ~/public

wp cache flush --skip-plugins --skip-themes

完了したら、もう一度サイトにアクセスして、問題が解決しないかどうかを確認してください。

それでも機能しない場合は、他の潜在的な解決策を読んでください…

ステップ 2 – PHP エラー ログを確認する

注:ログ ファイルを読むのが苦手な場合は、手順 3 に進んでください。

キャッシュを除外した後の最初のステップは、PHP エラー ログを確認することです。 ログは、エラー、問題、または潜在的な問題の真の原因を見つけるための最良の方法であるため、デフォルトでログを確認することを常にお勧めします。

ログ ファイルの表示と調査の詳細については、こちらをご覧ください。

そうすれば、この記事で考えられる修正を実装する前に、その理由を理解できます(つまり、メモリ制限を引き上げることで問題が解決するかどうかをテストする前に、より高い制限を必要とする実行中のプラグインを知ることが理にかなっています)。 .

エラー ログを確認する目的は、正しい方向を示すことです。 ただし、ここで発見したことを実際に使用することももちろん同様に重要です。 つまり、エラーと警告の両方に最初に注意を向け、解決に取り組みます (これに慣れていない場合は、開発者と協力することをお勧めします)。

ステップ 3 – デバッグ モードを使用してエラーを特定する

WordPress に組み込まれている「デバッグ」モードは、サーバー上のエラーを特定するのに役立ちます。 WordPress でデバッグ モードを有効にするには、wp-config.php ファイルを開き、最後の行の直前に次のコードを追加します。

// Enable WP_DEBUG mode

define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file

define( 'WP_DEBUG_LOG', true );

注: WP_DEBUG モードを有効にすると、すべての PHP エラー、通知、および警告が表示されます。 これにより、壊れていないものの、WordPress (および/または PHP) の開発規約に従っていないエラーや警告メッセージが表示される場合があります。

Web サイトを開くと、白い画面ではなく、エラーや通知が表示されることがあります。 WordPress でデバッグを有効にすると、エラーをチェックできるdebug.logファイルも作成されます。

これは、すべてのエラーまたは警告に関する情報を含むログ ファイルです。 wp-contentディレクトリにあります。 ログ ファイルを確認して、問題の原因を特定し、修正します。

たとえば、プラグインが問題の原因である場合、エラーはデバッグ ファイルに記録されます。 その後、その特定のプラグインを無効にして、開発者に問題を報告できます。

完了したら、 wp-config.phpファイルからコードを削除して、デバッグ モードを終了します。 これは、WordPress Web サイトのエラーを特定するための優れた方法の 1 つですが、サイトで発生するすべてのエラーを常にキャッチできるわけではありません。

必ずデバッグ モードを終了してください。 多くのユーザーが誤ってオンのままにしておくと、Web サイトのパフォーマンスが低下し、リソース消費が増加します。

ステップ #4 – WordPress と PHP のメモリ制限を増やす

サーバーに設定されているメモリ制限も、問題の原因である可能性があります。 サイト上のすべてのプラグインは異なるスクリプトを実行し、実行のためにサーバーのメモリを消費します。

これに加えて、WordPress はメモリ制限を課して、プラグインがサイトの速度を低下させる非効率的なプロセスを実行するのを防ぎます. そうは言っても、スクリプトが許可されているよりも多くのメモリを必要とする場合、ホワイト スクリーン オブ デスが発生する可能性があります。

ただし、使用可能なメモリを増やす前に、ログを確認して、このすべてのメモリを消費しているものを正確に判断することをお勧めします。 盲目的にメモリを増やすことは決して推奨されないため、最初にログを注意深く確認することが重要です。

これを修正するには、さまざまなプラグインで使用できるメモリの量を増やすことができます。 SFTP を使用してサーバーにログインし、wp-config.php ファイルを見つけます。 ほとんどの場合 (Servebolt を含む)、それはパブリックフォルダーにあります。

wp-config.php ファイルを開き、最下部に次の行を追加します。

define( 'WP_MEMORY_LIMIT', '64M' );

これにより、WordPress はプラグイン スクリプトに最大 64 MB のメモリを割り当てることができます。 場合によっては、これで問題が解決することがあります。 すぐに修正されない場合は、125、256、512 などのより大きな値を試してください。パフォーマンスの低いコードが通常よりも多くのメモリを使用している可能性があるため、より多くのメモリが使用可能になると、コードが活性化されます。

Servebolt では、制限を定義しない限り、WordPress は常に利用可能な最大メモリを使用することに注意してください。 したがって、以前に使用可能なメモリを制限した場合にのみ、この手順に従う必要があります。

または、Servebolt コントロール パネルで、より高い PHP メモリ制限を設定することもできます。 以下に示すように、サイト設定に移動するだけで、Web サイトの PHP メモリ制限を変更できます。

Servebolt コントロール パネルでより高い Php メモリ制限を設定する

ステップ #5 - 最後に行った変更を思い出す

プラグインをインストールして有効化したのか、設定を変更したのか、少し考えてみてください。 通常、死の白い画面は、PHP がクラッシュしたときに発生します (つまり、サーバーに関連していません)。

そのため、これはプラグインで最近開始したプロセスが原因である可能性があります (つまり、大規模なメディア ライブラリを効率的に処理する方法を持つ画像最適化プラグインなど)。

Git を使用すると、変更の追跡と以前の反復の呼び出しがはるかに簡単になるため、Git の使用を検討することをお勧めします。 Git は行った変更を保存し、必要に応じて呼び出すことができます。

自分が行った変更が何であるかを特定できる場合は、後戻りして、プラグインまたはテーマの開発者が変更するまで、その設定を有効にしても機能しない (再度試みてはならない) ことに注意することが容易になります。問題を解決するために連絡しました。

ステップ #6 – プラグインの無効化

これは少し退屈であまり好ましくない方法です。 各プラグインを個別にトラブルシューティングするのは面倒ですが、インストールされているすべてのプラグインを一度に無効にするなどの一括アクションを適用できます.

ダッシュボード エリアにアクセスできない場合は、 FileZillaなどの SFTP クライアントを使用してサイトに接続する必要があります。 wp-content フォルダーを検索すると、「plugins」という名前のディレクトリーが表示されます。

その名前を「plugins-deactivated」に変更し、変更を保存します。 WordPress は、サイトにプラグインをロードするためのフォルダーを見つけることができなくなります。 したがって、自動的にそれらを完全に無効にします。 これは、WordPress がpluginsというフォルダーを探すためそのフォルダーが見つからない場合、すべてのプラグインが非アクティブ化されていると自動的に見なされます。

WordPressでプラグインを無効にする

その時点で、選択した FTP クライアントに戻り、フォルダーの名前をpluginsに戻します。 これで、管理エリアに戻り、プラグインを 1 つずつアクティブ化して、問題のあるプラグインを分離することができます。

ステップ #7 – サイトのバックアップを復元する

何も機能していないように見える場合は、サイトのバックアップを復元することを検討してください。 明らかに、バックアップに問題が発生した場合に備えて、現在のファイルのバックアップを作成することをお勧めします (無理に思えるかもしれませんが)。

Servebolt は、顧客のためにすべてのファイルとデータベースのバックアップを毎日実行します。 サイトチャットを通じてServeboltに連絡するだけで、サイトのバックアップを復元できます. チームは、追加費用なしでバックアップを復元します。

バックアップは最大 30 日間保存され、過去 14 日間は 1 日 1 回のバックアップが保存され、それ以前は毎週 2 回のバックアップが保存されます。

デバッグ オプション: テーマの問題を確認する

ワードプレスのテーマ

Web サイトで使用しているテーマによっては、ホワイト スクリーン オブ デスが発生する場合もあります。 プラグインと競合するか、更新中に特定のファイルが破損した可能性があります。 エラーを確認するか、テーマを交換して問題が解決するかどうかを確認することをお勧めします。 最後の手段として、デバッグを続けながら、デフォルトの WordPress テーマに切り替えることが一時的な解決策になることがあります。

管理者ダッシュボードにアクセスできない場合はどうすればよいですか?

管理ダッシュボードにアクセスしようとしたときに死の白い画面が表示された場合、テーマを変更しても同じ方法は明らかに不可能です.

代わりに、SFTP を使用してサイトのファイルにアクセスできます。

サイトにアクセスしたら、次の手順を実行します。

  1. webroot フォルダーを見つけて、wp-content ディレクトリに移動します。
  2. そこから、「themes」という名前のフォルダーを検索します。 アクティブなテーマの名前を探します。
  3. 次に、テーマのディレクトリ名の後に接尾辞「_old」を追加して、変更を保存します。 WordPress はテーマを無効にします (デフォルトのテーマがインストールされている場合は、デフォルトでそのテーマに切り替えます)。
  4. Web サイトにもう一度アクセスしてみてください。

SSH アクセスがあれば、 WP-CLIを使用してテーマを別のテーマに変更できます。

この例では、テーマ Twenty Twenty-Two に変更されています。

wp theme activate twentytwentytwo --skip-plugins --skip-themes

注:このコマンドは、この変更を行うときにプラグインとテーマの初期化をスキップします。

サイトが再び機能する場合は、WordPress テーマが問題の原因であることがわかります。 その時点で、テーマがまだ積極的に維持されている場合は、修正に取り組めるように、テーマの開発者にこれを報告する時期です. そうでない場合は、通常、別の WordPress テーマに切り替えることをお勧めします。

事後報告 – ホスティングサポートに連絡して予防措置を講じてください

エラーの名前は間違いなく深刻な問題のように見えますが、白い画面しか表示されない場合に WordPress Web サイトを復旧して実行することは、通常、簡単に修正できるエラーです。 それでも問題が解決しない場合は、次のステップとして、 WordPress ホスティングプロバイダーのサポート チームに連絡してください。当社でサイトをホストするという賢明な決定を下した場合は、Servebolt アカウントにログインしてチャットしてください。一緒に問題を解決できるようにお手伝いします。

まだ Servebolt を使用していませんが、経験的に高速なマネージド ホスティングに興味がありますか?

 WordPress を今すぐ Servebolt でお試しください:

    • スケーラビリティ:実際のユーザー ワークロード テストでは、Servebolt は 65 ミリ秒の平均応答時間を実現し、2 番目に優れた製品よりも 4.9 倍高速でした。
    • 世界最速の読み込み時間:全世界の平均ページ読み込み時間は 1.26 秒で、Servebolt は世界の WebPageTest 結果のリストのトップに位置付けられました。
  • 最速のコンピューティング速度: Servebolt サーバーは前代未聞のデータベース速度を提供し、1 秒あたり平均の 2.44 倍のクエリを処理し、PHP を 2.6 倍速く実行します。
  • 完璧なセキュリティとアップタイム:すべてのモニターで 100% のアップタイムがあり、SSL 実装の A+ 評価により、サイトがオンラインで安全であることを保証できます。

当社の専門家チームがすべてサポートし、無料のテスト Bolt を今すぐ試すことができます。