トップへ
プラグイン購入
お試し体験版
お知らせ
お問い合せ
プロが教えるワードプレスのエラー解消テクニック

プロが教えるワードプレスのエラー解消テクニック


エラーはいつ? どこで? なにが? で考える

初心者向けに書く時にはWordPressをワードプレスと表記する阿修羅ワークスです。 今回は初心者が恐怖するエラーについてです。 ワードプレスでテーマを編集していたら突然エラーで止まったという経験はないでしょうか? ワードプレスはPHPで動いていますので、PHPの文法に誤りがあるとエラーを吐いて止まります。 ワードプレス5.2系からはPHP エラープロテクションやサイトヘルスチェックツールが実装され、致命的なことにはならない対策が施されています。

しかしながら、あくまでも死の白い画面(管理画面にログインできない)を回避できるだけで、エラーを解消しないことにはどうにもなりません。エラーが起きる原因は様々で個別の事例については言及が難しいですが、最低限これだけは抑えておきましょう。

1.いつ起きたのか? 2.どこで起きているのか? 3.なにが原因か?

一番厄介なのは、エラーをエラーと認識せずに発生させてしまった場合です。 本人にその自覚がなく、いつ? どこで? なにが原因で起きたのかが皆目見当がつかない場合です。 あるいは気が付いたら既にバグが存在していた場合です。

もう少し説明しましょう。 まず「1.いつ起きたのか?」というのは、トリガー(誘発原因)がなんなのか? です。 デジタルデータというのは劣化しませんから、基本的には変更を加えなければ変化することはありません。 ということは、ビフォー/アフターを比較した時、最後に加えた処理が原因で起きている可能性が高いのです。

例えば、プログラムをアップデートした、ファイルに変更を加えた、PHPのバージョンを上げた、AをBに替えた、というものです。 逆に考えると、アフターの状態をビフォーの状態に戻せば論理的にはエラーは解消されます。 その他、プログラム自体が抱える内在的なバグがあります。本来扱うべき処理とは異なる例外的な処理が発生し、想定されていない場合はそこでプログラムが停止することがあります。

次に「2.どこで起きているのか?」は場所を特定することです。 エラーといっても全体で起きていることはまず有り得ません。ある特定の場所で起きていると考えたほうが自然です。 例えば、最低限プラグインで起きているのか、テーマで起きているのか、それ以外なのかを切り分ける必要があります。 プラグインで起きているにもかかわらず、テーマを調べても意味はありませんよね。大雑把な場所を特定します。

最後に「3.なにが原因か?」ですが、通常の状態ではエラーは発生しないけれど、特定の操作や条件が揃うと発生するということがあります。例えばPCで閲覧すると発生しないがスマホで見ると発生する。ブラウザのChromeで閲覧すると問題ないが、IEで閲覧すると発生する。ある特定のボタンを押すと発生する、といった条件があるかを特定します。

とはいえ、そんなのわからないよ、というのがプログラミング初心者ですよね。 そこで、プログラミング初心者でも出来て、なんとなくエラーを特定するテクニックを教えます。

科学的手法でアプローチする

科学的手法を用います。科学的手法といっても以下の2つの言葉を理解できれば大丈夫です。

・再現性 ・統計的な有意性

再現性というのは、スイッチをオンにしたらランプが消えるという事象があるのなら、ランプが消えている時はスイッチがオフになっている、という因果関係が見て取れることです。A=B ならば B=A となります。 ところが、A=Bであるけれど、B=Cであるなら再現性がありません。まだなにか見落としていることがあるわけです。

統計的な有意性というのは、はっきりとした因果関係は立証できないけれど、統計をとるとほぼそうなる、という事象です。 例えば、ヒトは二本の足と二本の腕という四肢を持って生まれてきますが、ヒト=四肢があるとすると、四肢がある=ヒトとなり大抵の動物は四肢があるので大抵の動物がヒトということになってしまいます。 また、生まれつき障害があり四肢が欠損している人はヒトではない、という結論になってしまいます。

因果関係と再現性だけで判断すると、万に一つという例外が現れた時に理論は破綻してしまいます。 自然というのは完璧ではなくゆらぎがあるので、例外はあるけれど例えば100万回のうち99万9999回同じ結果なら統計的有意性があるよ=ほぼ間違いないよね、という考え方です。

まずはともあれすっぴんのワードプレスに戻しましょう

話は戻ります。 とりあえず何が何だかわからない場合は、すっぴんのワードプレスにして下さい。 すっぴんのワードプレスというのは、

1.使用しているプラグインを全て無効にする 2.使用するテーマを最初からインストールされている公式のテーマにする

ということです。 これがすっぴんのワードプレスです。

すっぴんのワードプレスというのは、エラーのない初期の状態に近いわけですから、現時点でもっともエラーのない状態だと言えます。 まずこの状態にします。そして、エラーが出ないことを確認します。 仮にこの状態でもエラーが出るのであれば、ワードプレスに問題があるのではなく、もっと基礎の部分、つまりレンタルサーバーの設定や、PHPのバージョンに問題があると疑います。

ワードプレス本体がおかしいという場合もあるかもしれませんが、リリース前にチェックされており、もし問題があれば報告と修正がされているはずなので確率的には低いと推測します。 もちろんワードプレスを何年もバージョンアップしていないのなら別です。バージョンアップして下さい(笑)

原因をテーマかプラグインかそれ以外かに切り分ける

すっぴんのワードプレスにして問題がなければ、次の作業に移ります。 次にテーマを元の使っていたものに戻します。ここで問題が起きないかを確認します。 問題が起きなければテーマは無関係だということが分かります。テーマを変えて問題が起きればテーマ側に問題があることが分かります。

同様にプラグインも上から順に1つずつ有効化して問題が起きないかを確認します。 有効化して問題がおきればそのプラグインに問題がある、ということが分かります。 必ず1点ずつ有効化して確認して下さい。

このように問題がどこで起きているかを切り分けして下さい。また当たり前ではありますが、バージョンアップ通知が来ていたら最新のバージョンにアップデートしてから試して下さい。

テーマまたはプラグインに問題があることが特定できたら、次はどのファイルにその問題があるかを特定します。 その前に、該当ファイルとエラー箇所が分かったとしても、どうにもならないパターンを確認しましょう。

どうにもならないパターンですが、プラグインであれば潜在的なバグの場合は修正ができません。 作者に報告してそのプラグインのバージョンアップを待ちましょう。 理由としては、プラグインはバージョンアップで初期化されてしまうためです。自分で原因を特定してコードを変更しても、次のバージョンアップで元に戻ってしまいます。 しかし、テーマの場合は子テーマを作っていれば親テーマがアップデートされてもその影響を受けません。

 

まとめると、テーマのエラーは子テーマで修復できる。 プラグインの潜在的なバグは修正できない。 プラグインの設定に問題がある場合は設定を見直すことで解決する場合がある。

 

どうにもならないパターンでないことが確認できたら、次はファイル名の特定です。 明らかにエラーが発生して、ファイル名と行位置が表示されている場合はそれをメモします。

エラーメッセージの読み方

ファイル名と行位置は以下のような感じで表示されます。

一番最初にエラーの種類、次にエラーの内容、その次にファイル名(ファイルまでのフォルダパス)、最後にそのファイルの何行目にエラーがあるかが表示されます。

例では、使用しているテーマの「twentysixteen」のフォルダにある「functions.php」「35」行目にエラー箇所があると表示されています。 もし上記のようなエラーが出ずに単に「Internal Server Error」と表示された場合は、エラーのログ表示がオフになっていることを意味します。これではどこでエラーが起きているか分かりませんので、一時的に表示するように変更します。

エラーメッセージが出ない場合はphp.iniを確認する

レンタルサーバーによって設定方法は異なりますが、管理画面から「php.ini」設定を探して、「display_errors」「OFF」になっていたら「ON」にすると表示されるようになります。 しも難しいようであればオンラインでPHPの構文をチェックしてくれるサービスがあるので利用してみてください。

▼PHPコードの構文チェック https://jp.piliapp.com/php-syntax-check/

自分で行った単純なミスであれば直せる

晴れてファイル名とエラー箇所を特定できたとします。 この箇所を見て明らかに自分が行った変更という自覚があれば、元に戻せばエラーは解消します。 しかし、ネットでコードを見つけてコピペしてみたけど動かない、という場合は、コピペした内容がそもそも間違っているか、入力した文字が間違っているか、貼り付ける位置が間違っているかのどちらかになります。 単純にスペルミスや大文字小文字の打ち間違い、行末のセミコロンが抜けていたというのであれば、修正すれば直ります。

そうでなければ自己解決はできないので、ここまでの流れをまとめてプログラミング系Q&Aサイトなどで質問をします。 ところで、自己解決できるかどうかについてはエラー内容である程度判断できます。

よくあるエラーとその意味

よくあるエラーとしては以下のようなものであります。

 

Parse error: syntax error, unexpected ~

 

あるべき文字が抜けている場合などに起こる構文エラーで、よくあるのは行末のセミコロン抜けです。 その他、括弧や引用符の閉じ忘れでも発生します。

 

Fatal error: Call to undefined function ~

 

関数を呼び出そうとしたけれど、その関数が定義されていない場合に表示されます。そもそも関数が定義されていないか、呼び出す関数名を間違っていないかを確認しましょう。

 

Warning: Missing argument 2 for ~

 

関数に指定する二番目の引数が指定されていない場合に表示されます。 例えば、 my_func( $a , $b ); と指定するべきところを my_func( $a ); とだけ記述していると第二引数がないと怒られます。

 

Notice: Constant(定数名) already defined

 

定数を2回定義しようとすると表示されます。同じ名前の定数は定義できません。

 

Fatal error: Cannot redeclare ~

 

同名の関数を2回定義しようとすると表示されます。同名の関数は定義できません。

 

Warning: include(ファイル名): failed to open stream: No such file or directory

 

include関数でファイルやディレクトリが存在しない場合に表示されます。 そのファイルが存在しないか、パスが通っていないので、そのパスにファイルがあるかを確認します。

 

Notice: Undefined offset:(キー)

 

配列変数で定義されていないキーを指定した場合に表示されます。キーがあるかないかをisset関数などで判定してから処理をするようにします。

 

Warning: Invalid argument supplied for foreach()

 

foreach文で配列またはオブジェクト以外を指定した場合に表示されます。 例えば、単なる文字列を指定したり、空の変数を指定すると表示されます。

 

Warning: Cannot modify header information – headers already sent

 

HTTPリクエストで既にヘッダーが出力された後に、またヘッダーを出力しようとすると表示されます。 Cookieやリダイレクト処理のタイミングを間違うと表示されます。

 

Fatal error: Maximum execution time of 30 seconds exceeded

 

厳密にはエラーとは言えないのかもしれませんが、30秒以上処理に時間が掛かっていると表示されます。 多くの共用サーバーでは30秒ルールがあり、30秒経過しても処理が終わらない場合は強制終了されます。 誤って無限ループに陥っている場合や、プログラムが正常でもアクセス過負荷によって処理が遅延する際にも生じます。

とにかくエラーが起きたらそのエラーで検索してみる

エラーをコピペしてネットで検索するとその意味と原因が分かることがあります。 運良く自分のケアレスミスに気がつければ自己解決が可能です。

ただしエラーによってはエラーログに表示された行位置を見てもわからない場合があります。 例えば、引用符を閉じ忘れると開始の引用符から次の終了の引用符までが文字列とみなされて一塊となり、実際のエラー位置が大きくズレることがあります。

プログラミング用のエディタを使っていれば間違いに気が付くことができますが、普通のメモ帳的なものでファイルを開いていると特定が難しくなります。複数の関数を跨いでいじった覚えのない随分下の位置にエラーが表示されている場合は、引用符の閉じ忘れを疑ってみてください。