Год назад, в январе, окончательно наступил конец жизненного цикла Drupal 7. Однако заявки на обновление с «семерки» до актуальной версии появляются до сих пор. Как и в целом заявки на обновление Друпала. В связи с чем небольшой ликбез о том, как мы обновляем Drupal и
Зачем вообще что-то обновлять
Основных причин обновлять Drupal, как и другую CMS, как и программное обеспечение в общем, три:
- Новый функционал. Разработчики добавили, выпустили обновления. Мы обновили, получили новые штучки.
- Исправление ошибок — программ без них, как известно, не бывает. Разработчики нашли баг, исправили, выпустили обновление. Мы обновили, получили более стабильное ПО.
- Обновления безопасности. В программах, с которыми можно работать через Интернет, регулярно находят уязвимости, то есть потенциальные точки взлома. Уязвимости бывают разными, одни позволяют увидеть информацию, к которой доступ ограничен, другие позволяют подготовить покражу пароля у пользователя, третьи — получить полный контроль над программой или вообще над сервером.
И если без пунктов 1 и 2 в принципе можно жить, то пренебрегать обновлениями безопасности не следует. Дело в том, что сайты взламывают не только в кино, и не только какие-нибудь крупные, или известные. Со временем к найденным в ПО уязвимостям пишут сканеры и эксплойты — программы, которые автоматически находят сайты с незакрытыми уязвимостями и автоматически же их взламывают. А взломщику достаточно просто запустить эту программу — и вот у него уже доступ к вам на сервер.
Если вам кажется, что ваш сайт слишком маленький и взломщикам неинтересен, то возможно это и так. Но вот автоматически взломать его, чтобы запустить на сервере майнер криптовалюты, или спам-рассылку, или просто перенаправить трафик на какие-нибудь сомнительные ресурсы — для этого сгодится и ваш сайт. Вместе с сотней других таких же, автоматически найденных. Вот например старый случай.
Регулярные обновления
Зачем обновляться разобрались, теперь к вопросу — как.
У Drupal хорошая инфраструктура и налажена работа security team: команды безопасности, которая неустанно ищет и исправляет уязвимости в системе. Эти обновления (когда они есть) выходят по средам вечером, поэтому оптимально обновляться по четвергам с утра. Кому-то мы ставим обновления раз в неделю, кому-то раз в две, или раз в месяц. Чем больше промежуток, тем больше обновлений за него выйдет, тем больше времени занимает одна операция обновления.
Помимо патчей безопасности, обновляется ядро системы и дополнительно установленные модули. В обновлениях могут быть как исправлены баги, так и добавлены новые функции. Обычно успешное обновление среднего сайта раз в неделю занимает от 15 минут до часа, а раз в месяц — 2–3 часа (4–5 если с отдельным QA-инженером и smoke-тестами). Смотрим список изменений, выполняем техническую часть, затем проверяем обновлённый функционал, чтобы ничего не сломалось. Обычно не ломается.
Технически операция простая:
- Запуск команды проверки и установки обновлений (composer update).
- Запуск миграций базы данных (если в обновлении они есть).
- Все необходимые проверки.
- Экспорт конфигурации и сохранение изменений.
- Деплой (установка) обновлений на живой сервер в соответствии с нашими правилами деплоя.
Это всё обычные, повседневные обновления минорных версий системы (например с 10.4 до 10.5). Рекомендуется ими не пренебрегать, ну или хотя бы, повторюсь, ставить патчи безопасности. Это не только позволит поддерживать Drupal-сайт в бодром состоянии духа, но и будет проще начать
Обновления мажорной версии (8 → 9 → 10 → 11)
Тут всё уже немного сложнее. Между мажорными версиями происходят изменения без обратной совместимости. Отключаются старые API, появляются новые, меняются те или иные правила написания кода. Поэтому здесь простым composer update обойтись не удастся, нужно готовиться. Но есть и хорошая новость: большую часть подготовки можно ускорить благодаря модулю Upgrade Status. Он автоматически проверяет установленные модули CMS, сканирует кастомный (написанный нами) код и сообщает, все ли совместимо и чего не хватает, чтобы было совместимо, в форме вот такого отчета:
По результатам нужно уделить внимание подсвеченным в отчете моментам: зайти на страницы модулей, помеченных несовместимыми (на странице может найтись совместимая версия), исправить найденные проблемы в коде. Затем найти на drupal.org страницу со списком изменений между заданными версиями и пройтись по своему коду, сверяясь со списком. Потому что модуль подсвечивает не всё что нужно сделать. Например, обязательные вызовы accessCheck(), или необходимость поменять jQuery.once() на core/once не отмечает.
При этом сразу по их появлению обновлять мажорные версии Drupal обычно не стоит: дополнительные модули будут просто еще не готовы. Надо дать версии настояться хотя бы до *.2. Вот сейчас последняя версия — 11.3, так что готовить переходы 10 → 11 уже можно.
Вместе со всей подготовкой, в зависимости от сложности обновляемого сайта, обновление мажорной версии Drupal у нас занимало от 3–4 часов до 30–40. Но это с версиями 8, 9, 10. А как провести
Обновление старых версий (5, 6, 7) до актуальной
Правильный ответ: никак. Нельзя нажать какую-то кнопку и получить из Drupal 7 — Drupal 10 (или 8). Нельзя выполнить composer update: в Друпале применять composer стали только с 8-й версии. И в целом между Drupal 7 и 8 произошли следующие фундаментальные изменения (в крупную клетку):
- Ядро Drupal 8 работает на фреймворке Symfony (а 7 — нет). Это значит, что весь кастомный (написанный нами) код нужно переписать.
- Контент и его структура объявляется и хранится иначе, нужно воссоздать её заново.
- Тема оформления (фронт-энд) теперь работает не на PHP Template, а на Twig. Поэтому нужно переписать под Twig все шаблоны. Убрать из них вставки php-кода, если есть. Перенести их, например, в preprocess-хуки.
В общем, обновить тут ничего не получится. По сути, нужно создать новый сайт на актуальной версии Drupal и перенести на него старый контент. Примерно так:
- Поставить нужные модули, или их аналоги.
- Пересоздать типы материалов и словари таксономии.
- Сделать нужные представления, таблицы, ленты.
- Настроить SEO-модули и микроразметку.
- Перенести стили, переписать шаблоны с phptemplate на twig, портировав таким образом тему.
- Переписать свои модули под поддержку новых API.
- Затем скриптом, или модулем типа feeds, экспортировать материалы со старого сайта.
- И, тоже скриптом или модулем, или через Migrate API, импортировать материалы на новый сайт.
то есть по трудозатратам это примерно как создание нового сайта, хоть и не совсем с нуля. Так что когда решите обновляться с Drupal 7, это хороший повод подумать, что в текущей версии не устраивает, что убрать, что добавить, что переосмыслить. Оценить возможность и необходимость редизайна. И сделать сайт лучше прежнего.
Обращайтесь, если что, мы поможем!
