…バックアップは大切です orz
WordPress、恐い(爆)
私は二つのサイトを運営している。一つは今見ているこのBlogで、もう一つは写真用のBlogの「Olympus.blue」だが、同じレンタルサーバ上で運用している関係から、Googleドライブにバックアップを取っているのはこの「angel-halo.com」の方だったりする。
よって、「Olympus.blue」は無謀にもバックアップを取らずに運用していた。
これが良くない事だという事は十分理解していたのだが、そうそうトラブルなど起きる事はないだろう、と甘い考えでいたのも事実。
実際、今までWordPressの更新の際のトラブルはまったくなかった。
ところが…今日初めてトラブルに出会ってしまった。全く予期していなかっただけに、自分としては結構ショックだったりする。
そのトラブルは、WordPressの更新の時に来たのではなく、そのWordPressを更新した直後に、プラグインの更新を行った時に起きた。
いきなりHTTP 500 error
ショックすぎて、エラーを出した時のスクリーンショットを撮るのを忘れてしまったのだが、プラグインの更新をした直後に、管理画面が更新される事なく固まってしまい、オカシイと気付いて画面を更新したら、管理画面にアクセスできず、いきなりモニタの中心に“HTTP 500 error”と表示され、一般的なアクセスから管理画面にすらアクセスできなくなってしまった。
もうね…瞬間的に固まっちまったYo！
「やっちまったーっ！」って感じで(爆)
こうなると、普通のやり方ではerrorの解除どころか、設定を触る事すら出来なくなる。
よって、まずHTTP 500 errorとは何ぞや？ という所から調べる事になる。
簡単に言うと、500 internal server error、つまりサーバー内部で何らかのエラーが出ているというコードらしい。
…そんな事はわかっとるわ！(爆)
ま、何が原因か、という事を知らせる意味でも、こうしたerror表記は必要だという事はわかっているが、問題が発生しているこの状況で当たり前の事を言われてもねぇ…。
で、このHTTP 500 errorが起きるケース、特にWordPressを使用している時に限定してその原因を調べてみると、どうも大きく分けて3種類の原因がほとんどらしい。
一つが「.htaccess」が原因というケース。これはWordPressそのものの設定が記載されているファイルなので、その設定が更新時に問題を起こしてerrorを出すらしい。
二つ目はプラグインが原因というケース。これはプラグインが更新されたWordPressとの相性でトラブルを起こすケースらしい。
三つ目はテーマが原因というケース。これもプラグインと同じでWordPressそのものが更新された事でテーマの記述式が合わなくなって起きるケースらしい。
と、3つが大凡の原因だとして、私の場合はどれなのかがわからない。
…何も解決していないではないか(爆)
エラーログを探せ
Webサーバでエラーが発生した時の原因を探る場合、やはり頼りになるのがエラーログである。
何が原因でエラーを出したのかという記録であるが、Google先生の検索によると、これはレンタルサーバのPHP設定でエラーログを取ったりする事ができるよう設定できるらしい。
ところが…私が借りているロリポップレンタルサーバのPHP、しかもモジュール版PHPの場合、設定を変えることができない仕様になっていて、CGI版だとON・OFFができるのだが、モジュール版はそもそも設定を触れないようになっている事が判明。
…どうしろと orz
今更CGI版に戻せという事なのか？
というか、エラーログを採るだけでこんな問題あるわけ？
もう挫折感満載な状況下で、他に方法がないかといろいろ検索して探し回ったところ、WordPressの構成ファイルである「wp-config.php」に特定の命令を加えてやればログが残せるようになるらしい事か判明。
「wp-config.php」は、WordPressをインストールしたフォルダ内にあるファイルだが、コイツを編集すれば良いという事で、FTPソフトを使ってこのファイルをダウンロードし、内容を確認してみた。
ちなみに参考にさせてもらったサイトは以下。
Gatespace’s Blog WordPressのデバッグモード
https://gatespace.jp/2012/07/20/wordpress-debugging/
このサイトの情報によると、wp-config.phpの78行以降のあたりにWP_DEBUGというコマンドがあり、それをtrueにする事でデバッグモードに入れるというのだが…私のwp-config.phpにはその行がない！ orz
ないので…どうなるか分からないが、とりあえず自分で記述してアップロードしてやった。
具体的には、このデバッグモードにプラスして、ログを残すコマンドを併用して、/wp-content/フォルダにログデータを残すように記述して、アップロードした。
そして「Olympus.blue」に実際にアクセスすると、ちゃんと/wp-content/フォルダ内にログが保存されたので、今度はそのログデータをFTPソフトでダウンロードして、内容を見てみた。
すると…super-cacheのプラグインの所で止まっている事が判明した。
強制的にプラグインを切る
プラグイン、しかも何のプラグインが原因かが分かったので、/wp-content/内のpluginフォルダ内のsuper-cacheのプラグインのファイル名を強制的に違う名前にリネームしてやった。
これでsuper-cacheのブラグインがロードされなくなるので、問題は潰せたハズである。
で、「Olympus.blue」にアクセスすると…ようやく戻ったーっ！
しかし…ここまで来るのに時間がかかった orz
もともとプログラム等についてはド素人もいいところなので、こういうトラブルが発生すると何をどうすれば良いのか全く分からないのだが、とりあえずエラーログが重要だという事は分かったので、今後はログを残せる状態にしておこうと思う。
バックアップデータがあれば、とりあえずデータを入れ替えれば復活はできるので、本来ならバックアップを取るのが普通である。
WordPressを使っている人なら、ほとんどの人は分かっているとは思うが、バックアップは重要である。
コレ、絶対である。
最近のコメント