Белый экран вместо сайта — фирменный симптом PHP: ошибка случилась, но её вывод выключен (и правильно, на живом сайте ошибки показывать нельзя). Чтобы понять, что сломалось, нужно на время отладки включить вывод ошибок — или найти лог, куда они пишутся всегда.
Способ 1. Быстро: две строки в начале скрипта
В начало index.php (или проблемного файла) после <?php:
ini_set('display_errors', 1);
error_reporting(E_ALL);
Обновите страницу — вместо белого экрана появится текст ошибки с файлом и строкой. Способ хорош тем, что действует только на один скрипт и его легко убрать.
Способ 2. Для сайта целиком: php.ini или .htaccess
На своём VPS — в php.ini (путь покажет php --ini):
display_errors = On
error_reporting = E_ALL
После правки перезапустите PHP: systemctl restart php8.2-fpm. На виртуальном хостинге php.ini часто недоступен — используйте .htaccess в корне сайта:
php_flag display_errors on
Если после этой строки сайт упал с ошибкой 500 — ваш хостинг запрещает php_flag: включайте вывод ошибок через панель управления (у большинства провайдеров из рейтинга хостингов это переключатель в настройках PHP).
Способ 3. Правильный: лог ошибок
Ошибки пишутся в лог всегда, даже когда вывод выключен. Где искать: на хостинге — файл error_log в корне сайта или раздел «Логи» в панели; на VPS — /var/log/php8.2-fpm.log или путь из директивы error_log. Смотреть удобно так:
tail -20 /var/www/site/error_log
На живом сайте это единственный правильный способ: посетители видят аккуратную страницу, вы — полный текст ошибок.
Как читать ошибки: перевод с PHP на русский
- Notice / Warning — предупреждения: скрипт работает дальше, но что-то не так (необъявленная переменная, отсутствующий файл в include). Копятся годами, маскируют настоящие проблемы;
- Fatal error — скрипт умер на этой строке. Частые: Call to undefined function — не подключено расширение или файл с функцией; Uncaught Error: Class not found — не сработал автозагрузчик (забыли composer install?);
- Parse error: syntax error — опечатка в коде: пропущенная скобка или точка с запятой строкой выше указанного места;
- Allowed memory size exhausted — скрипту не хватило памяти: поднимите memory_limit, а если сайт упирается постоянно — лимиты хостинга кончились, пора на VPS, где memory_limit ставите сами.
⚠️ После отладки — выключить
Вывод ошибок на живом сайте — дыра в безопасности: тексты ошибок раскрывают пути к файлам и структуру кода. Починили — верните display_errors в Off. Логи при этом продолжат писаться.
Свои сообщения в лог: error_log()
Отладка не ограничивается чужими ошибками — в код можно писать свои метки:
error_log('Заказ #' . $id . ' не прошёл оплату: ' . $reason);
Строка попадёт в тот же error_log сайта. Хотите отдельный файл — укажите его третьим аргументом: error_log($msg, 3, '/var/www/site/my-debug.log'). Это цивилизованная замена var_dump посреди страницы: посетители ничего не видят, вы видите всё.
Ошибки в WordPress: WP_DEBUG
У WordPress своя обёртка над ошибками PHP. В wp-config.php над строкой «Это всё, дальше не редактируем»:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Такая комбинация — рабочая: ошибки пишутся в файл wp-content/debug.log, но не показываются посетителям. Белый экран после установки плагина? Открываете debug.log — и в последней строке написано, какой именно плагин упал: удаляете его папку из wp-content/plugins по FTP, сайт оживает. После отладки верните WP_DEBUG в false — лог быстро распухает.
Перевод самых частых ошибок CMS
- Allowed memory size of 134217728 bytes exhausted — упёрлись в memory_limit 128M. Виновник — тяжёлый плагин, огромная картинка в обработке или кривой цикл. Быстрое лечение — поднять лимит, честное — найти пожирателя;
- Maximum execution time of 30 seconds exceeded — скрипт не уложился в 30 секунд: гигантский импорт, медленный внешний API. Поднимается max_execution_time, но правильнее разбивать работу на порции;
- Headers already sent — что-то вывелось в браузер до отправки заголовков. В 90% случаев — пробел или перенос строки до <?php или после закрывающего ?> в конце файла. Ищите файл, указанный в скобках ошибки;
- Undefined array key — обращение к несуществующему ключу массива: типично после обновления PHP до 8.x, где старые Notice стали Warning. Код работает, но чинить надо.
Лимиты PHP: что и где подкрутить
Три параметра, в которые упирается типовой сайт: memory_limit (память на скрипт, разумно 256M), upload_max_filesize + post_max_size (размер загружаемых файлов — второй должен быть больше первого) и max_execution_time. Где менять: на VPS — php.ini и перезапуск php-fpm; на хостинге — раздел «Настройки PHP» в панели (у провайдеров из рейтинга они редактируются свободно). Проверить текущие значения: создайте файл info.php с <?php phpinfo();, откройте в браузере — и сразу удалите: phpinfo раскрывает конфигурацию сервера любому желающему.
Частые вопросы
Включил display_errors, а экран всё равно белый
Ошибка уровня Parse error в том же файле, где вы включаете вывод — PHP умирает до выполнения ini_set. Включайте через .htaccess/php.ini или смотрите лог.
Что значит error_reporting(E_ALL & ~E_NOTICE)?
«Показывать всё, кроме Notice». Так прячут шумные предупреждения старого кода. Для отладки лучше честное E_ALL — Notice часто указывает на источник настоящей проблемы.
Ошибка 500 — это то же самое, что Fatal error?
Обычно да: при выключенном display_errors фатальная ошибка PHP наружу выглядит как 500. Полный разбор серверных кодов — в справочнике ошибок HTTP.
Как узнать версию PHP на сервере?
В терминале: php -v. У сайта версия может отличаться от консольной — проверяйте через phpinfo() или в панели хостинга. Помните, что у PHP короткий цикл поддержки: версии старше трёх лет не получают патчи безопасности.
Насколько опасно оставить display_errors включённым?
Реально опасно: тексты ошибок раскрывают абсолютные пути, имена таблиц, версии библиотек — готовая разведка для атакующего. Плюс ошибки ломают JSON-ответы API. Правило: на проде display_errors всегда Off, ошибки — только в лог.
Ошибки перестали писаться в лог — почему?
Три частых причины: log_errors выключен в php.ini, у процесса PHP нет прав на запись в файл лога, или лог переехал (проверьте текущий путь: php -i | grep error_log). На хостинге лог может очищаться панелью — смотрите раздел «Журналы».
Шпаргалка: директивы и где их крутить
| Директива | Что делает | Разумное значение |
|---|---|---|
| display_errors | Показ ошибок в браузере | Off на проде, On при отладке |
| log_errors | Запись ошибок в лог | Всегда On |
| error_log | Куда писать лог | Свой файл в каталоге сайта |
| error_reporting | Какие уровни ловить | E_ALL |
| memory_limit | Память на скрипт | 256M для CMS |
| max_execution_time | Лимит времени скрипта | 30–60 сек |
| upload_max_filesize | Размер загружаемого файла | 64M (+ post_max_size больше) |
Отладка живого сайта: показать ошибки только себе
Классическая дилемма: на проде display_errors нельзя, а ошибку нужно увидеть прямо сейчас. Решение — включать вывод только для своего IP:
if ($_SERVER['REMOTE_ADDR'] === '203.0.113.7') {
ini_set('display_errors', 1);
error_reporting(E_ALL);
}
Посетители продолжают видеть аккуратный сайт, вы — полный текст ошибок. Свой текущий IP смотрите на любом сервисе вроде 2ip.ru (и помните, что у домашнего интернета он периодически меняется). Второй цивилизованный приём — дублировать ошибки в Telegram: в обработчике ошибок отправлять сообщение через бота. Для маленьких проектов это заменяет дорогие системы мониторинга: сайт упал — телефон пискнул через секунду, а не когда напишет клиент.
Итог
Алгоритм: белый экран → включили вывод ошибок (или открыли error_log) → прочитали файл и строку → починили → выключили вывод. Ошибки PHP выглядят страшно, но всегда содержат точный адрес проблемы — этим они лучше молчаливого белого экрана.
