WordPressの画面が真っ白になったときはプラグインとテーマを分けて調べる

WordPressの画面に何も表示されず真っ白になったときは、更新や再インストールを重ねません。直前に有効化、更新、編集した対象が分かるなら、その一つだけを元へ戻し、同じURLを確認します。対象が分からない場合は、管理画面へ入れるかを確かめてから、プラグインの停止とテーマの切り替えを別々に試します。

作業前に、白くなるURL、発生時刻、直前に更新または有効化したプラグイン、テーマやPHPファイルの変更を記録します。ファイルとデータベースのバックアップも確認します。白画面を直す作業と、原因を確かめる作業を同じものにしないことが大切です。

公開画面と管理画面のどこが真っ白かを分ける

最初に、症状が出る範囲を確認します。トップページだけか、すべての公開画面か、wp-adminも開けないのかを分けます。特定の投稿だけなら、その投稿で使うテンプレートや処理を先に調べられます。管理画面へ入れるなら、そこからプラグインを停止し、別のテーマへ切り替えられます。

WordPressのCommon WordPress Errorsは、PHPエラーとデータベースエラーのどちらも白画面として現れる場合があると説明しています。したがって、白画面という見た目だけで、プラグインが原因だと決めてはいけません。直前の変更と、停止したあとに画面がどう変わるかを対応させます。

文字のない白画面と、メンテナンス中を知らせる文が出る画面も別の症状です。文が表示されるなら、その文とHTTPステータスを記録し、白画面とは分けて調べます。

管理画面へ入れるなら直前に変更したプラグインから停止する

管理画面へ入れる場合は、直前に有効化または更新したプラグインが明らかなら、まずその一つを停止します。対象が分からない場合は、有効なプラグインの一覧を記録し、元へ戻す方法を確認してから、通常のプラグインをすべて停止します。全停止で画面が戻っても、本番サイトですぐにすべてを有効へ戻しません。

複製したテスト環境があるなら、そこで一つずつ有効にし、変更のたびに同じURLと管理画面を確認します。テスト環境を用意できない場合は、再停止できる担当者と作業時間を確保し、本番サイトでも一つだけ有効にして確認します。

全停止で画面が戻ったという結果は、通常のプラグイン側へ原因を絞る材料です。特定の一つを有効にして同じ症状が再現するまでは、そのプラグインが原因だと断定しません。複数のプラグインをまとめて有効にすると、この区別ができなくなります。

管理画面へ入れないならpluginsディレクトリを退避する

次の操作は、通常の単一サイトを対象にします。WordPressマルチサイトやプラグインの保存先を変更した構成では、ネットワーク全体の設定を変えるおそれがあるため、そのまま実行しません。

管理画面も真っ白なら、FTPまたはサーバーのファイル管理画面からwp-content/pluginsを確認します。ディレクトリを削除せず、たとえばplugins_oldへ名前を変えます。WordPressが通常のプラグインを読み込めない状態にして、公開画面と管理画面を開き直します。

管理画面へ入れるようになったら、プラグイン画面を一度開きます。そのあとディレクトリ名をpluginsへ戻し、プラグインが停止していることを確かめてから、一つずつ有効にします。名前を戻しただけで、すべてを有効にしないようにします。

名前を変えても画面が戻らない場合は、ディレクトリ名を正確に元へ戻してから、テーマの確認へ進みます。mu-pluginsは別のディレクトリから読み込まれるため、通常のpluginsディレクトリを変えても停止しません。

テーマはTwenty Elevenへ一時的に切り替える

プラグインを停止しても変わらなければ、使用中のテーマを記録してから、既定のTwenty Elevenへ切り替えます。管理画面へ入れる場合は、外観のテーマ画面から切り替えます。公開画面と管理画面が戻るなら、使用中だったテーマのPHPファイルや、そのテーマが呼び出す処理を調べます。

管理画面へ入れない場合は、先にwp-content/themes/twentyelevenが存在し、変更していないことを確認します。そのうえで、使用中のテーマのディレクトリ名だけを一時的に変えます。管理画面へ入れたら、外観のテーマ画面/wp-admin/themes.phpを開き、Twenty Elevenへ切り替わったことを確認します。既定テーマを確認せずに使用中のテーマを外すと、表示に使えるテーマがなくなるため、先に受け皿を確かめます。

元のディレクトリ名へ戻しても、使用中だったテーマへ自動で戻るとは限りません。原因を修正し、公開画面を確認してから、管理画面で明示して切り替えます。テーマを戻すことと、原因になった変更を戻すことも別の作業です。

WP_DEBUGはエラーを記録する間だけ有効にする

プラグインとテーマを分けても原因が見えない場合は、PHPエラーを記録します。まずサーバーが用意するPHPエラーログを確認し、可能なら複製したテスト環境で調べます。公開中の画面へエラーを表示したままにしません。

WordPressのDebugging in WordPressにある設定を使うと、エラーをWP_CONTENT_DIR内のdebug.logへ記録し、画面への表示を止められます。標準構成の保存先はwp-content/debug.logです。debug.logは通常、公開ファイルと同じ領域に作られます。HTTPから読めないことを先に確認できる環境か、複製したテスト環境で使います。wp-config.phpに同じ定義を重ねず、既存の値を控えてから一時的に変更します。

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

WordPress 3.4.2のwp_debug_mode()では、WP_DEBUGが有効なときにWP_DEBUG_LOGとWP_DEBUG_DISPLAYを処理します。WP_DEBUG_LOGはエラーの記録先をWP_CONTENT_DIR . '/debug.log'へ設定し、WP_DEBUG_DISPLAYをfalseにすると画面へのエラー表示を止めます。

設定後は症状が出る画面を一度開き、ログの時刻、ファイル名、行番号を確認します。ログが作られない場合は、書き込み権限を一律に広げません。必要なログを保存したら、変更した定義を設定前の値へ戻し、追加した定義は削除します。生成されたdebug.logも、確認後にサーバーから削除するか、公開領域の外へ退避します。設定を戻したことと、公開画面にエラーが出ないことを最後に確認します。

画面が戻った操作と原因を同じものにしない

画面を戻すために停止または切り替えた対象と、原因として確認できた対象を分けて記録します。Twenty Elevenへの切り替えで画面が戻った場合も、元のテーマそのものが原因とは限りません。元のテーマへ加えた変更、呼び出しているプラグイン、エラーログを分けて調べます。デバッグを有効にしても、ログを読む前にファイルを次々と変更しません。

画面が戻った時点で作業を終えると、必要な機能が止まったままになる場合があります。最後に、使用するプラグイン、テーマ、問い合わせフォーム、公開画面、管理画面を確認します。停止したもの、戻したもの、症状が再現した操作を記録すれば、復旧と原因確認を一つの作業記録に残せます。