WordPress の死の白い画面を修正する方法
公開: 2024-03-22WordPress ホワイト スクリーン オブ デス (WSOD) は、WordPress サイトにアクセスしようとしたときに空白の白い画面として現れる重大なエラーであり、問題の原因を示唆するエラー メッセージは表示されません。 この問題は Web サイト全体に影響する場合もあれば、WordPress 管理ダッシュボードなどの特定のセクションに限定される場合もあり、診断プロセスが複雑になります。 WSoD は表面上の手がかりを提供しないため、特に困難です。 根本的な問題は、プラグインの競合やテーマのエラーから、PHP のメモリ制限の枯渇、さらには WordPress コア ファイルの破損にまで及ぶ可能性があります。
このブログでは、WSOD の性質を理解するために必要な基本的な理解から、WSOD の出現につながる可能性のある特定のトリガーに至るまで、すべてを取り上げます。 また、Web サイトを復活させるのに役立つ一般的なソリューションと技術的なソリューションの両方についても詳しく説明します。
死の白幕とは
WordPress ホワイト スクリーン オブ デス (WSOD) は、エラー メッセージが表示されずに完全に空白の白い画面が表示される重大なエラーであり、Web サイトの所有者や開発者にとって特に複雑で困難な問題となっています。 このエラーは、一般公開ページと管理ダッシュボードの両方を含む WordPress サイトのあらゆる部分で発生する可能性があり、事実上ユーザーがロックアウトされ、コンテンツへのアクセスや管理ができなくなります。
WSOD は、プラグイン間の競合、WordPress の現在のバージョンと誤動作または互換性がないテーマから、Web サイトの PHP メモリ制限割り当てなどのよりシステム的な問題まで、さまざまな問題によって引き起こされる可能性があります。 本質的に、WSOD は、WordPress で発生した PHP エラーまたはデータベース エラーの症状であり、適切な方法で回復できず、画面上に表示されるコンテンツが完全に欠如する原因となります。
WSOD の性質を考えると、特にトラブルシューティング プロセスに役立つ直接的なフィードバックやエラー メッセージが提供されないため、WSOD の正確な原因を診断するのは難しい場合があります。 問題の原因を特定するには、根底にある問題を特定して解決するための系統的なアプローチが必要です。これには次のことが含まれます。
- プラグインの無効化
- テーマの切り替え
- PHPのメモリ制限を増やす
- WordPress ファイルのデバッグ。
問題のバリエーション
WSOD は、根本的な原因と WordPress サイトがホストされている環境に応じて、いくつかの方法で現れる可能性があります。 バリエーションには次のようなものがあります。
- 画面が真っ白になり、エラー メッセージも表示されないため、問題を特定するのが困難になります。
- 断続的に白い画面が表示され、サイトが正しく読み込まれることもありますが、失敗することもあります。
- 白い画面は WordPress サイトの特定の領域 (wp-admin 領域など) にのみ影響し、サイトの残りの部分は正常に機能します。
- WSOD は、新しいプラグインのインストール、WordPress バージョンの更新、またはテーマの更新後に表示されます。
このエラーが発生する理由
WSOD はいくつかの要因によって引き起こされる可能性があり、それぞれに独自の課題と解決策があります。
プラグインの競合: WSOD の最も一般的な原因の 1 つは、プラグイン間の競合です。サイトにインストールされている 2 つ以上のプラグインが相互の操作を干渉すると、白い画面が表示されることがあります。
テーマの問題: テーマの欠陥、またはテーマとプラグイン間の競合も WSOD の原因となる可能性があります。これは、新しいテーマをインストールした後、または既存のテーマを更新した後によく発生します。
PHP メモリ制限の枯渇: WordPress サイトが効率的に動作するには、一定量のメモリが必要です。サイトが割り当てられた PHP メモリ制限を超えると、WSOD が発生する可能性があります。
破損したコア ファイル: WordPress のコア ファイルは、不完全な更新や外部改ざんなどのさまざまな理由で破損し、WSOD が発生する可能性があります。
WordPress の死の白い画面を修正する方法
WordPress の死の白画面に遭遇した場合は、迅速に解決することが最優先事項になります。 それでは、この問題に正面から取り組むために採用できる主な戦略を見ていきましょう。
すべてのプラグインを無効化します
WSoD の背後にある最も一般的な原因の 1 つは、不正な動作をするプラグインです。 プラグインは WordPress サイトに機能を追加しますが、更新後に相互に競合したり、WordPress 自体と競合したりする可能性もあります。 すべてのプラグインを非アクティブ化すると、プラグインが WSoD の原因であるかどうかを判断するのに役立ちます。 これは、複雑な問題を対処可能な問題に変える消去法です。 問題を特定して解決する方法を見てみましょう。
WordPress 管理者経由
- WordPress ダッシュボードにアクセスできる場合は、「プラグイン」セクションに進みます。
- 「インストールされたプラグイン」メニューをクリックします。
- Pluginの横にあるリストの上部にあるボックスをチェックして、すべてのプラグインを選択します。
- [一括アクション]ドロップダウン メニューから[非アクティブ化]を選択します。
- 「適用」をクリックします。この操作により、すべてのプラグインが一度に無効になります。
FTP経由
管理領域からロックされていても、心配する必要はありません。 FTP クライアントがバックドアになる可能性があります。
- FTP クライアントを開き、Web サイトに接続します。
- wp-contentフォルダーに移動します。
- plugins フォルダーを見つけて名前を変更します。plugins_deactivatedのようなものが機能します。 これにより、WordPress がプラグインを見つけられなくなり、すべてのプラグインが無効になります。
すべてのプラグインを無効化したら、サイトに再度アクセスしてください。 問題が復活した場合は、おめでとうございます。プラグインの問題が切り分けられています。 次のステップは、問題の原因となっている正確なプラグインを見つけることです。
問題のあるプラグインを特定する
どのプラグインが問題の原因となっているかを特定するには、プラグインを一度に 1 つずつ再アクティブ化する必要があります。
- サイトにアクセスできるようになった場合は、各プラグインを一度に 1 つずつ再アクティブ化します。 プラグインを有効化した後、Web サイトを更新します。 WSoD が再び表示された場合は、犯人が見つかったことになります。
- サイトが利用できない場合は、FTP 経由でこれを行う必要があります。plugins_deactivatedフォルダーの名前をpluginsに戻します。次に、その中にある各プラグイン フォルダーの名前を 1 つずつ変更し、名前を変更するたびにサイトを確認します。 WSoD が返されると、問題のあるプラグインが特定されます。
問題のあるプラグインを特定したら、プラグイン開発者にサポートを求めるか、WordPress プラグイン ディレクトリでアップデートや他のユーザーが報告した同様の問題を確認することができます。
デフォルトのテーマに切り替える
つまり、プラグインのルートを試してみましたが、死の白画面 (WSoD) が依然として WordPress サイトにつきまとっています。 WordPress テーマはサイトの外観とレイアウトを制御しますが、コードの競合や互換性の問題が発生する可能性もあります。 デフォルトのテーマ (Twenty Twenty-One など) に切り替えると、現在のテーマが WSoD の原因であるかどうかを判断するのに役立ちます。 この手順では基本的に、サイトのビジュアル デザインの側面が安定した競合のない状態にリセットされ、問題をより正確に診断できるようになります。
WordPress 管理者経由
WordPress 管理ダッシュボードにアクセスできる場合:
- [外観] > [テーマ]に移動します。
- WordPress が提供するデフォルトのテーマ (Twenty Twenty-One や Twenty Twenty など) の 1 つを探し、 「有効化」をクリックします。これらのテーマは、安定性と互換性で知られています。
- デフォルトのテーマをアクティブ化した後、サイトに再度アクセスしてください。 通常の状態に戻った場合は、以前のテーマに問題があった可能性があります。
FTP経由
管理ダッシュボードにアクセスできない場合は、FTP が使用するルートになります。
- FTP クライアントを使用してサイトに接続します。
- wp-contentディレクトリに移動し、テーマ フォルダーを見つけます。
- 現在のテーマのフォルダーの名前を変更します。 このアクションにより、WordPress はサイトにインストールされている最新のデフォルトのテーマに強制的に戻されます。
- 利用可能なデフォルトのテーマがない場合は、WordPress テーマ ディレクトリからテーマをダウンロードし、テーマ フォルダーにアップロードすると、WordPress が自動的にそのテーマに切り替わります。
サイトがデフォルトのテーマで稼働すると、元のテーマが問題の原因であることがわかります。 それはほろ苦い啓示ではありますが、解決に近づくきっかけとなるものです。
テーマ関連の問題への対処
サイトがデフォルトのテーマで運用されている場合は、次のアクションを検討してください。
テーマを更新または再インストールする: テーマに利用可能な更新があるかどうかを確認します。アップデートにより問題が解決される可能性があります。 更新しても問題が解決しない場合は、テーマを再インストールしてみてください。
テーマ開発者に連絡する: 問題が解決しない場合は、テーマ開発者に連絡するのが良いでしょう。問題を解決するための修正やガイダンスが提供される場合があります。
テーマの切り替えを検討する: 場合によっては、別れることが最善の場合もあります。テーマが引き続き問題を引き起こし、解決策が見当たらない場合は、安定した美しい Web サイトを実現するには、他のテーマを検討することが最善の策である可能性があります。
キャッシュの消去
Web ブラウザーは Web サイトのキャッシュされたバージョンを保存し、次回の訪問時に Web サイトをより速く読み込むことができます。 ただし、キャッシュされたバージョンが古いか破損している場合は、WSoD が表示される可能性があります。 キャッシュをクリアすると、サーバーから Web ページの最新バージョンが強制的に取得され、表示の問題が解決される可能性があります。
ブラウザのキャッシュをクリアする
- ブラウザの設定または環境設定メニューを開きます。
- 「プライバシーとセキュリティ」または同様のセクションを探します。
- 閲覧データまたはキャッシュをクリアするオプションを見つけます。これは、[履歴]や[データ管理]などのサブメニューにある場合があります。
- キャッシュされた画像とファイルをクリアすることを選択していることを確認してください。 通常は時間範囲を選択できます。 すべてを確実にクリアするには、 [常時]を選択するのが良い方法です。
- ブラウザのキャッシュをクリアするアクションを確認します。
WordPress キャッシュプラグインによるキャッシュのクリア
キャッシュ プラグインはブラウザ キャッシュと同様の目的を果たしますが、サーバー側で Web サイトの静的バージョンを保存してサーバーの負荷を軽減し、パフォーマンスを向上させます。 ただし、ブラウザーのキャッシュと同様、このデータが古いか破損している場合は、WSoD が発生する可能性があります。 キャッシュ プラグインを通じてキャッシュをクリアすると、Web サイトで最新のコンテンツが確実に提供されます。
キャッシュをクリアするには:
- WordPress ダッシュボードに移動します。
- 設定に移動。ここでは、オプションの 1 つとしてキャッシュ プラグインを選択します。 それを選択してください。
- [キャッシュの削除]ボタンまたは同様のオプションを探します。
- キャッシュをクリアした後、サイトに再度アクセスして、問題が解決したかどうかを確認してください。
別のキャッシュ プラグインを使用している場合、手順は似ていますが、キャッシュをクリアするオプションが WordPress ダッシュボードのプラグインの専用タブまたはメニューの下にある場合があります。 ほとんどのキャッシュ プラグインでは、多くの場合 1 ～ 2 回のクリックでキャッシュを簡単にクリアできます。
10Web ダッシュボードからキャッシュをクリアする
10Web ユーザーの場合、ダッシュボードからキャッシュをすばやく簡単にクリアできます。
- WSoD を表示している Web サイトをクリックします。
- [Web サイト ブースター] > [設定]に移動します。
- 「キャッシュのクリア」をクリックして、 Web サイト全体のキャッシュを削除します。
デバッグを有効にする
WordPress のデバッグ モードは、通常は非表示になる PHP エラー、通知、警告を表示するように設計されています。 これは、サイトの問題を診断する場合、特に WSoD に直面した場合に非常に役立ちます。 特定のエラーを明らかにすることで、プラグイン、テーマ、またはカスタム コード スニペットに問題があるかどうかを理解できます。
デバッグを有効にする方法
- FTP クライアントまたは Web ホスティング コントロール パネルのファイル マネージャーを使用して、WordPress サイトのファイルにアクセスします。
- WordPress のルート ディレクトリでwp-config.phpファイルを見つけます。このファイルには、WordPress の重要な設定が含まれています。
- 「define( 'WP_DEBUG', false );」という行を探します。。 存在する場合は、falseをtrueに変更します。存在しない場合は、次を追加します。
- 定義( 'WP_DEBUG', true );
- ファイルの先頭、<?phpタグのすぐ下に追加します。
- ローカルで編集した場合は、変更を保存し、ファイルをサーバーにアップロードして戻します。
もう一度サイトにアクセスしてください。 空白の白い画面の代わりに、問題の原因を示すエラー メッセージが表示されるはずです。
エラーメッセージの解釈
デバッグを有効にすると、プラグインやテーマの関数の競合など、問題を直接示すメッセージが表示される場合があります。 これらのメッセージには通常、問題のあるファイルへのパスと行番号が含まれているため、エラーの正確な原因を簡単に特定できます。
例えば：
- エラーがプラグインのフォルダー内のファイルを指している場合は、その特定のプラグインを非アクティブ化すると問題が解決します。
- テーマ内に問題があることを示している場合は、デフォルトの WordPress テーマに切り替えると解決する可能性があります。
あるいは、エラー ログを参照することもできます。 Web サイトが 10Web でホストされている場合は、10Web ダッシュボードからエラー ログにアクセスできます。 10Web ダッシュボードにログインし、WSoD のある Web サイトをクリックして、 「ホスティング サービス>ログ」に移動するだけです。
PHPのメモリ制限を増やす
WordPress は PHP で書かれているため、コードを実行するにはメモリが必要です。 サイトに割り当てられた PHP メモリが不十分な場合、WSoD が発生する可能性があります。 PHP のメモリ制限を増やすと、WordPress がより多くのメモリを利用できるようになり、メモリ不足によって引き起こされる問題が解決される可能性があります。
FTP経由
- FTP クライアントまたはホスティング コントロール パネルのファイル マネージャーを使用して、サイトのファイルにアクセスします。
- WordPress インストールのルート ディレクトリにあるwp-config.phpファイルを見つけて開きます。
- 次のコード行を追加します。
- ローカルで編集した場合は、変更を保存し、ファイルをサーバーにアップロードして戻します。
定義('WP_MEMORY_LIMIT', '256M');この行により、WordPress で使用される最大メモリ量が 256MB に増加します。 ニーズとホスティング環境の機能に基づいて値を調整できます。
.htaccess ファイル経由
- WordPress インストールのルート ディレクトリで.htaccessファイルを見つけて開きます。
- 次の行を追加します。
- 必要に応じてファイルを保存し、再アップロードします。
php_value メモリ制限 256M
php.ini ファイル経由
- FTP 経由でサイトに接続し、ルート ディレクトリでphp.iniファイルを探します。表示されない場合は、作成する必要がある可能性があります。
- 次の行を追加または変更します。
- ローカルで作業している場合は、ファイルを保存してサーバーにアップロードします。
メモリ制限 = 256M
10Web ダッシュボード経由
Web サイトが 10Web でホストされている場合は、Web サイトのダッシュボードから直接 PHP メモリ制限を増やすことができます。
- 10Web アカウントにログインします。
- WSoD のある Web サイトをクリックします。
- [ホスティングサービス] >[ツール]に移動します。
- 下にスクロールして「詳細設定」をクリックします。
- PHP 設定でPHP メモリを見つけ、必要に応じて制限を調整します。
- 「保存」をクリックして変更を適用します。
さらなる支援を求めるべきとき
PHP のメモリ制限を増やしても WSoD が続く場合は、リソースを大量に消費するプラグインやメモリ リークを引き起こすテーマなど、WordPress サイト内の深刻な問題の兆候である可能性があります。 そのような場合：
開発者に相談する: 専門家はコードをさらに詳しく調査し、メモリ問題の根本原因を特定して修正できます。
ホスティングプロバイダーに問い合わせてください。一部のホストは、サイトのリソース使用状況に関する洞察を提供します。何がメモリを大量に消費しているのかを明らかにするログとメトリクスを提供し、対処方法の手がかりを提供します。
ファイル権限
権限が正しくないと、WordPress が必要なファイルを読み取ったり実行したりできなくなり、WSoD が発生する可能性があります。 ただし、慎重に行ってください。 権限の設定が緩すぎると、セキュリティ上の脆弱性への扉が開く可能性があります。 アクセス許可は、サーバー上のファイルやディレクトリを誰が読み取り、書き込み、または実行できるかを規定する一連のルールです。 WordPress の場合、これらの権限を正しく設定すると、セキュリティを損なうことなく Web サイトが適切に機能することが保証されます。
- 通常、ファイルは664 または 644 に設定し、ファイル所有者とグループが読み取りと書き込みを許可し、他のユーザーは読み取りのみができるようにする必要があります。
- フォルダーは775 または 755 に設定し、所有者とグループが読み取り、書き込み、実行できるようにし、他のユーザーは読み取りと実行のみできるようにする必要があります。
- WordPress 設定に重要なwp-config.php ファイルはさらに制限され、660、600、または 644 に設定される必要があります。これにより、機密情報が公開されないようになります。
権限を修正する方法
ファイルのアクセス許可の調整は、正しく行わないと重大なリスクを伴います。 自分の技術スキルに自信がない場合は、Web ホストにサポートを依頼するのが最善です。
権限を変更するには、サーバーへの SSH アクセスが必要です。 これにより、WordPress サイトがホストされているサーバーに直接接続してコマンドを実行するための安全な方法が提供されます。
SSH経由
SSH 経由で接続するには、サーバーへの特定のコマンド ラインとパスワードが必要です。 コマンド ラインには、サーバー アドレス、ユーザー名、ポートが含まれている必要があります。
- コマンドプロンプトを開きます。
- アドレス、ユーザー名、ポートをコピーしてコマンド ラインに貼り付け、 Enter キーを押します。
- プロンプトが表示されたらパスワードを入力し、 Enterを押します。
ファイルに正しいアクセス許可を設定するには、次のコマンドを使用します。
sudo を見つけます。 -type f -exec chmod 664 {} +ディレクトリの場合は、次を使用します。
sudo を見つけます。 -タイプ d -exec chmod 775 {} +特に wp-config.php ファイルの場合:
sudo chmod 660 wp-config.phpこれらのコマンドは、WordPress インストール内のすべてのファイルとディレクトリに適切な権限を体系的に見つけて適用し、wp-config.php ファイルのセキュリティを強化します。
これらの変更を自分で行うことに不安がある場合、またはプロセス中に問題が発生した場合は、Web ホスティング プロバイダーに連絡することが重要です。 セキュリティ リスクを引き起こすことなく、アクセス許可が正しく安全に設定されていることを確認できます。
失敗したアップデート
おそらくサーバーのタイムアウトが原因で、更新が計画どおりに進まない場合、WordPress は空白の画面に代表される、一種の途方に暮れた状態になることがあります。
WordPress が更新されると、サイトが一時的にメンテナンス モードになります。これは、WordPress ルート ディレクトリに .maintenance ファイルが存在することで示されます。 更新プロセスが中断されたり、正しく終了しなかった場合、このファイルが取り残され、サイトが無期限にメンテナンス モードでロックされる可能性があります。
.maintenance ファイルを確認して削除します。
- FTP クライアントまたはホスティング コントロール パネルが提供するファイル マネージャーを使用して、WordPress インストールのルート ディレクトリに移動します。 ここには、 wp-config.phpなどのファイルやwp-contentなどのフォルダーがあります。
- .maintenanceという名前のファイルを探します。ドット (.) で始まるファイルはアルファベット順に並べ替えると最初に来るため、通常はルート ディレクトリの先頭付近に表示されます。 一部の FTP クライアントまたはファイル マネージャーはデフォルトでこれらのドットファイルを非表示にする場合があるため、これらのドットファイルを表示するには設定を調整する必要がある場合があることに注意してください。
- ファイルが見つかったら、削除します。 この操作により、サイトのメンテナンス モードが解除されます。
唯一の問題が残留する .maintenance ファイルである場合、サイトは正常に読み込まれるはずです。 これは通常、更新が実際には正常に完了したが、WordPress がファイルの削除に失敗した場合に発生します。
更新が中断され完了しなかった場合、.maintenance ファイルが削除されると、WordPress は更新プロセスを自動的に再開しようとすることがあります。 サイトと管理者ダッシュボードに更新通知やプロンプトがないか常に監視してください。
手動アップデート
.maintenance ファイルを削除しても問題が解決しない場合は、WordPress を手動で更新する必要がある場合があります。
常に WordPress ファイルとデータベースの完全バックアップから始めてください。 この手順により、必要に応じてサイトを現在の状態に復元できるようになります。
- WordPress.org Web サイトにアクセスし、最新バージョンの WordPress をダウンロードします。
- FTP クライアントを使用して、新しい WordPress ファイルをサーバーにアップロードし、古いファイルを置き換えます。 設定やコンテンツが失われないように、wp-config.php ファイルまたはwp-content ディレクトリを上書きしないように注意してください。
- 新しいファイルをアップロードした後、WordPress 管理エリアにアクセスします。 データベースを更新するように求められる場合があります。 その場合は、表示される指示に従ってください。
コードエラーの修正
ライブサイトでコードを直接編集することにはリスクが伴いますが、誤ってエラーが発生した場合でも、状況は決して絶望的ではありません。
FTP 経由でコードの変更を元に戻す
WSoD を引き起こした特定の変更を思い出した場合は、それを元に戻すことが回復への最も早い方法です。
- FTP クライアントを使用して Web サイトのファイルにアクセスします。 FTP (ファイル転送プロトコル) を使用すると、サーバー上のファイルをアップロード、ダウンロード、管理できます。
- 接続したら、変更を加えたファイルに移動します。 これはテーマまたはプラグイン ファイルである可能性があり、WordPress 設定を調整している場合は wp-config.php ファイルである可能性があります。
- 正確な変更を覚えている場合は、ファイルを編集して元に戻してください。 新たなエラーが発生しないように、注意して修正内容を再確認してください。
変更を保存した後、Web サイトを更新して通常の状態に戻っているかどうかを確認します。 そうであれば、エラーは正常に修正されました。
バックアップを使用してサイトを復元する
どの変更が問題の原因となったのかわからない場合、または変更を元に戻しても問題が解決しない場合は、バックアップからの復元が信頼できるフォールバックです。
10ウェブユーザー
10Web ユーザーは、Web サイトを以前のバージョンに復元する 2 つの方法があります。 Web サイトのカスタム バックアップをスケジュール設定している場合は、作成したバックアップから復元できます。 復元ポイントから Web サイトを復元することもできます。 これらは、10Web が Web サイトに対して毎日作成する自動バックアップです。
- 10Web アカウントにログインします。
- WSoD のある Web サイトをクリックします。
- 復元ポイントから Web サイトを復元するには、 [ホスティング サービス] > [復元ポイント]に移動します。
- 復元したい日付を見つけて、 [復元] をクリックします。
- 次に、もう一度「復元」をクリックして確認します。
- Web サイトをバックアップから復元するには、 「バックアップ」に移動します。
- リストから、Web サイトを復元する日付を選択し、 [復元]をクリックします。
- もう一度「復元」をクリックして確認します。
構文エラーに対するデバッグ モードの活用
WSoD のトラブルシューティングのために WordPress デバッグ モードを有効にすると、構文エラーの場所が正確に特定される可能性があります。
- 「構文解析エラー」を示すエラー メッセージと、特定のファイル パスおよび行番号を探します。 この情報により、問題のあるコードを見つけて修正する場所がわかります。
- デバッグ モードの洞察を活用して、FTP 経由で接続し、指定されたファイルに移動して、記載されている行番号に移動します。 構文エラーを修正し、コードが適切な PHP 構文または使用している特定のプログラミング言語と一致していることを確認します。
PHP テキスト処理制限の調整
PHP は、テキスト内のパターン マッチングに PCRE ライブラリ (Perl 互換正規表現) を使用します。 pcre.backtrack_limitおよびpcre.recursion_limit設定は、PHP が処理できるテキスト パターンがどれだけ複雑かを定義します。 これらの制限を増やすことで、WSoD をトリガーする可能性がある、より長く複雑な投稿を PHP が処理できるようになります。
- 制限を増やすには: FTP クライアントを使用して wp-config.php ファイルにアクセスします。
- wp-config.phpファイルを開いて編集します。通常、ホスティング コントロール パネルのファイル マネージャーを使用してファイルを直接編集することも、ファイルをダウンロードしてテキスト エディターで編集して、サーバーにアップロードし直すこともできます。
- ファイルの一番下、「/* 以上です。編集を中止してください」という行の直前までスクロールします。出版おめでとうございます。*/ 。 ここで、次のコードを貼り付けます。
- コードを追加した後、wp-config.php ファイルを保存し、ローカルで編集した場合はサーバーにアップロードされていることを確認します。
/* 長い投稿のためのトリック */
ini_set('pcre.recursion_limit', '20000000');
ini_set('pcre.backtrack_limit', '10000000');このコードは、PHP 設定を調整してテキスト処理能力を高めます。
Web サイトを更新して、調整によって WSoD が解決されるかどうかを確認します。 サイトが通常の動作に戻った場合、問題は PHP による長い投稿の処理に関連している可能性があります。
最後に
WordPress ホワイト スクリーン オブ デス (WSoD) の調査を通じて、プラグインやテーマの競合から、PHP のメモリ制限、権限設定、更新の問題、コーディング エラー、さらには PHP テキスト処理に至るまで、さまざまな潜在的な原因と解決策をナビゲートしてきました。長い投稿の制限。 各ソリューションは、WSoD を診断して解決するための道筋を提供し、体系的なトラブルシューティング、定期的なバックアップ、および慎重な編集の重要性を強調しています。 経験豊富な開発者であっても、WordPress の初心者であっても、これらの側面を理解することで、健全で活気のあるサイトを維持する能力が大幅に向上します。
AI を使用して WordPress ウェブサイトの作成を加速します
10Web AI Website Builder を使用すると、ビジネス ニーズに合わせたカスタム WordPress Web サイトを 10 倍の速さで作成できます。
クレジットカードは必要ありません