Ошибки в PHP: как их читать и включить их отображение

Вы открываете страницу сайта на PHP, а вместо неё — пустой белый экран. Ни текста, ни ошибки, ничего. Это самая частая ситуация, в которую попадает новичок: PHP по умолчанию на боевом сервере не выводит ошибки в браузер, и создаётся впечатление, что «просто ничего не работает». К концу этой инструкции вы включите отображение ошибок в разработке, научитесь читать их текст и поймёте, чем Fatal error отличается от Warning. Займёт минут двадцать.

Инструкция ориентирована на PHP 8.x (8.1, 8.2, 8.3). В более старых версиях (7.x) названия ошибок те же, но часть предупреждений в восьмёрке стала фатальными — об этом ниже.

Что нужно иметь перед началом

• Установленный PHP 8.x — проверьте командой php -v в терминале, она должна вывести номер версии.
• Доступ к файлу php.ini или возможность править код проекта. Где лежит php.ini, покажет команда php --ini.
• Если сайт на хостинге — доступ к панели управления или FTP, чтобы дотянуться до логов и настроек.
• Любой редактор кода. Блокнот тоже подойдёт, но подсветка синтаксиса заметно облегчает поиск опечаток.

Шаг 1. Включите отображение ошибок для разработки

Самый быстрый способ проверить, что ошибки вообще есть, — включить их вывод прямо в скрипте. Добавьте в самое начало PHP-файла, до любого другого кода:

<?php
// Показывать все ошибки на экране — только для локальной разработки
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

После этого перезагрузите страницу. Если белый экран сменился текстом ошибки — значит, ошибка была, её просто скрывали. Это и есть проверка: вы должны увидеть строку вроде Fatal error: Uncaught Error: ... с указанием файла и номера строки.

Важный момент: ini_set('display_errors', ...) в начале файла не поймает ошибки парсинга самого этого файла — если в нём синтаксическая ошибка, PHP не дойдёт до вызова ini_set. Такие ошибки видны только в логе (шаг 3) или при включении вывода на уровне сервера.

Шаг 2. Настройте это глобально через php.ini

Прописывать ini_set в каждом файле неудобно. Для локальной разработки лучше включить вывод один раз в php.ini. Найдите файл командой php --ini, откройте его и приведите строки к такому виду:

display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On
error_log = /path/to/php-error.log

Путь в error_log замените на реальный — на файл, в который у PHP есть право писать. После правки перезапустите веб-сервер (или PHP-FPM), иначе изменения не подхватятся. Проверка: создайте файл с <?php phpinfo();, откройте в браузере и найдите строку display_errors — она должна показывать On в обеих колонках.

На боевом сервере display_errors всегда держите Off. Текст ошибки может выдать путь к файлам, имя базы данных и структуру проекта — это подарок тому, кто ищет уязвимости. В продакшене ошибки пишут только в лог.

Шаг 3. Найдите лог ошибок

На хостинге display_errors почти всегда выключен, и правильный путь — читать лог. Где он лежит:

1. Если задан error_log в php.ini — там, куда указывает путь.
2. На shared-хостинге лог часто называется error_log и лежит в корне сайта или в папке logs. Смотрите панель управления хостинга — обычно есть раздел «Логи».
3. Веб-сервер пишет свой лог: у Nginx это обычно /var/log/nginx/error.log, у Apache — /var/log/apache2/error.log. Фатальные ошибки PHP-FPM часто попадают именно туда.

Открыли лог — смотрите на последние строки, они самые свежие. Каждая запись содержит дату, уровень ошибки, текст, файл и номер строки.

Как читать текст ошибки

Строка ошибки состоит из трёх частей: тип, сообщение и место (файл + строка). Пример:

PHP Warning:  Undefined array key "email" in /var/www/site/register.php on line 42

Читается так: предупреждение, обращение к несуществующему ключу массива email, в файле register.php на строке 42. Идёте на строку 42 — там и ищите.

Четыре типа, которые встречаются чаще всего:

Правило новичка: сначала гасите Parse error и Fatal error — без них страница просто не работает. Потом Warning, потому что за ними часто прячется настоящая логическая ошибка. Notice и Deprecated разбирайте в последнюю очередь, но не игнорируйте: в PHP 8 многое из того, что раньше было Notice, стало серьёзнее.

Что изменилось в PHP 8

Обращение к несуществующему ключу массива в PHP 7 давало Notice, а в PHP 8 — Warning. Некоторые вещи, которые в семёрке были предупреждением, в восьмёрке стали TypeError и обрывают выполнение. Поэтому код, работавший на PHP 7.4, после обновления до 8.x может внезапно падать — и это не поломка, а более строгая проверка.

Логика try/catch для перехвата

Начиная с PHP 7, большинство фатальных ошибок — это исключения, которые можно перехватить. Это не замена исправлению, но помогает показать пользователю понятное сообщение вместо белого экрана:

<?php
try {
    $result = someRiskyOperation();
} catch (\Throwable $e) {
    // Пишем в лог полный текст, пользователю — общее сообщение
    error_log($e->getMessage());
    echo 'Что-то пошло не так, попробуйте позже';
}

Ловите именно \Throwable, а не только \Exception: Error (например, вызов несуществующего метода) наследуется от Throwable, но не от Exception, и обычным catch (\Exception $e) вы его не поймаете.

Если не получилось

• Всё равно белый экран, хотя display_errors включён. Скорее всего, в файле синтаксическая ошибка (Parse error) — PHP не дошёл до строки с ini_set. Проверьте файл командой php -l имя_файла.php, она покажет строку с ошибкой не запуская код.
• Fatal error: Uncaught Error: Call to undefined function... Функция не существует в этой версии PHP или относится к незагруженному расширению. Проверьте написание и наличие расширения в phpinfo().
• Fatal error: Allowed memory size ... exhausted. Скрипт съел лимит памяти — часто это бесконечный цикл или чтение огромного файла целиком. Ищите цикл без выхода, а не поднимайте лимит вслепую.
• Warning: Undefined variable $x. Переменную используете до того, как ей присвоено значение. Частая причина — опечатка в имени: $user объявили, а обращаетесь к $users.
• Изменения в php.ini не применяются. Вы правите не тот файл. Сверьте путь через php --ini — для CLI и для веб-сервера это могут быть разные php.ini. И не забудьте перезапустить PHP-FPM или Apache.

Что делать дальше

Когда вы научитесь читать ошибки, следующий шаг — не тушить их по одной, а не создавать. Подключите к редактору линтер (в PhpStorm он встроен, для VS Code есть расширение PHP Intelephense) — он подсветит опечатки и обращения к неопределённым переменным до запуска. А для боевого сервера настройте отдельный лог и хотя бы раз в неделю в него заглядывайте: Warning, который вы не видите в браузере, часто и есть причина, почему у части пользователей что-то тихо не работает.