ワードプレスを利用し、カスタマイズが落ち着いた安堵の頃に待っているのが、システムエラーかと思います。『404エラー』については、もはや慣れっこですが、今回は『500 Internal Server Error』に遭遇し、心身共にすっかりやられてしまった経験がありますので、原因と復旧と対策について記載しておこうと思います。
大丈夫、必ず解決します＼(^o^)／
目次
何が起こったのか？！
まずは、落ち着いて下さい。
と言っても無理かと思いますが・・・(･ε･)
ワードプレスの『サーバーエラー』や『システムエラー』は無情です。だって、いきなり画面が真っ白になり、どうすることも出来なくなってしまうのですからね。
けれども実際に起こっているのは、大したことではありません。
見た目の警告がシンプルかつ派手なので、頭も真っ白になってしまうだけです。
この時点で思うのは、バックアップとアファリエイトでしょうか。それでもちょっとブログに執着し過ぎている自分に、出会うチャンスなのかも知れません。
All in One SEO Packが原因？！
これはちょっと曖昧で検証までは至りませんが、今回のクラッシュの原因は『All in One SEO Pack』でした。それでも特に何をしたという訳ではなく、上記の右側『ソーシャルメディア』の『Activate』をクリックしただけです。
その後、画面が真っ白になり、顔面蒼白となった次第です。
ちなみに時間帯は深夜１時で、当然その日は徹夜となりました。
今現在、原因究明に取り組んでいる方の為に、解決した方法を先に記載致します。
毎日ではありませんが定期的にバックアップを取っていたので、大事件にはならないという自信はありました。
-
-
WordPressデータを『さくらサーバー』から手動でバックアップする
少し前の話になりますが、データクラッシュ寸前の事件を起こしました。 原因は、セキュリティープラグイン導入の際の設定ミスで ...
細かいことはともかく『All in One SEO Pack』の操作で.htaccess（ドットエイチティーアクセス）が書き換えられてしまったようでした。
倉庫作業で言えば、リーダーの指示と荷物が一致しておらず、作業員が動けなくなってしまった状態と表現出来ます。
ですから『.htaccess』を前回バックアップのものに上書きして解決となりました。
記載作業については『参考程度』として下さい。
データの保証や管理は『自己責任』でお願い致します。
今やるべきことは何か？
今この記事を読んでいる方は、とにかくググって、多くの記事の中から自分の症状と照らし合わせる作業をしているのだと思います。サーバーエラーの原因は様々なので、とにかく一つずつ潰して行くしかありません。
バックアップがあるにしても、全ての上書きに勇気がいりますので、まずはリスクの少ないものから作業して行くべきです。当然それには『裏付け』が必要となりますが、その効率化を図る為、初期に行うべき確認方法を記載致します。
１.プラグインの干渉を疑う
まず第一にやるべ気は、プラグイン干渉のチェックです。
しかし画面が真っ白になり、ログインが出来なければどうしようもありません。
そこでサーバーの『コントロールパネル』から入りましょう。
『wp-content』⇒『plugins』の中から疑わしいプラグインを探します。
そしてフォルダ名の後ろに『_abc』のように適当な名前を付けます。
この作業を行うことで、リネームしたプラグインが認識されない状態になります。
単純に干渉エラーであれば、これだけで解決するはずです。
ちなみに認識されなくなったプラグインは、管理画面で自動的に無効化されます。
有効にすれば同じことの繰り返しになってしまうので、アンインストールとなるはずですが、先ほど変更したプラグイン名を元に戻してから削除を行って下さい。
どのプラグインが原因なのか見当が付かない場合は『plugins_abc』のように、大元のプラグインフォルダ自体のリネームをすることで一括で無効化が可能です。
これで解決しない場合は、プラグインの干渉が原因ではないことが明らかになりましたので、次のステップに進みましょう。
２.コントロールパネルでエラーチェックを行う
さくらサーバーにはアクセスログのエラーチェックを記録する設定があります。
ここから原因を探してみましょう。
『アプリケーションの設定』⇒『アクセスログの設定』⇒『エラーログ』と進みましょう。すると日時順にエラーログが表示されます。
この中から、500エラーが起こったであろう時間帯周辺を見ましょう。
私の場合は『.htaccess』が連発して記載されていました。
3.『.htaccess』を上書きする
データの置き換えや上書きをする際は『FileZilla』などのサーバー管理アプリを使用すると便利ですので、必要に応じて活用して下さい。
さて、何らかの原因で『.htaccess』が書き換えられてしまったと仮定します。
サーバーの『コントロールパネル』から『.htaccess』の内容をダウンロードなどで『.txt』テキストでコピーしておきましょう。
続いてバックアップを取っておいた過去の『.htaccess』と比べてみましょう。
違いがあったり、プラグイン名が追加されていたらここが原因の可能性が高いです。
※ もう一度確認の為に警告しますが『.htaccess』のバックアップを取りましょう。
『コントロールパネル』から『.htaccess』の上書きを行います。
ここまでで解決出来ることがほとんどです。
ちなみにバックアップを取っていない場合は、追加されたであろうコードを削除してみましょう。下記の範囲を削除すると解決する場合があります。
『#SITEGUARD_PLUGIN_SETTINGS_START』
『#SITEGUARD_PLUGIN_SETTINGS_END』
４.ディレクトリのパーミッション（属性）確認
この辺りになると、なかなか難しくなります。パーミッションの数値が何らかのアクションにより、変更されてしまったことを想定するものです。
サーバー推奨のものもあるので確認が必要ですが『コントロールパネル』から『属性』の数値を確認します。
これでもダメな場合は、バックアップからの置き換えを覚悟した方が良いかも知れません。勿論その前に現状のバックアップもお忘れなく。