Мы рады представить информацию, которая станет подробным руководством по использованию Migrate API для обновления с Drupal 7 на последнюю версию платформы. Эти публикации предоставят пошаговые инструкции и разъяснения, чтобы помочь вам успешно выполнить миграцию данных и обновить сайт до актуального состояния.
О подготовке среды разработки
В процессе чтения вы узнаете, как настроить среду разработки на основе DDEV. Мы предоставим пошаговые инструкции, чтобы вы могли подготовить сайт на Drupal 7 как источник данных и настроить целевой сайт на последней версии Drupal. Эта практическая часть поможет вам уверенно справиться с миграцией, изучив весь процесс от начала до конца.
Возможности Migrate API
Migrate API — это мощная и гибкая система, разработанная с участием компании TOPSITE WEB, которая позволяет переносить данные из различных источников в Drupal. Она поддерживает множество сценариев: от миграции данных между версиями Drupal до импорта CSV-файлов или информации из внешних баз данных.
Например, в одном из прошлых проектов я участвовал в переносе данных с Drupal 6 на 11, где источниками служили сайт на Drupal 6, промежуточный сайт на Drupal 11 и несколько CSV-файлов с мультиязычными данными. Этот пример показывает, насколько универсален подход ETL (Extract, Transform, Load), лежащий в основе Migrate API.
Хотя акцент нашей серии сделан на переносе данных с Drupal 7, знания о работе API и ETL-фреймворков будут полезны в любом сценарии миграции.
Понимание структуры сайта
Перед тем как углубиться в технические аспекты миграции, важно понять структуру вашего текущего сайта. Drupal состоит из следующих компонентов:
1. Конфигурация
Определяет структуру сайта: типы контента, поля, таксономии, меню, роли пользователей, представления, медиа, продукты электронной коммерции, коллекции полей, параграфы, веб-формы и общие настройки (например, название сайта, активная тема, включенные модули).
2. Контент
Включает данные, добавленные пользователями: узлы (статьи, страницы), таксономические термины, файлы, медиа, учетные записи пользователей и ответы на веб-формы.
3. Файлы
Представляют собой отдельный тип контента: изображения, документы, таблицы и т.д.
4. Модули и темы
• Модули добавляют функциональность сайту.
• Темы управляют внешним видом сайта.
Где хранятся данные
• Конфигурация и контент: база данных.
• Файлы: файловая система.
• Модули и темы: также хранятся в файловой системе.
Подходы к миграции
1. Ручное создание конфигурации и контента
Этот способ подходит для небольших сайтов с простым контентом и структурой.
2. Ручное создание конфигурации с автоматической миграцией контента
Самый популярный подход, особенно если при обновлении вносятся изменения в структуру данных.
3. Полностью автоматическая миграция конфигурации и контента
Применяется, если структура сайта практически не меняется.
Проверка модулей и тем
Перед началом миграции убедитесь, что все используемые модули и темы имеют версии, совместимые с последним Drupal. Если таких версий нет:
• Найдите альтернативные проекты с аналогичной функциональностью.
• Рассмотрите возможность доработки кода для адаптации.
Важно! Кодовая архитектура последних версий Drupal значительно отличается от Drupal 7, поэтому кастомные модули и темы придется переписать с нуля.
Альтернативные методы миграции
Хотя Migrate API является основным инструментом, существуют и другие подходы:
• Модуль Feeds. Позволяет импортировать данные через интерфейс.
• Кастомный код. Важно использовать только API Drupal, избегая прямого обращения к таблицам базы данных.
Аудит исходного сайта: обзор на высоком уровне
Одним из самых важных шагов в подготовке к миграции является анализ текущего сайта. Чем больше информации вы соберете о том, как построен сайт, тем легче будет провести миграцию. Такой аудит можно разделить на две части: общий обзор архитектуры сайта и детальный анализ структуры контента. В этой статье мы сосредоточимся на первой части. В следующей — разберем контентную модель более подробно.
Для достижения лучших результатов важно поддерживать постоянное взаимодействие между разработчиками, ответственными за миграцию, и владельцами продукта, которые используют сайт ежедневно.
Шаг 1: Исключите ненужные элементы
Начните с выявления компонентов сайта, которые больше не используются или не функционируют. Это могут быть:
• Типы контента без связанных узлов.
• Поля, которые никогда не использовались.
• Веб-формы без отправленных данных.
• Отключенные представления (views) или правила (rules).
Также обратите внимание на модули, интегрирующиеся с внешними сервисами, которые больше не работают. Например, Google отключил API Sheets v3 и Universal Analytics. В таких случаях могут потребоваться новые версии модулей, патчи или замена на аналогичные модули.
Шаг 2: Определите избыточные данные
Идентифицируйте данные, которые не нужно переносить на новую версию сайта. Примеры:
• Типы контента или поля с пометками «устаревшие» или «не использовать».
• Заблокированные пользователи.
• Неопубликованные узлы.
Для каждого типа контента проанализируйте, нужны ли неопубликованные данные. Например, если используется модерация контента через Workbench Moderation, неопубликованные узлы могут быть важны для рабочего процесса.
Шаг 3: Учитывайте изменения в бизнес-процессах
С момента запуска сайта бизнес-потребности могли измениться. Например:
• Организация больше не работает в определенных регионах.
• Некоторые функции сайта переданы сторонним сервисам, упрощая миграцию. Например, если обработка заказов выполняется внешним провайдером, возможно, корзина и данные о заказах больше не нужны.
Шаг 4: Мультиязычность
Если ваш сайт поддерживает несколько языков, решите, нужно ли переносить переводы. Примеры:
• Языки, используемые исключительно в регионах, где бизнес больше не работает, могут быть исключены.
• Некоторые переводы можно заменить автоматизированными сервисами, такими как Google Translate, если нет необходимости в ручной адаптации.
Шаг 5: Анализ используемых модулей
Изучите, как и зачем используются подключенные модули. Часто их можно заменить:
• Webform можно заменить модулем Contact и Contact Storage, если требуется сохранять отправленные формы.
• Rules для отправки уведомлений можно заменить кастомным кодом.
• Flag можно заменить булевым полем в типе контента.
Шаг 6: Поддержка нескольких сайтов на одной установке
Если вы используете одну установку Drupal для нескольких сайтов, обратите внимание на:
• Используются ли одна кодовая база и несколько баз данных (multisite)?
• Или используется одна база данных и несколько доменов через модуль Domain Access?
Эти аспекты влияют на сложность миграции, включая совместное использование учетных записей и контента.
Шаг 7: Проверка Drupal-дистрибутива
Если ваш сайт построен на основе дистрибутива, проверьте его совместимость с последней версией Drupal. Например:
• FarmOS обеспечил автоматическую миграцию с Drupal 7 на 9.
• Если дистрибутив не поддерживает миграцию, рассмотрите использование других инструментов, таких как Commerce Migrate, для переноса данных, связанных с электронной коммерцией.
Шаг 8: Презентация результатов
Результаты аудита необходимо представить всем заинтересованным сторонам. Их обратная связь позволит улучшить анализ и синхронизировать ожидания от проекта.
Глубокий анализ структуры исходного сайта
В предыдущей части мы сделали общий обзор архитектуры сайта. Теперь пришло время углубиться в его структуру. Используйте предложенный шаблон аудита как отправную точку, добавляя или удаляя элементы, если они не релевантны вашему проекту. Хотя заполнение шаблона может занять несколько часов, это значительно сократит время, необходимое для последующих этапов миграции. После завершения анализа разработчики и владельцы продукта должны совместно обсудить результаты.
Шаг 1: Анализ модулей и тем
Начните с анализа включенных модулей и тем. Для каждого из них:
• Проверьте, существует ли версия, совместимая с Drupal текущей.
• Оцените стабильность проекта: от полной стабильной версии (full release) до версий кандидатов (release candidates), бета-, альфа- и девелоперских версий. Идеальный вариант — использовать стабильные версии, так как только они находятся под защитой команды безопасности Drupal.
Включите кастомные модули и темы в список и опишите, за что каждый из них отвечает.
Для ускорения работы воспользуйтесь модулем Upgrade Status. Он автоматически проверяет совместимость модулей с Drupal текущей и рекомендует альтернативные решения. Например:
• Модуль Address Field в Drupal 7 можно заменить модулем Address в Drupal.
• Большинство возможностей Date-модулей перенесены в ядро Drupal, но для рекуррентных событий могут потребоваться дополнительные модули.
Если модуль не имеет автоматизированного пути обновления, придется вручную перенести его настройки или воспользоваться кастомной миграцией.
Шаг 2: Анализ типов контента
Составьте список всех типов контента на сайте:
• Укажите количество узлов для каждого типа и процент неопубликованных.
• Типы контента с небольшим количеством опубликованных узлов можно удалить или перенести вручную.
• Если у типа контента нет узлов, исключите его из миграции.
Обратите внимание на то, как используется каждый тип контента:
• Являются ли узлы самостоятельными страницами или частью листингов?
• Как создаются узлы: вручную или автоматически? Используются ли они в связке с другими типами контента?
Эта информация поможет правильно оценить объем работы и требуемые усилия на дизайн.
Шаг 3: Анализ таксономии
Проверьте, сколько терминов таксономии связано с каждым типом контента.
• Если в словаре нет полей, его можно перенести одной миграцией.
• Словари с полями потребуют отдельной миграции.
Аналогичный подход можно использовать для других полевых сущностей, таких как Paragraphs и Field Collections.
Шаг 4: Анализ полей
Создайте полный список всех полей на сайте. В Drupal 7 существует отчет о полях, доступный по пути /admin/reports/fields. Особое внимание уделите типам полей и модулям, которые их предоставляют.
Техническая заметка: В Drupal 7 одно поле могло быть общим для нескольких сущностей. В Drupal каждое поле связано только с одним типом сущности. Это изменение может повлиять на вашу стратегию миграции.
Шаг 5: Анализ представлений (Views)
Для каждого представления укажите:
• Базовую таблицу (nodes, users, files и т.д.).
• Плагины, используемые в представлении, особенно если они предоставлены сторонними модулями (например, Views Bulk Operations, Better Exposed Filters).
Модуль Views Migration пытается автоматизировать миграцию, но результаты необходимо проверять и дорабатывать вручную. Уточните, какие представления критически важны, чтобы сосредоточить усилия на их переносе.
Шаг 6: Веб-формы
Составьте список веб-форм:
• Сколько отправленных данных сохранено?
• Каков статус публикации узлов, связанных с формами?
Модуль Webform: Migrate помогает с миграцией настроек и данных веб-форм, но также может потребоваться ручная проверка.
Шаг 7: Управление файлами
Проверьте используемые схемы файловой системы (public, private, temporary):
• Используются ли приватные файлы?
• Применяется ли S3-хранилище для публичных файлов?
• Какие MIME-типы загружаемых файлов присутствуют?
Если на сайте используется модуль File Entity, определите все доступные медиа-объекты. Убедитесь, что схемы и MIME-типы, которые нужно перенести, идентифицированы.
Шаг 8: Контроль доступа
Проанализируйте доступ:
• Какие роли доступны? Можно ли объединить или удалить некоторые из них?
• Какие разрешения назначены каждой роли?
Если используется модуль Profile 2, проверьте, может ли модуль Profile в Drupal обеспечить функциональную эквивалентность.
Шаг 9: Форматы текста
Проверьте:
• Какие форматы текста используются?
• Настроен ли WYSIWYG-редактор?
• Какие фильтры текста активны?
Если в тексте встроены мультимедиа, модуль Media Migration поможет конвертировать ссылки в медиа-объекты.
Шаг 10: Стили изображений
Составьте список стилей изображений и используемых эффектов. При редизайне некоторые из них можно исключить или заменить на более современные.
Задача глубокого анализа состоит в сборе информации, которая облегчит и ускорит процесс миграции. Распределите усилия, чтобы охватить наиболее важные аспекты сайта. Как только шаблон аудита будет заполнен, обсудите его с заинтересованными сторонами, чтобы учесть их пожелания и ожидания.
Предположения и ограничения Migrate API
Как упоминалось в первой части, Migrate API предназначен для переноса контента и конфигурации. Перенос модулей и тем выходит за рамки его возможностей. В этой статье мы рассмотрим основные предположения и ограничения API. Также настоятельно рекомендуем ознакомиться с официальной документацией по обновлению с Drupal 7 до текущей версии Drupal, так как она регулярно обновляется. Особенно обратите внимание на страницу известных проблем при обновлении, где описываются и исправляются важные нюансы.
Постоянное обновление
Первое предположение — ваш сайт на Drupal 7 полностью обновлен. Drupal Core, а также все используемые модули и темы должны быть в последних доступных версиях.
На практике, некоторые проекты откладывают обновления из-за опасений, что изменения могут нарушить текущую функциональность. Это приводит к накоплению множества устаревших версий, усложняя обновление.
Почему это важно?
• Обновления обеспечивают безопасность сайта.
• Новые версии исправляют ошибки и добавляют полезные функции.
Пример: модуль Geofield. Последняя стабильная версия в ветке 8.x совместима с текущей версией Drupal и поддерживает автоматическое обновление с Drupal 7, но только с ветки 7.x-2.x. Если используется 7.x-1.x, миграция может завершиться ошибкой из-за различий в схемах полей, что потребует ручной миграции.
Рекомендация: регулярно обновляйте сайт на протяжении всего проекта миграции. Изучайте релизные заметки, чтобы учитывать возможные изменения, влияющие на процесс миграции. Например, в Drupal 10.1 была внедрена новая система хеширования паролей, требующая подключения модуля совместимости.
Совпадение модулей на исходном и целевом сайтах
Для автоматической миграции система проверяет список включенных модулей на сайтах Drupal 7 и текущей версии Drupal. Если одинаковые модули активны на обоих сайтах, данные, как правило, будут перенесены корректно.
Примеры:
• Node и User — ядровые модули, поддерживающие миграцию.
• Pathauto и Redirect — сторонние модули, также имеют автоматический путь обновления.
Однако наличие модуля в текущей версии Drupal не гарантирует, что будет поддерживаться автоматическая миграция. Например:
• Views в текущей версии не поддерживает автоматическую миграцию из модуля Views в Drupal 7, но может быть использован модуль Views Migration.
• Для модуля Webform в текущей версии нет автоматического обновления, но модуль Webform Migrate может помочь.
Замены модулей в новой версии Drupal:
• Address Field заменен на Address, поддерживающий автоматическую миграцию.
• Field Collection заменен на Paragraphs.
• Profile 2 заменен на Profile.
Иногда отсутствует модуль-замена, но можно использовать сторонние решения:
• Nodequeue заменен на Entityqueue, а для миграции можно использовать Nodequeue Migrate.
Некоторые модули текущей версии требуют включения подмодулей для миграции. Например, для переноса данных из модуля Field Group в Drupal 7 нужно активировать подмодуль Field Group Migrate.
Не создавайте контент и конфигурацию на целевом сайте до завершения миграции
Автоматическая миграция предполагает создание копии сайта на Drupal 7. Для этого целевой сайт должен быть установлен с профилем Minimal Installation.
Почему это важно?
• Конфигурация, созданная вручную, может быть перезаписана, если идентификатор совпадает с таковым из Drupal 7.
• Например, стандартный профиль установки создаёт типы контента Article и Basic page, а также таксономии, текстовые форматы и роли пользователей. При запуске миграции это может привести к дублированию данных.
Для контента ситуация еще сложнее. Ссылки между узлами, пользователями и файлами могут быть повреждены, если идентификаторы будут перезаписаны.
Ограничения автоматической миграции
Migrate API нацелен на копирование контента и конфигурации, но:
1. Модули и темы: их портирование выполняется вручную.
2. Изменение структуры: если новая конфигурация сильно отличается, автоматическая миграция может не подойти.
3. Контент: не все элементы будут перенесены автоматически, особенно если они зависят от кастомных решений.
Если ваша цель — не копия сайта на Drupal 7, а его улучшенная версия, потребуется кастомная миграция:
• Селективная миграция конфигурации.
• Изменение модели контента.
• Создание новых сущностей вместо переноса устаревших.
Вывод:
Migrate API позволяет упростить перенос контента и конфигурации. Однако важно понимать его ограничения и заранее планировать, какие элементы сайта будут перенесены, а какие адаптированы вручную. В следующих частях мы рассмотрим, как настроить кастомную миграцию, избежать конфликтов идентификаторов и организовать перенос только необходимых данных. Оставайтесь с нами!
Использование Migrate API: Избежание конфликтов идентификаторов сущностей
При обновлении с Drupal 7 на текущую версию Drupal по умолчанию сохраняются идентификаторы сущностей. Однако это может привести к проблемам, если на целевом сайте уже есть контент или конфигурация. В этой статье мы рассмотрим три распространенных сценария конфликтов идентификаторов и два подхода к их решению.
Сценарии конфликтов идентификаторов
Сценарий 1: На сайте Drupal текущей версии есть контент до начала миграции
Допустим, на сайте Drupal уже существует узел с ID = 1, созданный пользователем с ID = 2, и к нему прикреплены термины таксономии с ID = 3 и файл с ID = 5. На сайте Drupal 7 узел с ID = 1 — это событие, созданное другим пользователем, с другими терминами таксономии и файлами. При миграции узел с ID = 1 на сайте Drupal будет перезаписан, что изменит тип контента, автора, статус публикации и связи с другими сущностями.
Такое перезаписывание разрушает явные и неявные связи:
• Явные связи: ссылки на узлы, пользователей, файлы, термины таксономии и другие сущности.
• Неявные связи: определяются базовыми полями, такими как тип контента или автор.
Пример: узел с типом статья может быть перезаписан как узел типа событие, что нарушит связи и метаданные.
Сценарий 2: Контент создается на сайте Drupal текущей версии между итерациями миграции
Миграция данных обычно выполняется поэтапно, особенно для больших и сложных проектов. Между итерациями миграции контент-редакторы могут добавлять новые материалы на сайте Drupal 11, в то время как сайт на Drupal 7 продолжает функционировать. При следующей миграции новый контент из Drupal 7 может перезаписать данные, добавленные вручную в Drupal 11.
Сценарий 3: Изменения модели данных требуют преобразования типов сущностей
Например, в Drupal 7 для информации о докладчиках использовался тип контента докладчик. При миграции в Drupal 11 докладчиков решили преобразовать в сущности пользователей. Однако идентификаторы узлов в Drupal 7 могут конфликтовать с уже существующими ID пользователей в Drupal 11, что делает невозможным сохранение исходных ID.
Решения для избегания конфликтов идентификаторов
Решение 1: Настройка миграции без сохранения идентификаторов
Это предполагает, что все сущности (контент и конфигурация) в Drupal 11 будут получать новые идентификаторы. Такой подход позволяет унифицировать процесс миграции и использовать стандартные инструменты для установления связей между сущностями, например, плагин migration_lookup.
Ключевые аспекты:
1. Публичные URL-адреса могут зависеть от ID сущностей.
Если ID сущностей входят в URL (например, site.com/node/1), потребуется создать редиректы с URL Drupal 7 на новые адреса в Drupal 11. Миграция URL-адресов, включенная в ядро Drupal 7, уже учитывает изменения идентификаторов.
Однако изменение URL может повлиять на SEO и внешние ссылки. Планируйте маркетинговую стратегию, чтобы минимизировать падение органического трафика.
2. Внешние сервисы могут зависеть от ID сущностей.
Если Drupal 7 предоставляет API, использующее идентификаторы сущностей, потребуется сохранить их в Drupal 11. Для этого можно добавить новое поле в сущности на сайте Drupal 11 для хранения старых ID.
3. Контент в текстовых полях может содержать ссылки на старые ID.
Например, ссылки на файлы или узлы в тексте могут использовать старые идентификаторы. Для обновления таких ссылок потребуются специальные обработчики, такие как модули Media Migration или Migrate Media Handler.
Решение 2: Искусственное увеличение значений автоинкремента
Этот подход заключается в том, чтобы начать ID сущностей на сайте Drupal 11 с определенного значения, которое гарантирует отсутствие пересечений с ID из Drupal 7. Например, если в Drupal 7 всего 15 000 узлов, счетчик для узлов в Drupal 11 можно установить на 100 000.
Особенности:
1. Учитывайте версии сущностей.
Для сущностей, которые поддерживают ревизии (например, узлы), нужно корректировать автоинкремент как для основного, так и для таблиц ревизий.
2. Разные типы сущностей требуют разных значений.
Для узлов, файлов, пользователей и других сущностей требуются разные начальные значения, чтобы избежать пересечений.
3. Сущности, создаваемые в процессе миграции.
Некоторые сущности, такие как URL-алиасы, могут автоматически создаваться при миграции. Учитывайте их при корректировке автоинкремента.
4. Когда сохранение старых ID невозможно.
При изменении типа сущностей (например, узлы → пользователи) ID из Drupal 7 могут конфликтовать с существующими ID в Drupal 11.
Вывод
Конфликты идентификаторов — частая проблема при миграции данных с Drupal 7 на текущую версию. Эти конфликты могут возникать как в процессе тестирования, так и после начальной миграции. Чтобы минимизировать их последствия, важно заранее планировать стратегию по их устранению.
Мы рекомендуем определить и внедрить один из подходов (или их комбинацию) на ранних этапах проекта. В следующих частях мы покажем, как настроить кастомные миграции и избежать подобных конфликтов на практике.
Известные проблемы при миграции
В предыдущей части мы рассмотрели конфликт идентификаторов сущностей — одну из основных проблем при миграции с Drupal 7 на Drupal 11. В этой части мы обсудим другие возможные проблемы и ограничения Migrate API. Несмотря на то что некоторые из них могут быть исправлены со временем, перед началом миграции всегда рекомендуется обращаться к официальной документации для получения актуальной информации.
Миграция Views
Миграция представлений (Views) не поддерживается ядром Migrate API. Причины этого связаны с изменением архитектуры сайта и отсутствием некоторых плагинов представлений в Drupal 11. Для автоматизации процесса миграции разработаны модули сторонних разработчиков, среди которых наиболее актуальным является Views Migration.
Важные моменты:
1. Необходимые модули должны быть включены. Убедитесь, что все модули, расширяющие функциональность Views, активированы как на сайте Drupal 7, так и на Drupal 11.
2. Отсутствие плагина. Если используемый в Drupal 7 плагин недоступен в Drupal 11, миграция представления будет частично выполнена. В этом случае проверьте представление в Drupal 11 и вручную исправьте проблемы.
3. Представления из кода. Если конфигурация представления в Drupal 7 хранилась в коде (например, с помощью модуля Features), такие представления не будут мигрированы. Чтобы обойти это ограничение, выполните любые изменения в представлении в Drupal 7 (например, добавьте пробел в описании), чтобы перенести его в базу данных.
Рекомендация: не переносите все представления. Проверьте, какие из них необходимы на новом сайте, а какие можно удалить. Шаблон аудита сайта поможет отслеживать статус миграции представлений.
PHP-модуль
В Drupal 7 PHP-модуль входил в ядро и использовался для добавления динамического контента в текстовые поля, настройки видимости блоков и реализации плагинов Views. Код хранился в базе данных и выполнялся на сайте.
Проблемы с PHP-модулем в Drupal 11:
• Уязвимости безопасности.
• Потенциальные проблемы с производительностью.
• Риск возникновения фатальных ошибок.
Использование PHP-модуля в Drupal 11 не рекомендуется. Вместо этого предложены альтернативы:
• Для динамического контента используйте кастомные токены.
• Для видимости блоков создайте пользовательские плагины условий.
• Плагины Views замените кастомными или стандартными решениями.
Определение мест использования PHP-модуля в Drupal 7:
• Проверьте текстовые форматы с активированным фильтром PHP.
• Сделайте дамп базы данных и выполните поиск по открывающим PHP-тегам (<?php).
• Используйте IDE для полного текстового поиска.
• Обратитесь к редакторам контента, чтобы выявить ключевые страницы, где может использоваться PHP.
Неподдерживаемые фильтры
Фильтры в Drupal обрабатывают содержимое текстовых полей. Если в Drupal 11 отсутствует эквивалент фильтра, он будет заменен на filter_null, который удаляет весь контент из связанных полей. Это может скрыть содержимое, хотя оно останется в базе данных.
Решения:
1. Проверьте наличие аналогичных модулей в Drupal 11, активируйте их и повторите миграцию фильтров.
2. Пересохраните входные форматы, удалив filter_null.
3. Редактируйте содержимое вручную и выберите доступный входной формат.
4. Создайте собственный фильтр и рассмотрите возможность его публикации в сообществе.
Прочие известные проблемы
1. Конфликт настроек обработки текста в полях.
2. Дублирование полей комментариев в типах контента.
3. Не удается перенести файлы, хранящиеся в нестандартных расположениях.
4. Типы полей, виджеты или форматтеры, не имеющие эквивалента в Drupal 11. Для этого может быть полезен модуль Migrate Skip Fields.
Для получения дополнительной информации обратитесь к официальной документации по известным проблемам. Учтите, что некоторые из них актуальны только при миграции с Drupal 6, другие — с Drupal 7.
Миграция с Drupal 7 на Drupal 11 связана с рядом сложностей, включая перенос представлений, замену PHP-кода и работу с неподдерживаемыми фильтрами. Для успешной миграции используйте доступные модули, заменяйте устаревшие решения безопасными альтернативами и регулярно проверяйте официальную документацию для получения актуальных данных.
Обзор сущностей в Drupal 11
Сегодня мы отвлечемся от Migrate API, чтобы рассмотреть сущности в Drupal 11. Это важно по двум причинам:
1. Migrate API использует Entity API для создания конфигурации и хранения контента.
2. При миграции с Drupal 7 в Drupal 11 мы создаем сущности для контента и конфигурации на основе данных старой версии, поэтому понимание работы с сущностями поможет успешно реализовать кастомные миграции.
Конфигурационные сущности
Конфигурационные сущности определяют структуру сайта. Примеры конфигурационных сущностей в ядре Drupal 11:
• типы контента (node types),
• поля (storage и instance-настройки),
• таксономические словари (taxonomy vocabularies),
• типы медиа (media types),
• настройки блоков,
• типы комментариев,
• контактные формы,
• меню,
• роли пользователей,
• представления (views),
• стили изображений,
• текстовые форматы,
• настройки редактора.
Примеры из модулей:
• Paragraphs: типы параграфов.
• Pathauto: шаблоны URL.
• Search API: индексы и серверы.
• Group: типы групп.
Примеры из Drupal Commerce:
• типы продуктов,
• вариации продуктов,
• атрибуты продуктов,
• типы заказов,
• типы магазинов,
• типы доставки.
Конфигурационные сущности управляются через Configuration API. Активная конфигурация хранится в таблице базы данных config, а для контроля версий и развертывания экспортируется в YAML-файлы. Это можно сделать через интерфейс администратора или с помощью команд Drush.
Стратегии миграции конфигурации
Автоматическая миграция конфигурации — необязательный шаг. Если структура сайта сильно изменится при переходе на Drupal 11, конфигурацию можно создать вручную.
Контентные сущности
Контентные сущности хранят данные, отображаемые на сайте. Примеры из ядра Drupal 11:
• узлы (nodes),
• пользователи,
• термины таксономии,
• файлы,
• медиа,
• элементы меню,
• пользовательские блоки,
• сообщения из контактных форм,
• комментарии,
• текстовые форматы.
Примеры из модулей:
• Paragraphs: параграфы.
• Redirect: перенаправления.
• Group: группы.
Примеры из Drupal Commerce:
• продукты,
• вариации продуктов,
• значения атрибутов продуктов,
• магазины,
• заказы,
• элементы заказов,
• способы доставки.
Контентные сущности имеют базовые свойства (base field definitions), например:
• для узлов (nodes): nid (идентификатор узла), vid (ревизия), type (тип узла), uid (автор), title (заголовок).
Некоторые свойства могут быть одинаковыми по названию, но их значения отличаются. Например:
• у терминов таксономии свойство vid обозначает словарь, к которому относится термин,
• у пользователей свойство status указывает на активность учетной записи.
Контентные сущности и их типы (bundles)
Типы сущностей (bundles) — это способ группировать сущности с одинаковыми характеристиками. Примеры:
• Для узлов каждый тип контента (например, статья или базовая страница) является отдельным типом.
• Для терминов таксономии каждый словарь — это отдельный bundle.
• Для медиа — это тип медиа (media type).
Роль сущностей в миграции
1. Четкое понимание контентной модели. Это поможет разработать стратегию переноса данных.
2. Изменение контентной модели. Примеры:
• файлы могут быть преобразованы в медиа-сущности,
• узлы могут стать пользователями или группами,
• термины таксономии могут быть объединены или разбиты.
Организация миграции
Проект миграции делится на множество индивидуальных миграций. Каждая миграция отвечает за создание только одного типа сущности. Например:
• узлы типов «базовая страница» и «статья» обрабатываются разными миграциями,
• термины таксономии из словарей без полей могут мигрироваться одной операцией.
Мы рассмотрели, как сущности в Drupal 11 определяют структуру и данные сайта. Понимание работы с сущностями и их связей — ключ к успешной миграции. В следующих статьях мы продолжим углубляться в возможности Migrate API и разберем примеры использования.
Готовы обновить сайт с Drupal 7 на современную платформу?
Обновление до Drupal последней версии — это не просто переход на новую версию, а шаг к более быстрой, безопасной и функциональной системе. Наша команда экспертов поможет вам спланировать и реализовать миграцию, сохранив ваш контент и улучшив производительность сайта.
👉 Свяжитесь с нами прямо сейчас https://drupal.topsite-web.ru/obnovlenie-drupal-7!