WordPress の死の白い画面: 回復へのガイド

公開: 2023-01-10

WordPress は、MacOS や現在の Windows と同様に、悪名高い「ホワイトスクリーンオブデス」または略して「WSOD」を備えています。 WSOD は、何か問題が発生したときに表示されます。不明な理由で、空白またはほとんど空白の白い画面が表示されます。それで？

WordPress ホワイトスクリーンオブデス (WSOD) とは何ですか?

通常の状態では、WordPress サイトで「死のホワイトスクリーン」 (WSOD) に遭遇することはほとんどありません。これは、WordPress サイトのパブリックフロントエンドまたはバックエンドインターフェイスの代わりに表示される単なる空白の画面です。これは、WordPress がクラッシュして正しく読み込まれないことを意味します。

死の白い画面はおそらく何かの結果ですあなたはあなたのWordPressサイトにしました。

なんで？何がうまくいかなかったのですか？

2019 年 5 月に WordPress 5.2 がリリースされて以来、WordPress には WSOD からユーザーを保護するリカバリモードが用意されています。リカバリモードがなければ、互換性の問題により、多くの WSOD が発生し、WordPress ユーザーが不満を抱くことになります。インストールしているプラグイン、テーマ、または拡張機能でサポートされていないバージョンの PHP または MySQL をサーバーが使用している場合、サイトを壊す代わりに、リカバリモードになります。現在、PHP のメモリ不足 (OOM) エラーは、WSOD 保護をバイパスして完全に空白の画面が表示される最も一般的な残りのシナリオです。

WordPress の中心的な貢献者である Marius Jensen に、現在真の WSOD を引き起こしている他の原因について調べてみました。 Marius は Site Health (現在の Health Check and Troubleshooting) プラグインの作成者であり、そのコンセプトと機能は最終的に WordPress コアに組み込まれました。（これがリカバリモードとその他の保護機能を取得した方法です。）Marius は、完全に空白の画面で WordPress をクラッシュさせる唯一の方法は、PHP の実行フローを中断して、致命的なエラーハンドラーが正常に動作できないようにすることであることを確認しました。 PHP と HTTP サーバー間の接続を切断すると、それが実現します。画面上のトラブルシューティングフィードバックは表示されません。それは苛立たしいことですが、WordPress 内でプラグインのインストールと構成を行っているだけであれば、このようなことはまずありません。

死の白い画面は、WordPress がハッキングされたことを意味しますか?

いいえ、WSOD は悪者があなたを捕まえたという意味ではありません。ただし、まれに、セキュリティ侵害の副作用である可能性があります。ハッカーがサイトを侵害したと思われる場合は、Kathy Zant のガイド、How to Clean a Hacked WordPress Site に進んでください。

WSOD の原因として最も可能性が高いのは、PHP コーディングエラー、2 つ以上のプラグイン間の競合、またはサーバー環境の問題です。幸いなことに、これらは大惨事ではありません。サイトとそのコンテンツは失われていません。必要に応じて、WSOD を自分で修正できます。

この記事では、WSOD の可能性のある診断と治療法のリストを見ていきます。 WordPress サイトを復活させる方法を学びます。また、WordPress がより深いレベルでどのように機能するかについても学びます。

このガイドでは

プレビューを表示

WordPress の死の白い画面: 私はそれをしましたか?

はい。死の白い画面はおそらく何かの結果ですあなたはあなたのWordPressサイトにしました。

WSOD の原因は通常、インストールしてアクティブ化したばかりの WordPress プラグインにあります。または、最近の更新の結果である可能性があります。新しく追加または更新されたプラグインは、別のプラグインと競合している可能性があります。このシナリオでは、1 つのプラグインが別のプラグインと同じことをしようとしているか、矛盾する目的に向かって動作しています。

プラグイン、テーマ、または誤動作している PHP コードスニペットが致命的なエラーを引き起こしている場合、WSOD が発生する可能性があります。構文エラー、バグ、または使用している PHP バージョンと互換性のないコードが含まれている可能性があります。あなたまたはあなたのホストが PHP のバージョンをアップグレードしたばかりなら — これは良いことです! — 互換性のないプラグインはエラーをスローし始め、WSOD でサイトをダウンさせる可能性があります。 WordPress 5.2 以降を使用している場合、非互換性の問題により、真の WSOD よりもはるかに役立つリカバリモードが有効になります。

通常、原因は、プラグイン、テーマ、またはカスタムコードで変更されたばかりのものです。

WSOD は、サイトの機能に影響を与える最後 (またはごく最近) に変更されたものに対する応答であることが多いためです。最近のすべての変更を確認します。問題を引き起こす可能性が最も高いと思われる変更に注目してください。新しいプラグインをインストールしたり、テーマコードを変更したりしたばかりの場合は、最初に何が問題なのかを確認する場所です。

WordPressがほとんど死んだとき

すべての WSOD が同じというわけではなく、真の WSOD ではないものもあります。

完全に白い画面ではなく、何らかのエラーメッセージが表示される場合があります。 HTTP 500 エラーまたは失われたデータベース接続に関するサーバーエラーメッセージである可能性があります。 WordPress からの重大なエラーメッセージである可能性があります。または、訪問者に対してサイトが正常に読み込まれる可能性がありますが、ログインしようとすると、死の白い画面が表示されます. WordPress ダッシュボードにログインできても、サイトのフロントエンドが公開されているため、全員に空白の画面が表示される場合があります。

あなたの WSOD の経験がこれらの説明のいずれかに当てはまる場合は、朗報です。あなたのサイトはほとんど死んでいます。復活させるのは難しくありません。

WordPress サイトにアクセスしたり、ログインしようとしたときに、真っ白な画面が表示される場合は、それが真の WSOD です。何が原因なのかを特定するには、もう少し深く掘り下げる必要があります。

WordPress リカバリモードと死の白い画面

WSOD に直面した人にとって幸いなことに、WordPress 5.2 では復旧モードが導入されて、WSOD が解消されました。回復モードは多くの致命的なエラーをキャッチし、それらを修正するのに役立ちます. WordPress コアの最新のメジャーリリースを使用していない場合は、そこから始めてください。最新情報を入手してください。

WordPress のリカバリモードのおかげで、何か問題が発生したときに完全に空白の画面が表示されることはほとんどありません。 WordPress 6.1 以降では、灰色の画面の上に白いウィンドウが表示され、次のメッセージが表示されることがよくあります。

「あなたのウェブサイトで重大なエラーが発生しました。」 (フロントエンドリカバリモードのスクリーンショット) — _{「あなたのウェブサイトで重大なエラーが発生しました。」} _{(フロントエンドリカバリモード)}

古いバージョンの WordPress では、「サイトで技術的な問題が発生しています」などの同様のメッセージが表示されます。

バックエンドの/wp-admin URL を参照すると、詳細について管理者の電子メールアカウントを確認するように指示する通知も表示されます。

「このウェブサイトで重大なエラーが発生しました。 WordPress のトラブルシューティングの詳細をご覧ください。」 (バックエンドリカバリモードのスクリーンショット) — _{「このウェブサイトで重大なエラーが発生しました。} _{WordPress のトラブルシューティングの詳細をご覧ください。」} _{(バックエンドリカバリモード)}

また、サイトを修復するための何らかの説明とガイダンスとともに、「内部サーバーエラー」を説明する太字のテキストが表示された白い画面が表示される場合もあります。

回復へようこそ

これがリカバリーモードです。 WordPress は、あなたが立ち直れるように手助けしようとしています。

最初に行うことは、WordPress 管理者アカウントに関連付けられているメールアドレスを確認することです。 WordPress は、実行中のすべてのコードで致命的な PHP エラーを特定しようとします。

可能であれば、WordPress は誤動作しているプラグインやその他のコードを「一時停止」します。 WordPress は、悪いコードが実行されないようにします。その後、メールで管理者に詳細を報告します。

リカバリモードのメールには、リカバリモードで WordPress にログインするための手順と一時的なリンクが記載されています。 (このリンクは 24 時間有効です。その後、サイトでまだ重大なエラーが発生している場合は、新しいリンクが送信されます。)

プロからのヒント:リカバリモードのメールが届かない場合でも、管理者としてログインしているときに次のアドレスをベースサイト URL に追加することで、リカバリモードで WordPress にログインできる場合があります: /wp-login.php?action=entered_recovery_mode .

これは、さらに調査する機会です。リカバリモードが特定のプラグインを WSOD の原因として特定した場合は、それを無効にします。これにより、あなたのサイトは誰にとっても元に戻ります. 次に、このプラグインの既知の問題を調査できます。アップデートがあるかどうかを確認してください。それを維持する責任者に連絡してください。

WordPressのすべての白い死の画面が同じというわけではありません

いくつかの例外的なケースとして、WordPress またはサーバー環境のどこかで問題が発生したことがあります。更新またはインストールプロセスが停止し、サイトがメンテナンスモードのままになっている可能性があります。あなた、ホスティングプロバイダー、またはインストールしたプラグインによって、 php.iniまたは.htaccessファイルが変更され、予期しない結果が生じた可能性があります。既存の環境は、新しくインストールされたプラグインの要件をサポートしていない可能性があります。

WordPress リカバリモードはこれらの状況に対処できませんが、白い画面にエラーメッセージが表示されます。サイトのフロントエンドにはアクセスできない可能性がありますが、管理者ログイン画面とバックエンドインターフェースは正常に動作している可能性があります。

これらは真の WSOD 状況ではありませんが、同様に厄介です。通常、次の条件のいずれかが原因で発生します。

1. メンテナンスモードで立ち往生している

WordPress コア、プラグイン、またはテーマを更新している間、WordPress は「メンテナンスモード」になります。サイトのどの部分を参照しても、灰色の画面に次のような白いメッセージウィンドウが表示されます。

「定期メンテナンスのため一時的にご利用いただけません。しばらくしてからもう一度確認してください。」 (WordPressメンテナンスモードのスクリーンショット) — _{「定期メンテナンスのため一時的にご利用いただけません。} _{しばらくしてからもう一度確認してください。」} _{(WordPressメンテナンスモード)}

これはすぐに解決しない場合もありますが、品質管理された WordPress ホスティングはこれに気づき、自動化されたプロセスで修正します. 数分間待っても変更がない場合は、WordPress がインストールされている web/application ルートフォルダーにある.maintenanceファイルを削除することで、メンテナンスモードを終了できます。 (表示するには、ファイル名のピリオドで始まる「非表示」ファイルの表示を有効にする必要がある場合があります。)

.maintenanceファイルが存在しない場合、サイトは期待どおりに読み込まれます。

2.ファイルのアップロードまたは投稿のサイズ制限に達した

送信するデータが多すぎるため、アップロード、公開後、またはフォーム送信プロセスでサイトが白い画面でタイムアウトする場合があります。

解決策: wp-config.phpで投稿コンテンツの制限を増やします:

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

解決策: php.iniでファイルのアップロードと投稿のサイズ制限を増やします。

 upload_max_filesize = 256M
post_max_size = 256M

投稿またはフォームの送信がタイムアウトするまでの時間 (秒単位) を延長することも役立つ場合があります。 PHP がスクリプトを実行して入力を解析する時間を増やすこともできます。さらに、フォーム送信で許可される変数の数を増やすことができます。最後に、PHP が送信されたデータをガベージとして処理するまでの時間制限を指定できます。

 最大実行時間 = 300
最大入力時間 = 300
最大入力変数 = 1000
session.gc_maxlifetime = 1000

または.htaccess 、 httpd.conf 、またはvirtualhostで:

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value session.gc_maxlifetime 1000

または、WordPress またはテーマのfunctions.phpファイルのカスタムコードスニペットで:

 @ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000');
@ini_set('session.gc_maxlifetime', '1000');

これらのパラメーターのメモリと時間の値は、単なる推奨事項です。それらが機能していることを確認し、現在の値を確認するには、WordPress 管理インターフェイスのサイトヘルスツールを使用します。

リカバリーモードと共に、WordPress 5.2 はサイトヘルスツールを導入しました。 問題を診断したり、サイトの設定やサーバー環境に関する技術情報を取得したりするのに非常に役立ちます。 [ツール] > [サイトの健全性] の下にある管理者メニューで見つけてください。 WordPress のヘルスチェックとトラブルシューティングプラグインの拡張機能を利用することもできます。

3. PHP のメモリ不足

PHP は、WordPress コアのベースとなっているサーバー側スクリプト言語です。 PHP が WordPress とアクティブなプラグインを実行するのに十分なメモリがない場合、WSOD が表示されます。これは、エラーメッセージまたはログに示される場合があります。

ホスティングプランによっては、サーバー上のすべてのアプリケーションまたは WordPress の特定のインスタンスの PHP メモリ制限を増やすことができる場合があります。どうすればよいかわからない場合は、ホストのテクニカルサポートチームにお問い合わせください。

wp-config.php

通常、WordPress フォルダー内のwp-config.phpファイルに次の設定を追加すると、この例では WordPress のフロントエンドメモリ制限が 256 MB に設定されます。

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

128 ～ 256 MB で十分です。次の行をwp-config.phpに追加することで、PHP に割り当てられる最大またはバックエンドメモリ (次の例でも 256 MB) を定義することもできます。

 define('WP_MAX_MEMORY_LIMIT', '256M');

2 番目の数値は、PHP が使用できるメモリの合計を定義する最大メモリ制限です。最初の数字は、より大きな PHP 制限内で実行される WordPress のメモリです。 PHP メモリの最大制限は、WordPress アプリケーションのメモリ制限以上である必要があります。

php.ini

PHP の最大メモリ制限を定義する別の方法は、WordPress フォルダーにあるphp.iniファイルの設定を使用することです。

 メモリ制限 = 256M

行の先頭にセミコロンがないことを確認してください。 また、php.ini は、 php.iniファイルが配置されているフォルダー内またはフォルダーの下で実行されている WordPress (またはその他の PHP アプリケーション) のインスタンスにのみ影響を与えることに注意してください。サーバーまたは Web ルートにアクセスできる場合は、 php.ini php.iniそこにあるphp.iniファイルは、異なる条件を指定する独自のphp.iniファイルがない限り、すべてのPHP アプリケーションの環境設定を管理します。

.htaccess

HTTP サーバーとして Apache または Litespeed を使用している場合、PHP メモリ制限を定義する 3 つ目の方法は、WordPress フォルダー内の.htaccessファイルを使用することです。上記の例のように、PHP の最大制限を 256 MB に設定するには、.htaccess に次のようなコメントを外した行が必要です。

 php_value メモリ制限 256M

wp-config.php 、 php.ini 、および.htaccessのアプリケーションおよびサーバー設定の構文エラーも、WSOD の原因となる可能性があります。それらがサイトを破壊している場合は、手動で修正するか、元のデフォルトに置き換える必要がある場合があります。 Apache または Litespeed Web サーバーを使用している場合、それらの動作を管理する.htaccessファイルは、多くの WordPress プラグインによって変更される可能性があります。 これらのファイルのいずれかにエラーが発生すると、WSOD が発生し、サイトがダウンする可能性があります。

4. HTTP サーバーがクラッシュしている

HTTP (またはその暗号化された安全な形式の HTTPS) は、Web サーバーを Web サーバーにするハイパーテキスト転送プロトコルです。これは、要求に応じてサーバーが Web ページ (HTTP ドキュメント) をクライアント (ブラウザーなど) に提供する方法です。

WordPress サイトで一般的に使用される HTTP サーバーは、Apache、Litespeed、および NGINX です。これらのエラー画面の外観はわずかに異なり、ブラウザによって表示される方法も異なる場合がありますが、レポートされる HTTP エラーコードはすべて同じです。

内部サーバーエラーとも呼ばれる HTTP 500 エラーは、HTTP サーバーに予期しない問題があり、HTTP 要求の実行を妨げていることを示します。その他の 5xx サーバーエラーコード、特に 502 (Bad Gateway)、503 (Service Unavailable)、および 504 (Gateway Timeout) は、サーバーが過負荷またはアクセス不能であることを示します。 500 内部エラーは、要求されたページ/ドキュメントを返すのを停止するサーバー上の故障の包括的なものです。

お使いのブラウザは、独自の HTTP エラー画面を提供し、独自の特別なエラーコードを表示する場合があります。 Google Chrome (およびその他の Chromium ベースのブラウザー) は、Chrome の使用中にアドレスバーでchrome://network-errors/を参照すると、すべての独自のエラーコードを内部的に一覧表示して説明します。

サーバー側の問題

WordPress サイトで一般的に使用される HTTP サーバーソフトウェアには、Apache、Litespeed、および NGINX が含まれます。多くの WordPress ホストは、キャッシュを使用してパフォーマンスを最大化しています。

ブラウザーをハードリフレッシュしたり、ブラウザーの Cookie とキャッシュをクリアしたりしても 500 エラー画面が解消されない場合は、サーバー側のキャッシュファイルに問題がある可能性があります。サーバー側のキャッシュは、うまく機能していないときに多くの混乱を引き起こす可能性があるため、クリアすることも試してください。ホスティングコントロールパネルまたは WordPress 管理インターフェイスには、キャッシュクリアコントロールがある場合があります。

HTTP 500 エラーの一般的な原因には、次のサーバー側の条件が含まれる場合があります。

PHP メモリの制限を超えました。
PHP がエラーを表示するように設定されていない場合のその他の PHP エラー。
サーバーのファイルとフォルダーにアクセスするための十分な権限がありません。
.htaccess 構成ファイルの構文エラー。

PHP のメモリ制限とその増加方法については既に説明しました。以下の次のセクションでは、PHP のデバッグについて詳しく説明します。

不適切なアクセス許可は、最新の管理 WordPress ホスティングでは発生しないはずですが、従来の共有ホスティングでは一般的です。ファイルは 664 または 644 に設定し、フォルダーは 775 または 755 に設定し、wp-config.php は 660、600、または 644 に設定する必要があります。

.htaccess ファイルに変更を加えた場合、またはそれを変更するプラグイン (多くの場合またはキャッシュ) を使用している場合は、エラーがないか確認し、復元するか、新しい動作する .htaccess ファイルを再作成する必要があります。 WordPress.org で.htaccessの詳細をご覧ください。

クライアント側の問題

HTTP 500 エラーは、他の条件によってクライアント側 (ブラウザー内) で発生することもあります。

ブラウザの設定が正しくありません。
破損したキャッシュ。
ブラウザで実行される破損した JavaScript ファイル。
インターネット接続の問題。

現在のブラウザを問題から除外するために、サイトを別のブラウザに読み込んでみてください。ブラウザに問題がある場合は、デフォルト設定にリセットしてみてください。インストールしたブラウザー拡張機能やプラグインを無効にして、サイトとのやり取りがうまくいかないかどうかを確認します。

問題が不正なキャッシュファイルに関連している場合、キャッシュされていない WordPress 管理領域に引き続きアクセスできる可能性があります。それでも WordPress 管理インターフェイスにログインできる場合は、そこでキャッシュクリアスイッチを使用するか、以下で説明する追加のトラブルシューティング手順を試すことができる場合があります。

HTTP 500 エラーは、データベースの問題、WordPress サイトのプラグインまたはテーマの問題、または WordPress 自体の問題によって引き起こされる可能性もあります。

HTTP 500 エラーのトラブルシューティングを行うには、HTTP サーバーと PHP のエラーログを有効にする必要があります。次に、両方に表示されるエラーを確認します。また、PHP のメモリ制限を確認して増やしたり、プラグインを無効にしたり、デフォルトのテーマに切り替えたりして、これらのアクションのいずれかでサイトが元に戻るかどうかを確認することもできます。

これらの手順については、以下で詳しく説明します。これらの手順に従っても 500 エラーが解消されない場合は、ウェブホストのサポートチームに連絡してサポートを受けてください。

WordPress が本当に死んだとき

WordPress サイトのすべてのフロントエンドページとバックエンドページで完全に白い画面が表示され、エラーフィードバックがまったく表示されない場合、それは完全な WSOD エクスペリエンスです。 PHP エラーログと HTTP サーバーログにアクセスする方法を知っていれば、エラーメッセージと診断情報を取得できます。別のオプションとして、WordPress の PHP デバッグを有効にすることもできます。ホストには、デバッグをよりアクセスしやすくするためのツールがいくつかある場合があります。しかし、そうでない場合は、解決策が見つかるまで、一般的な WSOD の治療法のリストをたどることができます。

WordPress の死のホワイトスクリーンのトラブルシューティングと修正のためのマスターチェックリスト

WordPress ホワイトスクリーンオブデスを修正するには、次の手順を実行すると解決策が得られます。これらは、私が経験した最も一般的な WSOD の原因の順に整理されていますが、任意の順序で試すことができます。

特定の状況に最も関連すると思われる解決策を優先することが最も理にかなっています。

エラーのログ記録とデバッグのステップ (#2) は最も技術的ですが、徹底しており、WordPress が終了する原因を常に教えてくれます。

便利な診断および修復ツールとなるいくつかの無料プラグインへのリンクを提供しました。また、iThemes Security は、データベースのスキャンと修復機能、およびファイル変更の検出に特に役立ちます。サーバーの設定と機能を詳しく調べるためのサーバーツールもあります。

最後の手段として、適切な最新のバックアップにより、サイトが最後に確認された良好な状態にオンラインに戻ります。 Backup Buddy は、この役割に最適なプラグインです。

ブラウザのキャッシュと Cookie をクリアする

ブラウザやサーバーにキャッシュされたサイトのページは、実際に起こっていることとは異なることを示している可能性があります。 WordPress がサイトへの新しい訪問者をどのように表示しているかを確認してみましょう。

まず、ブラウザのキャッシュと Cookie をクリアします。 WordPress やその他のサイトにログインしている場合、これによりユーザーセッションが終了するため、他の訪問者と同じように閲覧できます。

次に、ホスティングパネルと WordPress 管理者 (利用可能な場合) を使用して、ホストと WordPress キャッシュプラグインが作成しているサーバー側のキャッシュをクリアします。サイトとサーバーのキャッシュをすべてオフにしてみてください。ブラウザでハードリフレッシュを実行します。これで問題が解決する場合は、システムで動作していないキャッシュ設定が有効になっている可能性があります。排除のプロセスを通じて、どれが機能し、どれが機能しないかを識別できます。

2. PHP エラーを探す

WordPress コア、テーマ、またはプラグインの PHP コードは、WordPress がホワイトスクリーンオブデスでゴーストを諦めさせる致命的なエラーを生成する可能性があります。

致命的な PHP エラーとその原因に関する詳細情報を取得するには、PHP エラーレポートを有効にして、画面、ログファイル、またはその両方に送信します。致命的なエラーは、WSOD の原因を示している可能性があります。

PHP ベースの Web アプリケーションである WordPress には、デバッグ用の独自の診断レポートシステムがあり、PHP のエラーログ機能を利用するのに役立ちます。オンにして制御するには、 wp-config.phpに次の行があることを確認してください。

 define('WP_DEBUG', true);

これを追加するか、値を false から true に変更する必要がある場合があります。これは WordPress に PHP デバッグを有効にするように指示します。

WP Debugging プラグインをインストールしてアクティブ化することで、ショートカットを作成することもできます。 wp-config.phpを自分で直接変更しなくても、WordPress の PHP デバッグが有効になります。

以下に示す追加のwp-config.phpパラメータは、デバッグ出力を HTML として画面に出力し、デフォルトで「error_log」という名前のファイルを出力します。

 define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );

また、WordPress が最適化されていないバージョンの CSS と JavaScript の依存関係を使用するように強制することも、それらが問題を引き起こしている可能性が低い場合に役立つ場合があります。

 define( 'SCRIPT_DEBUG', true );

Debug Bar プラグインは、便利な追加の補完ツールです。素敵なインターフェイスでデバッグデータが表示されます。

これを行うには、 php.iniに、 error_reporting = E_ALLのように、 error_reporting定数にNONE以外の値を指定する行が必要です。この行の先頭にセミコロンがあってはなりません。これにより、アクティブな設定ではなくコメントになります。 E_ALLを使用すると、すべてのPHP エラー、警告、通知が表示されることに注意してください。 E_ERRORのような別の値を使用して、WordPress をクラッシュさせる致命的な実行時エラーのみをログに記録します。

3.テーマとプラグインの競合を確認する

前の手順で説明したように PHP エラーをデバッグすると、WSOD のソースとして明確なテーマまたはプラグインファイルが示されます。また、技術的ではない除去プロセスのアプローチでそれに近づくこともできます.

テーマのトラブルシューティング

ホワイトスクリーンオブデスは、多くの場合、WordPress のテーマやプラグイン間の競合によって引き起こされます。競合の原因を特定するには、すべてのプラグインを無効にして、Twenty Twenty-Three などの WordPress コアを備えた現在の変更されていないデフォルトのテーマパッケージに切り替えてみてください。

テーマから始めます — テストするのが最も簡単です。アクティブなテーマを既知の変更されていない既定のテーマに切り替えて、サイトがオンラインに戻った場合は、使用しているテーマに問題があることがわかります。

テーマのfunctions.phpファイルがある場合は、それを見てください。最近変更した場合は、それが問題の原因である可能性があります。 functions.phpファイルは、テーマがアクティブ化されたときに使用するカスタム関数コードが追加される場所です。ここで不適切なコードと構文エラーが発生すると、WSOD が発生します。

プラグインのトラブルシューティング

/wp-content/plugins/フォルダーからプラグインフォルダーを一時的に移動するだけで、コマンドライン/SSH または SFTP を介して WordPress 管理者にアクセスせずにプラグインを非アクティブ化できます。私の習慣は、「A」という名前のプラグインサブフォルダーを作成して、アルファベット順に並べ替えられた/pluginsディレクトリの最初に表示されるようにすることです。次に、他のすべてのプラグインフォルダーを「A」に移動します。

これが完了したら、サイトをリロードします。 WordPress は、プラグインがすべてなくなったかのように動作します。それらはまだインストールされていますが、非アクティブ化されています。ホワイトスクリーンオブデスが消えたら、プラグインとテーマを 1 つずつ再アクティブ化し、毎回ホームページを更新して、サイトがクラッシュする原因を確認します。

Meks Quick Plugin Disabler は、すべてのアクティブなプラグインをすばやく無効にしてから、WordPress 管理画面からコマンドで再度有効にする便利なツールです。

4.破損したコアファイルを修復する

WSOD は、破損したコア WordPress ファイルの結果である可能性があります。これはありそうもないことですが、WordPress ダッシュボードの更新領域でワンクリックするだけで、WordPress の最新バージョンをすばやく簡単に再インストールできます。これにより、プラグイン、テーマ、または既存のコンテンツが損なわれることはないため、コアファイルに問題がないことを簡単に確認できます。

上記の手順のいずれも役に立たない場合、WSOD は、手の届かないサーバー環境の問題が原因である可能性があります。この場合、ホスティングプロバイダーに連絡して支援を求める必要がある場合があります。最後の手段として、バックアップを復元することで、サイトを「最後に既知の良好な」状態にロールバックすることもできます。

WSOD を防ぐ方法 — WordPress サイトの所有者とビルダーへのアドバイス

WordPress は問題なく動作していましたが、突然死の白い画面が表示されました。

これはおそらく、あなたが WordPress の機能にとって重要なものを変更したためです。

しっかりと管理された WordPress ホスティングアカウントを Liquid Web または Nexcess で使用し、それを使用して行うことに対して十分なリソースで適切に構成されている場合、WSOD で WordPress を壊す可能性のある方法の 99% を回避できます。

問題は、サイトの所有者がこれらの慣行を避けていないことです!

してはいけないこと

カウボーイコーディング。 SFTP、コマンドライン、または WordPress 管理画面内のコードエディターとスクリプトインサーターを使用して、ライブサイトで機能コードを追加または編集します。ちょっとしたミスでサイトがダウンしてしまいます。 .htaccessやwp-config.phpなどの構成ファイルを変更すると、サイトがダウンすることもあります。代わりに、ローカルのテストまたはライブ (公開ではない) ステージングサイトで作業してください。
疑わしいテーマ、プラグイン、および拡張機能のインストール。 稼働中のサイトに低品質またはゼロのソフトウェアをインストールすると、トラブルが発生します。一度に追加しすぎると、最終的に破壊的な変更が何かを判断するのが難しくなります。カウボーイコーディングと同様に、ライブサイトに新しいコード製品をインストールするのは危険です。まず、プライベートローカルサイトまたはステージングサイトで十分にテストします。
複雑なキャッシング。 ホストが提供する可能性のあるサーバー側のキャッシュにはいくつかの種類があり、すべてのキャッシュおよびパフォーマンス最適化プラグインではうまく機能しない可能性があります。新しいキャッシュ方法または設定を実装する場合は、ライブサイトに変更を実装する前に、ローカルおよびステージング環境で慎重にテストしてください。
一度にすべてを更新します。 多くのテーマとプラグインを一度に一括更新できます。通常、これは機能しますが、サーバーがタイムアウトした場合、メンテナンスモードでスタックする可能性があります。また、新しく更新されたコードによって、新しいバグ、競合、または互換性の問題が発生する可能性があります。これが発生してサイトがダウンした場合、問題の原因を特定するのが難しくなります。複数のテーマ、プラグイン、および拡張機能を一度に更新した場合、アイテムの数はいくつでもかまいません。更新されたコードは、メインの公開サイトにロールアウトする前に、ローカルおよびライブステージングサイトでテストできます。

WSOD のない生活を送るためのヒント

WSOD はどの WordPress サイトでも発生する可能性がありますが、心配する必要はありません。このガイドのヒントに従うことで、問題を特定し、サイト訪問者が気付く前にすばやく修正することができます。

WordPress サイトの問題は、適切なメンテナンスとケアの重要性を強調しています。 WSOD に対応するよりも、訪問者にエラーメッセージや空白の画面が表示されないように、WordPress で作業する方法を学ぶことができます。

変更は慎重かつ慎重に行ってください。ローカルのテスト環境またはステージング環境で潜在的な WSOD に対処します。これらは、現在管理されているほとんどの WordPress ホストの標準的なツールと機能です。これらの基本的なベストプラクティスに従えば、WordPress ホワイトスクリーンオブデスについて心配する必要はありません。

WordPress を安全に保護するための最高の WordPress セキュリティプラグイン

WordPress は現在、すべての Web サイトの 40% 以上で使用されているため、悪意のあるハッカーにとって格好の標的となっています。 iThemes Security Pro プラグインは、WordPress のセキュリティから当て推量を取り除き、WordPress Web サイトを簡単に保護および保護できるようにします。これは、WordPress サイトを常に監視して保護するフルタイムのセキュリティ専門家がスタッフにいるようなものです。

iThemes Security Pro を入手

ダン・ナウス

Dan Knauss は、StellarWP のテクニカルコンテンツジェネラリストです。彼は 1990 年代後半からオープンソースで、2004 年からは WordPress で、ライター、教師、フリーランサーとして働いています。