Linux(Ubuntu)サーバとダーツを愛する中年サラリーマンの日記。

Linuxサーバより愛を込めて。

Wordpress

WordPressの管理画面が真っ白になったときの対処

投稿日:

なぜか管理画面が真っ白に・・・

なぜか、ではなく原因はある程度予測がついたのですが。

 

使用していたプラグインのアップデートを行った直後、管理画面が真っ白になってしまい何もできなくなったのです。

 

ということはほぼ!

 

99.99%!!

 

間違いなく!!!

 

プラグインのアップデートに失敗したか何かであろうと思われたわけです。

 

しかし管理画面が使えないので、問題があると思われるプラグインを停止することも削除することも適わず・・・

 

そんなときの対処法を調べましたので備忘録として残しておきたいと思います。

 

wp-config.phpとデバッグモードで原因追求

wp-config.phpの最下部(なにか自分で追記した場合は別として)に以下の文があります。

 

 

ここのfalseをtrueに書き換えるとデバッグモードとして動作してくれます。

 

このモードでWordpressを動かすとブラウザ上にエラーを直接表示してくれます。程度も様々で「直したほうがいいよ」ぐらいから「これが原因でページを表示できません」レベルまでカバーしてくれるので、今回のように真っ白でなにも表示されない状態になってもエラー原因を調べることができるのです。

 

実際デバッグモードにして動かしてみると色々なエラーが表示されてびっくりしました(汗

 

なかでも致命的だったのは使っていたプラグインの一つである「Google Analytics for wordpress」でした。しかも正にアップデートがあったやつ・・・。

 

どうやら中身のPHPファイルに異常有と表示されているのですが中身なんて構えませんし、どうしたものか・・・

 

プラグインを手動で停止する方法

管理画面が真っ白ではいつものプラグインメニューからの停止が不可能ですよね。

 

そこで手動にてプラグインを停止する術はないものか・・・と調べた結果、2通りの方法に当たりました。

 

MySQL内のデータを修正する

プラグインを管理しているテーブルの値を直接変更することで停止する方法です。

 

phpmyadminを使うでもよいでしょうし、コンソールから直接SQLを叩いて編集するでも構いません。

 

まずはプラグインに関する必要な情報を抜き出してみますと

 

 

このSQLを実行しますと現在有効化されているプラグインのみのデータが抽出されます。

 

この中のoption_valueフィールドの値を変更してやります。これがまあめんどくさいんですが。。。(結構長いので、テキストエディタなどを使用したほうがよいと思われます)

 

ちなみにこの値、以下のようなルールにて作成されてるんですって。

 

a:数字{i:数字;s:数字;"プラグイン名";~}

 

a:に続く数字は有効化されているプラグインの数、{}内は配列になっていてi:に続く数字は配列の添字で0から順番に大きくなり、s:に続く数字はプラグイン名のstring型バイト数を指します。(s:以下は少しあやしい)

 

今回の場合、プラグインを1つ無効化するわけですからa:の後の数字は1減算します。

 

問題なのはi:以下の部分。配列の中から「i:数字;s:数字;”プラグイン名";」が停止したいプラグインに該当する部分を見つけて、その塊(例えば自分の場合ですが「i:8;s:50;"google-analytics-for-wordpress/googleanalytics.php";」の部分)を消します。

 

最後に、消したことで飛んでしまった添字を全て修正します。これまた自分の場合i:8を消したため、以降に含まれていたi:9→i:8に、i:10→i:9に・・・と結構な数のメンテが発生しましたTT

 

こんなめんどくさい思いをして変更した値を「wp_options(wp_の部分は個々の環境で違うはずです。初期設定で修正可能なため)」テーブルに書き込んでやるわけです。

 

 

ちなみにこの操作をSQLで行うなら

 

 

と叩けばOK!

 

あぁ~、めんどくさかった・・・

 

プラグインのディレクトリ名を変更する

こちらはかなりの強硬手段ですが、MySQL内の値を修正するよりはるかに手っ取り早くプラグインを停止できます。

 

FTPを使用するでもコンソール経由でもよいのでプラグインのディレクトリ名またはファイル名をリネームしてやります。最後に「_」を追記する程度で十分です。

 

自分もこれで一発でした。管理画面も見れるようになりましたし、Analytics関連なら別に入れているプラグインでも代用可能なことが分かりましたので停止にしたままプラグインを削除してスッキリ。

 

ただ、修正した後再び同じプラグインを再利用する予定の場合はコチラの方法は避けた方が良い気がします。自分の場合、元のディレクトリ名に戻しても上手く動かない状態になり嵌ってしまいましたので。

 

また、上記のデータベース内の値が修正されていない→内部的には有効化の状態→ディレクトリの名前を戻すと即有効化となるため、根本的な原因が解決していないとまた真っ白になったりもしますのでご注意を。

 

まとめ

実はこの現象が発生したとき別の記事を書いている途中(しかも完成間近)だったため、正直頭の中まで真っ白になってしまいました。

 

無事?解決したので良かったものの、いきなり管理画面が真っ白になったらやっぱりビックリしますよね?

 

ということで今回の内容を纏めておきます。

 

  • wp-config.php内のdefine('WP_DEBUG',true);とすることでデバッグモードとして動作する
  • デバッグモードではエラー内容がブラウザに表示される。これは通常では表示できないような致命的なエラーでも同じ
  • プラグインが原因である場合、MySQLのデータ修正 or プラグインディレクトリのリネームによる停止で回避可能
  • wp_optionsテーブルのoption_valueフィールドのデータ構造を知っておくとデータ修正がしやすい

 

といったところでしょうか。

 

結果的には使用しませんでしたが、普段あまり使用していないSQLであるUPDATE~の復習ができたのは思わぬ副産物ということで。

 

これからもよく分からずにWordpressをいじって同じ目にあうこともあろうかと思いますので今回のデバッグモード、しっかりと覚えておきたいと思います。

スポンサードリンク

スポンサードリンク

オススメの記事

-Wordpress
-, , ,

Copyright© Linuxサーバより愛を込めて。 , 2017 All Rights Reserved Powered by AFFINGER4.