Drupal на сервере: частые ошибки и решения

MAATRIX

Drupal мощный, но требовательный, и на сервере у него свой набор типичных проблем: белый экран (WSOD), ошибка соединения с базой, сбои прав на settings.php и каталог files, ошибки Composer при обновлении, зависший кэш или 500 после изменений. Практически все частые ошибки Drupal объясняются понятными причинами — PHP, база, права, зависимости, кэш — и решаются проверенным набором действий. Разберём их по порядку, начиная с самых частых, с командами и указанием, где искать логи. Где искать причины. Ошибки PHP пишутся в лог веб-сервера: /var/log/apache2/error.log или /var/log/nginx/error.log. У Drupal есть журнал событий в админке (Отчёты → Последние сообщения журнала, dblog) и watchdog-логи. Для отладки полезен инструмент Drush — консольный помощник Drupal, через который удобно чистить кэш, применять обновления и смотреть статус. Первый шаг при любом сбое — заглянуть в лог веб-сервера и в журнал Drupal, а не гадать по внешнему симптому. Если админка недоступна, диагностику ведут через Drush и логи сервера.

Белый экран смерти (WSOD)

Сайт открывается пустой белой страницей без текста — классический White Screen of Death, следствие фатальной ошибки PHP. Причины: конфликт модуля, несовместимая версия PHP, нехватка памяти или ошибка в коде. Первым делом включите вывод ошибок. В web/sites/default/settings.php временно задайте отображение всех ошибок, добавив соответствующие настройки error_level, и обновите страницу — появится текст ошибки.

Частая причина — нехватка памяти PHP: Drupal прожорлив, увеличьте memory_limit до 256M или выше в конфиге PHP и перезапустите веб-сервер:

systemctl restart apache2

Вторая частая причина — сбойный модуль после обновления. Отключить проблемный модуль без доступа в админку можно через Drush:

drush pm-uninstall имя_модуля
drush cache:rebuild

Пересборка кэша (drush cr) вообще снимает многие «внезапные» белые экраны, поэтому это первое, что стоит попробовать при странном поведении сайта.

Ошибка соединения с базой данных

Drupal пишет об ошибке подключения к базе. Проверьте три вещи. Первое: верны ли параметры в массиве $databases в web/sites/default/settings.php — база, пользователь, пароль, хост. Опечатка или смена пароля пользователя базы — частая причина. Второе: запущена ли СУБД:

systemctl status mysql

Если сервис не запущен — стартуйте и смотрите причину падения. Третье, очень частое: переполнен диск, база ушла в режим только для чтения:

df -h

Почистите старые бэкапы, логи и кэш. Drupal хранит много кэша в базе и файлах; при повреждении базы после аварийного выключения восстанавливайте таблицы средствами MySQL и из резервной копии. Регулярные повреждения — признак нестабильного диска, что на надёжном VPS редкость.

Проблемы с правами: settings.php и files

Специфика Drupal — строгие требования к правам. Две болевые точки. Первая: после установки settings.php должен быть защищён от записи, иначе Drupal ругается на небезопасную конфигурацию. Сделайте его доступным только на чтение:

chmod 444 /var/www/vashdomen.ru/web/sites/default/settings.php

Вторая: каталог files (загрузки) должен быть записываемым для веб-сервера, иначе не грузятся изображения и не работает кэш. Восстановите владельца и права:

chown -R www-data:www-data /var/www/vashdomen.ru/web/sites/default/files
chmod -R 755 /var/www/vashdomen.ru/web/sites/default/files

Важный момент безопасности: каталог files не должен исполнять PHP — это защищает от загрузки вредоносных скриптов. В поставке Drupal есть .htaccess, запрещающий выполнение PHP в files; на Nginx это правило задаётся в конфиге отдельно. Проверьте, что оно на месте.

Ошибки Composer при обновлении

Обновление ядра или модулей через Composer падает с ошибкой. Частые причины: нехватка памяти для Composer, конфликт версий зависимостей или отсутствие доступа к сети. Если Composer падает по памяти, запустите его с увеличенным лимитом:

php -d memory_limit=-1 /usr/local/bin/composer update

Конфликт зависимостей Composer подробно описывает в выводе — читайте, какой пакет какой версии мешает. Иногда нужно обновлять с указанием конкретных пакетов, а не всё разом. После успешного composer update обязательно примените обновления базы данных:

drush updatedb
drush cache:rebuild

Пропуск этого шага — частая причина, почему после обновления файлов сайт ломается: код обновился, а схема базы нет. Всегда делайте бэкап проекта и базы перед обновлением, чтобы откатиться при проблемах. Хорошая практика — обновляться сначала на копии сайта, убедиться, что всё работает, и только потом применять обновление на боевом. Это особенно важно для сложных сайтов с большим числом модулей, где отдельные расширения могут не поддерживать новую версию ядра, и обновление лучше отложить до выхода совместимой версии модуля.

Ошибка 500 и зависший кэш

Сайт отдаёт 500 или ведёт себя странно после изменений конфигурации, темы или модуля. Очень часто виноват устаревший кэш. Drupal агрессивно кэширует, и первое средство почти при любой странности — пересборка кэша через Drush:

drush cache:rebuild

Если Drush недоступен, кэш можно очистить через админку (Конфигурация → Производительность) или, в крайнем случае, усечь таблицы кэша в базе. Ошибка 500 без явной причины также может быть связана с правами (см. выше), нехваткой памяти или ошибкой в .htaccess/конфиге веб-сервера. Проверьте лог веб-сервера — там будет конкретное сообщение. После правок конфигурации, установки модулей и смены темы возьмите за правило выполнять drush cr — это экономит массу времени на ложной диагностике.

Нехватка ресурсов и медленная работа

Drupal при богатой функциональности требователен к ресурсам. Если сайт тормозит, а под нагрузкой ловит 502/503, проверьте память:

free -m

Если система в свопе — серверу мало RAM. Включите кэширование страниц и агрегацию CSS/JS в настройках производительности, добавьте объектный кэш (Redis или Memcached) для высокой посещаемости — это резко снижает нагрузку на базу. Отключите неиспользуемые модули: каждый добавляет работу на каждый запрос. Если после оптимизации сайт всё равно упирается в ресурсы, нужна конфигурация помощнее — Drupal комфортнее с 2 ГБ RAM и выше. На VPS MAATRIX память и CPU наращиваются без переустановки сайта.

Частые вопросы