Наука об успешном переходе с Drupal 7 на 9 (и почему некоторые из них терпят неудачу)

Помните тот великолепный веб-сайт, который все в вашей компании любили (или, по крайней мере, терпели), который вы были вынуждены перейти на более новую систему? А команда, которой вы доверили это, возможно, откусила больше, чем может проглотить? То, что когда-то было прекрасно выглядящим и функциональным веб-сайтом, теперь превращается в кучу странных проблем, низкой производительности, а иногда и почти непригодного для использования сайта.

Если это звучит знакомо, и вы столкнулись со странными проблемами после того, как обновили свой сайт с Drupal 7 (или 6) до Drupal 9 (или 8), пожалуйста, прочитайте эту статью до конца . Мы рассмотрим общие проблемы, с которыми сталкиваются владельцы сайтов после обновления Drupal 7 (или 6) до Drupal 9 (или 8), и способы их решения. Это не покроет всех проблем, с которыми мы сталкиваемся, когда приступаем к спасению миграции, но, по крайней мере, должно привести вас к тому моменту, когда вы можете спать по ночам.

Обновление Drupal с 7 до 9 — основная задача

Первый вопрос, который вы, вероятно, задаете себе: «Почему?» Обновление с Drupal 7 до Drupal 9 (Drupal 8 уже закрыт) кажется не таким сложным с точки зрения платформы.

Что ж, Drupal 8 изменил все. Была проведена полная архитектурная переработка, поэтому CMS стала более устойчивой, актуальной и простой в освоении в долгосрочной перспективе. Принятие современных технологий и сред, таких как объектно-ориентированное программирование, Symfony, Twig, последние версии PHP и многое другое, также позволило сообществу Drupal расти в геометрической прогрессии, предоставляя более широкий спектр навыков, помогающих создавать Drupal. Это означает, что теперь легче найти специалиста для создания и поддержки вашего веб-сайта на Drupal. Хорошая новость заключается в том, что обновление до любых будущих версий Drupal (например, с Drupal 8 до Drupal 9) после первоначальной миграции чрезвычайно просто и не требует пересборки.

Но вернемся к рассматриваемой проблеме: многие организации все еще переходят с Drupal 7 на 9 , что требует полной перестройки веб-сайта. Сама перестройка достаточно сложна без сохранения текущей структуры контента, что может подойти самым опытным разработчикам. И в большинстве случаев более крупные веб-сайты требуют еще большего внимания, поскольку они, как правило, имеют несколько дополнительных и настраиваемых модулей, которые не имеют прямого пути обновления. Все это вместе открывает бесконечные возможности для ошибок.

Для команд, которые не пробовали этот тип миграции, чаще всего первой ошибкой миграции с Drupal 7 на 9 является отсутствие подготовки. Первым и наиболее важным шагом для успешной миграции Drupal является проведение тщательного миграционного аудита для анализа каждой мелочи текущей структуры веб-сайта . Этот отчет не только поможет вам оценить последствия миграции, но также даст представление об областях, требующих улучшения. Следующим наиболее важным шагом является решение, разрешить ли специализированному партнеру по разработке Drupal (кому-то, кто изо дня в день дышит Drupal) выполнять миграцию. Точно так же, как вы предпочли бы, чтобы кардиохирург выполнил операцию шунтирования, а не хирург-ортопед; наличие специализированной компании, ориентированной на Drupal, для создания вашего веб-сайта Drupal приведет к успешной миграции.

Общие проблемы миграции с Drupal 7 на 9

Один из самых распространенных источников разочарования после перехода с Drupal 6/7 на 8/9 — это незнание, с чего начать при решении проблем. Как вы, с навыками программирования или без них, узнаете, в чем заключаются настоящие проблемы? Легко - проверьте журналы ошибок. Я знаю, это звучит так, как будто вы открываете еще одну банку червей, пытаясь понять, что говорят журналы, но ниже мы познакомим вас с наиболее распространенными.

Давайте перейдем непосредственно к некоторым из наиболее распространенных проблем, с которыми сталкиваются владельцы сайтов Drupal после перехода с Drupal 7 на Drupal 9.

Сайт почти не работает/не работает

1. Проблемы с сервером: ваш сервер может быть скомпрометирован, если у вас недостаточно прав для доступа к серверу. Более глубокий просмотр журналов ошибок поможет вам понять, откуда возникла проблема. Если это проблема с сервером, убедитесь, что у вас достаточно прав для доступа к вашему серверу. Обратитесь к своему хостинг-провайдеру, чтобы увеличить лимит памяти, если вы столкнулись с проблемой нехватки места. Если это не поможет, поднимите тикет с упоминанием проблемы с вашим сервером.
2. Пользовательский код: если ваш веб-сайт Drupal 6/7 оказался более сложным, чем ожидалось, скорее всего, вместо оценки пользовательского кода и его правильного сопоставления перед миграцией был выполнен простой подъем и изменение. Если у вас есть настраиваемые условия, которые срабатывают при загрузке вашей страницы, и она не находит связанный с ней пользовательский код, вы получите неработающую страницу. Первое, что нужно сделать, это проверить, правильно ли вы оценили веб-сайт в ходе миграционного аудита (если вы это сделали), чтобы проверить наличие пользовательских модулей и кода. Если проблема связана с пользовательским условием и код отсутствует, вам понадобится ваш разработчик Drupal для создания пользовательской реализации кода. В идеале пользовательский код должен быть создан до переноса какого-либо контента.
3. Модуль Core/Contrib: Иногда вы можете столкнуться с известной проблемой в вашем основном или вспомогательном модуле, для которого уже есть решение/исправление. Небольшое исследование может помочь определить это. Найдите и примените патч, и все будет хорошо.
4. Устаревшая версия/библиотеки PHP: на вашем новом сайте Drupal может использоваться более старая версия PHP или библиотеки, от которых зависит ваш код. Убедитесь, что на вашем веб-сайте реализована последняя версия PHP и других библиотек. Также проверьте, соблюдены ли все системные требования и конфигурации.

Невозможно редактировать страницы (проблемы с правами доступа)

1. Ошибка 500: если вы не можете редактировать страницы из-за внутренней ошибки сервера 500, это может быть вызвано различными причинами (неправильная конфигурация, неверный код, неправильное индексирование, агрегация и т. д.). Однако одна из наиболее распространенных причин заключается в том, что это может быть связано с несоответствием между форматами полей или отсутствующими полями. Например, если ваше поле даты с вашего сайта Drupal 7 не перенесено в правильном формате или значение не было преобразовано в формат Drupal 9, будет выдано сообщение об ошибке. Другой пример: если в Drupal 7 вы использовали поле «Изображения», а в Drupal 9 вместо этого вы используете поле мультимедиа. Лучший способ исправить это — исправить скрипт миграции, чтобы данные сохранялись правильно. Если есть только несколько полей для редактирования, вы также можете создать обновление хука.
2. Ошибка 403. Часто ошибка 403 возникает из-за неправильной передачи разрешений. Проверьте, правильно ли настроены разрешения. Если вы используете модуль для управления своими пользователями, проверьте, доступен ли он в Drupal 9. Иногда у вас могут быть хуки или подписчики на события, ограничивающие доступ для некоторых пользователей. Проверьте эти условия и убедитесь, что они реализованы и в вашей новой установке.
3. Страница разрешений не отвечает: ваш сайт Drupal может реализовывать некоторый пользовательский код для обработки разрешений. Если этот код не реализован на новом сайте Drupal 9, возможно, вы не сможете просматривать или редактировать (или и то, и другое) страницу разрешений. Иногда мы видим ситуации, когда пользователи были перенесены в массовом порядке без надлежащего переноса их ролей и профилей пользователей. Как стандартная практика, перед миграцией разрешений разработчик должен создать настраиваемые разрешения и назначить их ролям от людей/разрешений.

Ужасная производительность веб-сайта

1. Ненужные модули: Модули являются строительными блоками вашего сайта Drupal, поэтому вы также можете перенести их. Но иногда мы видим, что устаревшие ненужные модули Drupal 7 перемещаются в Drupal 9, что может вызвать всевозможные проблемы. Тем более, что они могут утяжелить ваш сайт. Вот несколько причин, по которым некоторые из ваших модулей не нужно переносить:
   • Модуль (или его функционал) уже перекочевал в Drupal Core. Например, в Drupal 8.5 дополнительный модуль Media перемещен в ядро, что избавляет от необходимости использовать дополнительный модуль.
   • Его функциональность проста и может быть вставлена ​​в другой пользовательский модуль. Например, если модуль node::postSave используется только для одного или двух типов контента, чтобы выбрать, куда пользователь должен перейти после создания узла, можно вместо этого переместить код в пользовательский модуль.
   • Требования к модулю необходимо пересмотреть. Иногда небольшое изменение в удобстве использования может значительно улучшить производительность сайта. Например, всем веб-сайтам на самом деле не нужен модуль модерации контента, если только команда контент-маркетинга не большая и распределенная. Основные функции редакторского рабочего процесса Drupal (Черновик, Публикация) достаточно хороши для большинства бизнес-требований, которые не требуют сложного/детализированного рабочего процесса.
   • Иногда подмодули устанавливаются вместе с модулями, но редко/никогда не используются. Такие подмодули должны быть удалены.
2. Воспроизведение той же архитектуры. Хотя легче просто поднять, переложить и отряхнуть руки от миграции, это почти никогда не является хорошим подходом. Особенно, если старая (Drupal 6/7) архитектура была грязной и менее надежной. Изменение бизнес-логики/требований также может потребовать полной перестройки архитектуры. Тщательный аудит сайта подскажет, какие именно модули нужно оставить, а какие можно безопасно исключить.

Сторонние интеграции больше не работают

1. Устаревшая версия API: если ваш веб-сайт подключен к различным сторонним инструментам, таким как Salesforce, Marketo, Mailchimp и т. д., неправильно выполненная миграция может повлиять на работу этих интеграций. Часто API, который вы запрашиваете в модуле интеграции Drupal, является более старой версией. Единственное исправление заключается в том, что интеграция должна быть написана в последней версии стороннего API.
2. Проблемы модуля интеграции: вам нужно будет проверить, правильно ли вызываются сторонние API в модуле интеграции. Правильно ли передаются параметры? Проверьте, как они устанавливаются и извлекаются. Проверьте очередь задач для этого модуля интеграции. Там может быть доступный патч, который необходимо применить. Необходимо провести надлежащее тестирование, чтобы убедиться, что API правильно перенесен в Drupal 9.

Другие распространенные проблемы и исправления

1. Установка модуля: Всегда используйте композитор для установки модулей. Это позволит избежать ошибок из-за недопустимых/недоступных зависимостей.
2. Несоответствие источника миграции: независимо от того, какой у вас источник миграции (CSV, база данных, JSON, XML), убедитесь, что поля источника совпадают с полями назначения. Если вы используете CSV в качестве источника, помните о порядке импорта — приоритет имеет значение для сопоставления типов контента.
3. Пути к изображениям. Часто пользователи добавляют изображения непосредственно в содержимое CKEditor. Эти изображения не всегда перемещаются по указанному пути при переносе, поскольку их расположение обычно отличается от расположения других медиафайлов. Тщательно спланированная миграция должна решить эту проблему.
4. SEO: небрежный переход с Drupal 7 на 9 может повлиять на SEO вашего сайта во многих отношениях. Одна из самых серьезных проблем — битые ссылки. Убедитесь, что существующая структура URL и навигация сохранены, так как любые изменения могут привести к множеству неработающих ссылок. Необходимо провести полный SEO-аудит, чтобы убедиться, что на дороге нет препятствий.
5. Стиль Drupal 7: часто проблемы миграции с Drupal 7 на Drupal 9 (особенно проблемы с производительностью) возникают из-за того, что разработчики используют тот же стиль кодирования, что и Drupal 7, вместо того, чтобы адаптироваться к изменениям, внесенным Drupal 8. Примеры: (а) как вы убиваете кеш страниц сильно отличается в Drupal 8. (b) Drupal 8 имеет встроенное управление конфигурацией, но оно часто не реализовано должным образом или не поддерживается должным образом в каждой среде. (c) Мы также столкнулись со случаями, когда проект Drupal 8 все еще реализует процедурный стиль кода.