Белый экран Joomla 5 и 6: как найти ошибку и восстановить сайт

Белый экран Joomla — это не отдельная ошибка, а симптом. Обычно PHP прекращает выполнение из-за fatal error, но подробности скрыты настройками отображения ошибок. Причиной может быть несовместимое расширение, версия PHP, повреждённый файл, ошибка шаблона, нехватка памяти или серверная конфигурация.

Главная задача — не менять файлы наугад, а сначала получить точное сообщение об ошибке и только после этого устранять источник.

Что сделать в первую очередь

1. Не удаляйте папки расширений и не заменяйте файлы Joomla наугад.
2. Если возможно, создайте резервную копию текущего состояния.
3. Вспомните, что менялось непосредственно перед проблемой: Joomla, PHP, шаблон, плагин, перенос сайта или ручная правка.
4. Проверьте, работает ли фронтенд при сломанной админке или наоборот.

Если панель администратора ещё открывается

Если административная часть Joomla доступна, сначала включите более подробный вывод ошибок через общие настройки.

Откройте Система → Общие настройки.

Затем перейдите на вкладку Сервер и в поле Сообщения об ошибках (Error Reporting) выберите значение Максимальные (Maximum). Сохраните настройки и снова откройте страницу, на которой появляется белый экран.

Если этого недостаточно, дополнительно можно временно включить Система → Общие настройки → Система → Debug System. Для более подробной записи событий также используется вкладка Logging.

Если админка не открывается: configuration.php

Если административная панель Joomla вообще не открывается, тот же максимальный уровень вывода ошибок можно временно включить непосредственно в файле configuration.php.

Через файловый менеджер хостинга или FTP откройте корневую папку сайта. Это каталог, в котором находятся папки administrator, components, includes и файл index.php. Там же находится configuration.php.

Откройте configuration.php для редактирования и найдите существующую строку с параметром public $error_reporting. Если сейчас указано значение 'none', строка выглядит так:

public $error_reporting = 'none';

Замените только значение 'none' на 'maximum'. После изменения строка должна выглядеть так:

public $error_reporting = 'maximum';

Сохраните файл и снова откройте проблемную страницу. Вместо пустого белого экрана может появиться сообщение об ошибке или stack trace, по которому уже проще определить источник сбоя.

Где искать логи

Если сообщение на экране не появилось или сайт падает слишком рано, проверяйте:

• лог Joomla — путь указан в Global Configuration;
• PHP error log в панели хостинга;
• логи веб-сервера;
• журналы конкретного расширения, если оно их ведёт.

В типичной современной установке Joomla системный каталог логов часто находится в administrator/logs, но ориентироваться нужно на фактический Path to Log Folder.

Чаще всего виновато последнее изменение

Если белый экран появился сразу после установки или обновления расширения, связь вероятна. Не удаляйте каталог расширения первым действием.

1. Зафиксируйте текст ошибки.
2. Проверьте совместимость расширения с Joomla и PHP.
3. Посмотрите changelog и документацию разработчика.
4. Если панель доступна — отключите расширение штатно.
5. Если нет — используйте резервную копию или аккуратное отключение через базу данных только для точно идентифицированного расширения.

Проверьте версию PHP

Белый экран после смены PHP часто связан с расширением или шаблоном, который использует несовместимый код. Обратная ситуация тоже возможна: новая Joomla требует более свежего PHP, чем выбран на сервере.

Проверяйте требования для своей ветки Joomla в официальной таблице.

Нехватка памяти и ресурсов

Fatal error может возникать при исчерпании PHP memory limit или других серверных ограничений. В сообщении об ошибке обычно прямо указывается, что разрешённый объём памяти исчерпан.

В таком случае нужно не просто увеличивать лимит, а выяснить, какая операция потребляет ресурсы: импорт, резервное копирование, тяжёлое расширение, бесконечный цикл или проблемный запрос.

.htaccess: проверяйте, но не лечите им всё подряд

Файл .htaccess может вызвать HTTP 500 из-за неподдерживаемой директивы, ошибки синтаксиса или правил, несовместимых с сервером. Это особенно вероятно после переноса между хостингами.

Совет «добавьте php_value display_errors 1» не универсален. На части конфигураций директивы php_value сами вызывают 500. Если подозрение падает на .htaccess, сравните его с актуальным стандартным файлом Joomla и правилами вашего сервера.

Проверьте шаблон и overrides

Если ошибка появилась после изменения template override или обновления шаблона, stack trace может указывать на каталог /templates/. На тестовой копии можно переключиться на стандартный шаблон и сравнить результат.

Старый override иногда перестаёт соответствовать новому layout компонента после крупного обновления Joomla.

Права доступа и владелец файлов

После миграции проверяйте не только числовые права, но и владельца файлов, режим работы PHP и требования конкретного хостинга. Универсальная рекомендация «configuration.php обязательно 444» подходит не всем серверам.

Кеш после восстановления

После исправления причины очистите кеш Joomla, кеш template framework и, если используется, серверный кеш/CDN. Иначе можно продолжать видеть старую ошибочную страницу.

Чего делать не стоит

• удалять папку расширения только потому, что его имя встретилось в stack trace;
• редактировать index.php ядра ради постоянного ini_set();
• комментировать случайные строки в configuration.php;
• оставлять Maximum Error Reporting и Debug включёнными на рабочем сайте;
• «откатывать» Joomla поверх новой версии без поддерживаемой процедуры.

Короткий алгоритм диагностики

1. Получить точный текст ошибки.
2. Проверить последнее изменение.
3. Проверить PHP и требования Joomla.
4. Проверить логи.
5. Проверить расширение или шаблон, указанный в stack trace.
6. Проверить .htaccess и серверную конфигурацию после миграции.
7. Восстановить чистую резервную копию, если изменение невозможно безопасно откатить.

Итоги

Белый экран Joomla не нужно «лечить» набором случайных строк из старых форумов. В Joomla 5 и 6 правильный путь — включить диагностику, получить stack trace или запись в логах и устранить конкретную причину.

Чем меньше случайных правок сделано до получения сообщения об ошибке, тем проще восстановление.