Как я обновлял Drupal 10 до 11: план, грабли и итоги

Два года мой клубный сайт жил на Drupal 10, и всё было хорошо. Пока однажды утром я не прочитал, что ветка 10 подходит к концу поддержки. Обновление Drupal до 11 откладывал месяцами: страшно, вдруг развалится. В итоге потратил один вечер и половину ночи на грабли, которых мог избежать. Рассказываю честно: план работ, где я тупил, что сломалось и почему теперь сплю спокойно.

Если у вас тоже стоит десятая версия и вы поглядываете на одиннадцатую с опаской — эта статья для вас. Знакомо? Обновиться хочется, а руки не доходят. Доходите.

Зачем я вообще полез в обновление Drupal до 11

Сначала мотивация, без неё никуда. Ветка 10 получает исправления безопасности ограниченно, и каждый месяц отсрочки — это риск. Плюс новые модули уже пишут в первую очередь под 11-ю, а кое-что из нужного мне просто отказывалось ставиться на старую базу. Третий довод бытовой: обновляться по шагам всегда дешевле, чем прыгать через две версии в панике.

Я выбрал момент субботнего утра, предупредил пользователей о возможных перерывах и начал. Часа через четыре сайт работал на новой версии, но эти четыре часа были насыщенными.

Подготовка: бэкап и тестовая копия перед обновлением Drupal

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

mysqldump -u user -p dbname > drupal10-backup.sql
tar -czf site-files.tar.gz /path/to/site

Проверил, что дамп открывается и весит адекватно. Потом поднял тестовую копию на поддомене — та же версия PHP (8.3), те же настройки. Все эксперименты шли только там. Боевой сайт продолжал работать, пока я ломал копию. Это скучный этап, именно он экономит нервы.

Отдельно советую записать список всех установленных модулей с версиями до начала работ. Я сфотографировал страницу со списком расширений, и потом эта картинка выручала трижды, когда ловил расхождения между средами.

Что проверить до старта: требования окружения

Одиннадцатая версия требует PHP не ниже 8.3, современную базу данных и актуальный Composer, если сайт собран им. Мой хостинг позволил переключить версию PHP одной кнопкой в панели. Composer был свежий — обновлял его ещё зимой для другого проекта.

Обязательно прогоните отчёт о состоянии сайта в админке: красные строки там — это будущие проблемы при миграции. У меня светились два пункта: забитый кэш и устаревшая библиотека для обработки картинок. Почистил, обновил, только потом двинулся дальше. Пустой зелёный отчёт — ваш билет на поезд.

Само обновление: composer и update.php

Технически переход выглядит компактно. Сначала правим файл проекта ядра:

composer require 'drupal/core-recommended:^11' 'drupal/core-composer-scaffold:^11' 'drupal/core-project-message:^11' --update-with-dependencies

Потом подтягиваются зависимости — этот этап самый долгий, у меня занял минут десять. Дальше обязательные шаги:

drush updatedb
drush cr

У кого нет drush — те же действия доступны через веб: страница update.php и очистка кэша в админке. Но я всем сердцем советую поставить drush ещё до обновления: половина диагностики дальше делается его командами за секунды.

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

Момент Икс: белый экран и модуль, который всё положил

А вот и моя главная боль той ночи. После updatedb фронтенд открылся, а админка выдала белый экран смерти. Ни ошибок, ни намёков. Я чуть не откатил всё назад и не бросил это дело до следующего года, если честно. Уже открыл терминал для восстановления из дампа.

Отвлекся, сделал чай. Вернулся и вспомнил про логи PHP — а там всё было написано: кастомный модуль статистики, который я писал сам два года назад, обращался к функции, удалённой в новой версии. Отключил его через drush:

drush pm-uninstall mystats

Админка ожила. Мораль простая: белые экраны почти всегда виновник виден в логах, не надо гадать и тыкать наугад. И второй вывод: свои самописные модули проверяйте первыми, они самые опасные при смене поколения ядра.

Что сломалось после перехода и как я чинил

Список фактических поломок на моём сайте получился таким. Во-первых, тема оформления: моя кастомная тема на основе Classy перестала корректно стилизовать формы. Потратил час на правку шаблонов Twig — изменились некоторые хуки. Во-вторых, отвалился модуль генерации PDF: автор выпустил совместимую версию через неделю, я временно поставил dev-ветку. В-третьих, представления Views с агрегацией показали пустые колонки — помогло пересохранение представлений после обновления.

Заметьте: само ядро встало идеально. Все грабли лежали в надстройках. Это типичная картина для крупных обновлений, готовьтесь морально: ядро — полчаса, обвязка — весь вечер.

Проверка сайта после обновления Drupal: мой чек-лист

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

• Отчёт о состоянии: все пункты зеленые или осознанно желтые.
• Регистрация и вход нового пользователя с чистого браузера.
• Создание материала каждого используемого типа, включая загрузку картинки.
• Формы обратной связи: письмо реально доходит до ящика.
• Поиск по сайту находит старые документы.
• Страницы ошибок 403 и 404 показывают свои шаблоны, а не голый текст.
• Cron отрабатывает вручную без ошибок в журнале.

На пункте с письмами я поймал сюрприз: SMTP-модуль сбросил настройки пароля при переустановке. Хорошо, что проверил заранее, а не узнал от читателей, что подтверждения регистрации не уходят.

Полезные команды, которые спасали меня той ночью

• drush status — быстро понять, что вообще происходит с сайтом
• drush ws —tail — журнал событий вживую, главный детектив при белых экранах
• drush cr — очистка кэша, лечит половину странностей после обновлений
• drush pm:list —status=enabled — сверка списка модулей с сохранённой картинкой
• drush sqlq < dump.sql — восстановление базы, если всё пошло совсем плохо

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

Отдельное слово о времени суток для обновления. Я выбрал субботнее утро не случайно: трафик минимальный, впереди целый день на неспешную отладку, а поддержка хостинга отвечает быстро в будние часы — на случай проблем с окружением. Ночные вылазки хороши для мелких правок, но крупный переезд лучше делать со свежей головой при свете дня. Проверено и на успехе, и на неудаче.

Стоило ли оно того: итоги через месяц

Месяц спустя могу оценить трезво. Сайт работает так же стабильно, админка стала отзывчивее, а главное — вернулась возможность ставить современные модули без танцев. Нагрузка на базу, по ощущениям от графиков мониторинга, даже слегка снизилась. Никакой магии прироста скорости ждать не стоит: это техническое обслуживание, а не апгрейд железа.

Мой вердикт: если сидите на десятке — планируйте переход на ближайшие выходные. Один подготовленный вечер по чек-листу избавит вас от аврала в последний момент, когда поддержка кончится окончательно. Проверено на себе: страшно ровно до первого успешного updatedb.

Как я поднимал тестовую копию: маленькие хитрости

Раз уж тестовая среда сыграла ключевую роль, расскажу о ней подробнее. Копия делается в три движения: дамп базы в новую пустую базу, распаковка файлов в каталог поддомена, правка настроек соединения с базой в файле sites/default/settings.php. У меня заняло минут пятнадцать вместе с переключением PHP-версии.

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

Модули, которые потребовали внимания отдельно

Помимо самописного виновника белого экрана, присмотр за собой просили ещё три расширения. Модуль мета-тегов обновился штатно, но сбросил одну настройку открытого графа — заметил только глазами на странице соцсети. Галерея изображений отказалась включаться до обновления своей библиотеки — лечилось последовательностью: сначала библиотека через composer, потом модуль. Формы обратной связи заработали сразу, но потеряли кастомную тему писем, пришлось перекинуть шаблон руками.

Вывод для планирования: составьте таблицу всех модулей с колонкой «что может сломаться». Занятие скучное, минут двадцать. Но именно оно превратило мой хаос той ночи в управляемый список задач, где каждую строчку можно закрыть и забыть.

План Б: откат, если всё пошло совсем плохо

Об этом говорят мало, все рассказывают только успехи. А вы держите в голове путь назад. Мой сценарий отката был отрепетирован заранее и выглядел так: выключаю сайт обслуживанием, восстанавливаю базу из дампа, распаковываю архив файлов поверх, чищу кэш — минут двадцать, и десятка снова жива. К счастью, план Б не понадобился, но его наличие позволяло принимать решения спокойно.

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

Что порадовало в новой версии лично меня

Пара приятных мелочей по итогам месяца. Админка заметно шустрее отзывается на слабом VPS — экономия на каждом клике складывается в настроение дня. Улучшенная система обновлений сама предлагает порядок включения зависимых модулей, раньше это было лотереей. И поиск по списку модулей наконец-то ищет по описанию, а не только по машинному имени — казалось бы, мелочь, а времени экономит массу.

Никаких революций для посетителя сайта нет и быть не может, и это нормально. Обновление ядра — гигиеническая процедура. Делается раз в пару лет, даёт спокойствие и доступ к будущим возможностям. Как замена зубной щётки: откладывать можно, но зачем.

И финальная мысль для тех, кто откладывает. Обновления не становятся проще со временем: чем дольше сидите на старой ветке, тем больше модулей накопят несовместимостей и тем дороже будет прыжок. Регулярный шаг в полшума сегодня дешевле, чем героический рывок завтра. Мой план теперь простой: следующее крупное обновление делаю в течение месяца после релиза, не позже.

План для ленивых: обновление Drupal за один вечер

• Бэкап файлов и базы, тестовая копия на поддомене
• PHP 8.3+, свежий composer, чистый отчёт о состоянии
• composer require ядра ^11, затем drush updatedb и drush cr
• Белый экран? drush ws —tail и отключение виновника
• Чек-лист проверок: пользователи, формы, письма, cron
• Наблюдать неделю, потом удалить старые резервные копии