Білий екран 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 або запис у логах і усунути конкретну причину.

Що менше випадкових правок зроблено до отримання повідомлення про помилку, то простіше відновлення.