ここまで、PHPでいくつかのトラブルを見てきました。
第1話では、
HTTP ERROR 500第2話では、
Warning: Undefined array key "name"第3話では、コードは動いていても、
入力された文字をそのまま表示して大丈夫？
という問題がありました。
エラーが出たり、警告が出たり。
面倒ではありますが、考え方を変えるとこれらはまだ親切です。
「ここがおかしいよ」と何かしら教えてくれているからです。
では今回。
PHPを少し修正してページを開いてみると――
真っ白。
エラーもない。
警告もない。
文章もない。
何もない。
……これは困ります。
「真っ白」は原因ではなく、結果
PHPを触っていると、
PHPを変更したら画面が真っ白になりました。
ということがあります。
いわゆる「真っ白な画面」です。
でも、
「真っ白になる」という名前のエラーがあるわけではありません。
何らかの理由でPHPの処理が途中で止まったり、そもそも何も出力されていなかったり、エラーが画面に表示されない設定になっていたり。
いくつかの原因によって、
結果として何も表示されていない
だけです。
だから、
真っ白だから○○が原因！
とは決めつけられません。
まず必要なのは、
何が起きているのか調べるための情報を増やすこと
です。
まず最初にやること
AIにコードを書いてもらって、
- コードを追加した
- 保存した
- ページを更新した
- 真っ白になった
なら、最初にやることは意外と簡単です。
今追加したコードを元に戻す。
これです。
第1話でも出てきましたね。
新しいコードを追加する前は正常だった。
追加したら真っ白になった。
元に戻したら正常になった。
ここまで確認できれば、
今追加した部分に原因がある可能性がかなり高い
と絞り込めます。
いきなりサイト全体を調べる必要はありません。
「直す」より先に「戻せる」が大事
AIにコードを書いてもらうと、ついつい、
動かなかった
↓
AIに修正版を書いてもらう
↓
さらに動かない
↓
またAIに書き換えてもらう
となりがちです。
すると、そのうち、
「最初は何が動いていたのか」
まで分からなくなります。
なのでコードを変更するときは、
変更前の状態へ戻せるようにしておく
ことがとても大切です。
小さな変更なら、元コードをコピーしておくだけでも構いません。
慣れてきたらバックアップやGitなど、もっと便利な方法もあります。
でも最初は、
「壊れたら一個前へ戻す」
これができるだけでも十分です。
今日の合格ライン
今回は早めに合格ラインを出しておきます。
真っ白な画面になったとき、
真っ白＝原因不明で終わりではない。
まず、
直前に何を変更したか確認する。
そして、
元に戻して正常になるか確認する。
さらに、
エラーが見えないなら、原因を調べるための情報を探す。
ここまでできれば合格です。
では、その「情報」をどうやって探すのでしょう。
なぜエラーが表示されないの？
PHPでは、問題が起きたときにエラーを画面へ表示することができます。
ところがWebサーバーの設定などによっては、
エラーをブラウザへ表示しない
ようになっている場合があります。
これは必ずしも悪いことではありません。
前回も少し触れましたが、公開中のWebサイトでエラーをそのまま表示すると、
- ファイル名
- サーバー内部のパス
- 使用しているプログラムの情報
など、訪問者に見せる必要のない情報まで表示されることがあります。
だから本番環境では、
利用者にはエラーの詳細を見せない
という設定になっていることがあります。
その結果、
作っている側から見ると「ただ真っ白」
ということが起こるわけです。
じゃあ、どうやって原因を知る？
ここで登場するのが、
エラーログ
です。
名前のとおり、
どんなエラーが起きたのかを記録しているもの
です。
画面には何も表示されていなくても、サーバー側には、
PHP Parse error: syntax error, unexpected token ...や、
PHP Fatal error: Uncaught Error ...などが記録されている場合があります。
難しそうな英語が並んでいますが、全部理解する必要はありません。
まず見るのは、
どのファイルで起きた？
そして、
何行目付近で起きた？
です。
エラーによっては、
in /example/public_html/index.php on line 25のような情報が付いています。
これだけでも、
「index.phpの25行目付近を見ればいいのか」
と調べる範囲をかなり狭くできます。
エラーログはどこにある？
これはサーバーによって違います。
レンタルサーバーなら、管理画面に、
- エラーログ
- PHPエラーログ
- アクセスログ
- ログ
などの項目が用意されていることがあります。
自分でサーバーを管理している場合は、PHPやWebサーバーの設定によって保存場所が変わります。
ここで、
「サーバーによって違うなら覚えられない！」
と思わなくて大丈夫です。
覚えなくていいです。
AIに、
Xserverを使っています。PHPのエラーログはどこから確認できますか？
のように、自分の環境を付けて聞けばいいんです。
「PHP エラーログ ○○サーバー」
と検索してもOKです。
AIに相談するときは「真っ白です」だけにしない
ここまで分かれば、AIへの質問もかなり良くできます。
たとえば、
PHPを修正したところ、ブラウザが真っ白になりました。
だけでは、AIも原因を推測するしかありません。
そこで情報を追加します。
PHPファイルにコードを追加した直後から画面が真っ白になりました。
追加部分を削除すると正常に表示されます。
ブラウザにはエラーメッセージが表示されません。
エラーログには次の内容があります。（エラーログを貼る）
初心者にも分かるように、原因になっている場所と修正方法を教えてください。
これならAIは、
かなり具体的な情報をもとに原因を考えられます。
第1話から少し成長しましたね。
最初は、
動かない！直して！
だったのが、
何をしたら起きたのか
戻したらどうなるのか
どんなエラーが記録されているのか
まで伝えられるようになっています。
エラーを一時的に画面へ表示する方法もある
開発中など、状況によってはPHPのエラー表示を有効にして原因を確認することもあります。
たとえば、こんなコードを見かけることがあります。
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);ざっくり言えば、
PHPのエラーを確認できるようにする
ための設定です。
これを問題のPHPファイルの冒頭などで一時的に使うと、真っ白だった画面にエラー内容が表示され、原因を見つけられる場合があります。
ただし――
公開サイトでずっと表示したままにするのはおすすめしません。
原因を調べるために一時的に使い、確認が終わったら元へ戻す。
あるいは、画面表示ではなくエラーログを使う。
この考え方が大切です。
WordPressが真っ白になった場合は？
WordPressでも、プラグインやテーマ、PHPコードの変更などをきっかけに画面が表示されなくなることがあります。
WordPressにはデバッグ用の仕組みがあります。
wp-config.php で、
define('WP_DEBUG', true);という設定を見かけたことがあるかもしれません。
さらにログへ記録する設定として、
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);という組み合わせがあります。
ざっくり言えば、
デバッグを有効にする
↓
エラーをログへ記録する
↓
訪問者の画面には詳細を出さない
という考え方です。
ログは通常、WordPressの wp-content/debug.log に記録されます。
ただし、サーバー設定などによって挙動が異なる場合もあります。
そして調査が終わったら、デバッグ設定を有効にしたまま放置しないようにしましょう。
AIが「WP_DEBUGをtrueにしてください」と言ってきたら
ここもAI時代には大事です。
AIへ、
WordPressが真っ白です。
と相談すると、
WP_DEBUGを有効にしてください。
と提案されることがあります。
これは原因調査として有効な方法です。
でも、
AIに言われたから意味を考えずコピペする
のではなく、
「これは何をする設定？」
と聞いてみましょう。
さらに、
「本番サイトで使っても大丈夫？」
「調査が終わったら元に戻す必要はある？」
まで聞けば、かなり安全に作業できます。
AIがコードを書いてくれる時代だからこそ、
「このコードは何をする？」
を聞く癖が重要になります。
真っ白になったときの基本手順
今回の内容をまとめます。
PHPやWordPressを変更して画面が真っ白になったら、慌ててコードをどんどん書き換えるのではなく、
- 直前に何を変更したか確認する
- 変更前へ戻して正常になるか確認する
- ブラウザにエラーが出ていないか確認する
- サーバーやPHPのエラーログを確認する
- 必要なら開発用のエラー表示・デバッグ機能を使う
- 得られたエラー内容をAIに渡す
この順番で進めてみましょう。
特に、
元へ戻す → 情報を集める → AIへ渡す
は、PHP以外のトラブルでも使えます。
ワンポイント：「何行目」と書いてある場所が犯人とは限らない
エラーログに、
on line 25と書いてあったとします。
では、25行目だけ直せばいいのでしょうか？
必ずしもそうとは限りません。
たとえば、その少し前の行で ; や } を書き忘れた結果、PHPが25行目まで来て、
「ここからもう解釈できない！」
となることもあります。
だから、
25行目に原因がある
ではなく、
25行目付近でPHPが問題に気付いた
くらいに考えた方が安全です。
エラー行の少し上も確認してみましょう。
これ、地味ですがかなり役立ちます。
「何も分からない」からでも調査は始められる
真っ白な画面を見ると、
何も表示されていないから、何も分からない。
と思ってしまいます。
でも実際には、
何も表示されていないこと自体が調査のスタート地点です。
直前に何をした？
戻したら直る？
ログには何がある？
どのファイル？
何行目？
そこまで分かれば、AIにもかなり良い質問ができます。
全部自分で原因を突き止める必要はありません。
AIが考えるための材料を集められる人になる。
それも、これからのWeb制作ではかなり強い能力です。
次回は「フォームを送ったら、なぜPHPに届くの？」
ここまで、
$_POST['name']を、
フォームから送られてきたnameを受け取っている
くらいに理解して使ってきました。
でも、そろそろ気になりませんか？
そもそも、HTMLに入力した文字はどうやってPHPまで届いているのでしょう？
<form method="post">この method="post" は何なのか。
GET とは何が違うのか。
そして、
$_POSTと、どうつながっているのか。
第5話は、
フォームの文字はどうやってPHPに届く？GETとPOSTを追いかけてみよう
です。
ここまで来ると、最初は「謎の記号」だったPHPが、だんだんWebの仕組みとしてつながり始めます。