Известные проблемы при обновлении с Drupal 6 или 7 до Drupal 8

Drupal 6 до 8

Категории агрегаторов

В Drupal 8 больше нет концепции категорий агрегаторов, и поэтому они не перенесены в Drupal 8.

Разрешенные протоколы

Drupal 8 теперь сохраняет протоколы в параметре контейнера «filter_protocols», поэтому, если вы изменили переменную «filter_allowed_protocols», введите ее в файл services.yml.

Разрешенные словари таксономического эталонного поля

В Drupal 6 список применимых типов контента для данного словаря определен в настройках словаря. В Drupal 8 разрешенные словари могут быть определены в настройках поля ссылки термина таксономии. Этот параметр в настоящее время не переносится, что позволяет ссылаться на все словари в Drupal 8. Вы можете вручную отредактировать настройки поля ссылки на термин таксономии в Drupal 8 после обновления и выбрать разрешенные словари.

[Исправлено] Форматы даты

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

Поля, отсутствующие в форме редактирования или на странице просмотра

Еще одна вещь, которая может привести к путанице, - это когда вы запускаете миграцию, которая кажется успешной, но после этого вы не видите свои поля в форме редактирования. Перейдите на страницу администрирования типов контента и откройте вкладку «Управление отображением форм» для каждого типа контента. Поля, добавленные обновлением, могут быть скрыты в форме редактирования. Если это так, перетащите их вверх, чтобы они были видны. Точно так же, если они не отображаются в представлении узла, возможно, поля, добавленные Migrate, скрыты на вкладке «Управление отображением», и вам может потребоваться сделать их видимыми там. В миграции пользовательских полей на объект может помочь модуль Migrate Plus.

Домашняя страница загружается и тема не работает

При выполнении миграции иногда страница белая и загружает только несколько элементов. По сути, это похоже на сломанную тему. Visiting /user и возвращение на домашнюю страницу обычно разрешают это.

Меню UI

Переменные menu_primary_links_source и menu_secondary_links_source не переносятся, поскольку они не имеют аналогов в Drupal 8.

Модули и темы

Перед началом миграции необходимо включить новые модули и темы, а также установить тему администратора (если она есть).

Типы содержимого узла

Конфигурация по умолчанию в Drupal 6 имеет типы контента Story и Page. Типы контента по умолчанию в Drupal 8 называются Article и Basic Page (которые имеют имя машины 'page', как в Drupal 6).

• Миграция отобразит тип контента Drupal 6 Page на тип Drupal 8 Page, поскольку имена компьютеров этих типов контента совпадают.
• Миграция создаст тип контента Story для Drupal 8. Возможно, вы захотите удалить тип контента Drupal 8 Article, если он вам не нужен. Для получения более подробной информации, пожалуйста, обратитесь к # 2236289: Миграция «сюжетных» узлов из D6 создает новый тип контента в D8.

Узловые переводы

В Drupal 6 и 7 переводы узлов хранились в разных узлах, тогда как в Drupal 8 они теперь объединяются с их узлами исходного языка. Система миграции выполнит объединение трансляций узлов, но это означает, что некоторые ссылки могут теперь указывать на узлы, которые больше не существуют. См. # 2746527: [META] Для получения дополнительной информации обработайте данные, связанные с переводами узлов Drupal 6 и 7 с разными идентификаторами.

Обратите внимание, что редакции переведенных узлов еще не перенесены. См. # 2746541: [backport] Перенос версий D6 и D7 ревизий узлов на D8 для получения дополнительной информации.

Обзор обновления многоязычного Drupal 6 до Drupal 8.

Категории профиля

Поля, сгруппированные по модулю профиля в Drupal 6, не будут сгруппированы в Drupal 8.

Поле профиля (выбор списка)

Настройка «разрешенных значений» результирующего поля в Drupal 8 будет представлять собой комбинацию всех выбранных пользовательских значений и текущих допустимых значений в Drupal 6, а не только разрешенных значений в Drupal 6.

Статистика

Настройки журнала доступа и статистические данные не i18n переносятся. Консолидация статистических данных i18n перенесена с Drupal 8.5.2. См. # 2930101: i18n / statistics - счетчик узлов не обновляется для переводов.

Текст / форматы ввода

Форматы фильтров, не распознаваемые Drupal 8, будут перенесены как filter_null, фильтр, который просто возвращает пустую строку. Это означает, что любой формат ввода, использующий неизвестный формат фильтра, не будет отображать содержимое полей, хотя содержимое находится в базе данных. Это может сбивать с толку. См. # 2618332: Лучшая обработка замены отсутствующих фильтров с помощью filter_null и # 2630578: Форматы, дублированные в обновлении D6

Форматы фильтров, не распознаваемые Drupal 8, включают печально известный фильтр PHP-кода и любой другой фильтр, предоставляемый модулем contrib, который недоступен в вашей установке Drupal 8.

Фильтр PHP не поддерживается в ядре Drupal 8 - это очень плохая практика, но вы можете использовать модуль PHP для этого, если вам действительно нужно.

Чтобы исправить эту ситуацию, у вас есть несколько альтернатив:

• Проверьте, имеют ли модули, предоставляющие фильтры, версию Drupal 8 и установите их
• Отредактируйте и сохраните затронутые форматы ввода. Это удалит ссылку на format_null, и содержимое начнет отображаться. Обратите внимание, что, поскольку исходный фильтр не существует, содержимое не фильтруется и могут отображаться незамененные токены, или даже сайт может быть подвержен любой проблеме безопасности
• Отредактируйте содержимое и измените на другой формат ввода. Это переносит те же проблемы, что и предыдущий пункт

Часовые пояса и даты

Drupal 6 использует смещение часового пояса для вычисления местного времени. Drupal 7 и Drupal 8 используют имя часового пояса. К сожалению, PHP-функция timezone_name_from_abbr(), которая преобразует смещение в имена часовых поясов, будет генерировать разные имена часовых поясов в зависимости от того, включено или нет летнее время на вашем сервере. Например, временное смещение 3600 преобразуется в Европу/Париж, если летнее время выключено, и Европа/Лондон, если летнее время включено. Миграция настроена на игнорирование летнего времени. В зависимости от конфигурации вашего сервера, настройка часового пояса Drupal 8 может быть неправильной после миграции (# 2353679: отсутствует переменная миграции D6-> D8: date_default_timezone).

В часовых поясах, в которых используется летнее время, дата может интерпретироваться Drupal 8 по-разному по сравнению с Drupal 6. Например, если время около полуночи, дату можно рассматривать как другой день. Это вызывает проблемы, особенно если для построения путей используются токены даты (например, псевдонимы URL, пути к полям файлов). Два возможных решения показаны в # 2926421: Обработка несоответствий дат между D6 и D8.

URL псевдонимы

При переносе псевдонимов URL для языка, который не включен на новом сайте Drupal 8, ни один из псевдонимов не будет работать, пока вы не включите язык на новом сайте Drupal 8.

Views

Views еще не перенесены, вам нужно будет создать представления в Drupal 8 вручную. Для получения дополнительной информации, пожалуйста, обратитесь к # 2500547: Путь обновления для Views из Drupal 6 и 7 и модуль Views Migration.

Настройка блока активности пользователя

Настройки активности пользователя не переносятся. Это необходимо отредактировать вручную в соответствующем представлении в разделе фильтры / доступ (# 2169327: перенести настройку блока активности пользователя).

Drupal 7 до 8

[Исправлено] Разрешенные словари таксономического термина

В Drupal 7 разрешенный словарь для поля ссылки на термин таксономии определяется в настройках поля ссылки на термин таксономии. Этот параметр в настоящее время не переносится, что позволяет ссылаться на все словари в Drupal 8. (см. # 2763637: Поля терминов таксономии D7 не переносятся с разрешенными словарями). Вы можете вручную отредактировать настройки поля ссылки на термин таксономии в Drupal 8 после обновления и выбрать разрешенные словари.

Заблокированные IP-адреса

Столбец id из таблицы ban_ip в Drupal 7 не переносится.

Типы комментариев

Drupal 7 позволяет комментариям иметь разные поля для разных типов контента. Обычно комментарии имеют поля Автор, Тема и Комментарий. Поскольку разные комментарии D7 могут иметь разные поля, при миграции будут созданы отдельные типы комментариев D8 для каждого типа контента:

• Тип контента Foo будет иметь тип комментария comment_node_foo
• Тип контента Bar будет иметь тип комментария comment_node_bar

Единственное исключение - это комментарии на форуме. Когда модуль D8 Forum включен, автоматически создается тип комментария comment_forum. Комментарии на форуме D7 переносятся в этот тип комментариев.

Важное примечание: стандартный профиль установки Drupal 8 и тип содержимого статьи
Если ваш сайт Drupal 8 был установлен с использованием стандартного профиля установки, у вас будет тип контента под названием Article.

• Этот тип контента будет поставляться с полем комментария под названием комментарий.
• Система миграции не может предположить, что сайт D8 был установлен с использованием стандартного профиля установки. Поэтому будет создан тип комментария comment_node_article, а комментарии с типом содержимого статьи D7 будут перенесены в этот тип комментария.

В результате ваш тип контента Article теперь будет иметь два поля комментариев:

• комментарий, пришедший из стандартного профиля установки D8 и не использованный
• comment_node_article, созданный системой миграции

Скорее всего, вы не хотите иметь два поля комментариев для типа контента Article, поэтому вам нужно вручную удалить поле комментария комментария из Article (admin/structure/types/manage/article/fields). После того, как вы это сделали, вы также можете удалить тип комментария комментария (admin/structure/comment), если вы нигде не используете тип комментария comment.

Рекомендуется удалить ненужное поле комментария из типа содержимого Article перед запуском миграций, потому что ядро ​​Drupal 8 в настоящее время имеет ошибку, связанную с удалением поля комментария, см. # 2906470: Потерянные комментарии и записи в comment_entity_statistics после удаления экземпляра поля комментария 

Код PHP

Форматы фильтров, не распознаваемые Drupal 8, будут перенесены как filter_null, фильтр, который просто возвращает пустую строку. Это означает, что любой формат ввода, использующий неизвестный формат фильтра, не будет отображать содержимое полей, хотя содержимое находится в базе данных. 

Форматы фильтров, не распознаваемые Drupal 8, включают печально известный фильтр PHP-кода и любой другой фильтр, предоставляемый модулем contrib, который недоступен в вашей установке Drupal 8.

Фильтр PHP не поддерживается в ядре Drupal 8 - это очень плохая практика, но вы можете использовать модуль PHP для этого, если вам действительно нужно.

Чтобы исправить эту ситуацию, у вас есть несколько альтернатив:

• Проверьте, имеют ли модули, предоставляющие фильтры, версию Drupal 8 и установите их
• Отредактируйте и сохраните затронутые форматы ввода. Это удалит ссылку на format_null, и содержимое начнет отображаться. Обратите внимание, что, поскольку исходный фильтр не существует, содержимое не фильтруется и могут отображаться не замененные токены, или даже сайт может быть подвержен любой проблеме безопасности
• Отредактируйте содержимое и измените на другой формат ввода. Это переносит те же проблемы, что и предыдущий пункт

Поля простого текста

Противоречивые настройки обработки текста в Drupal 7
В Drupal 7 параметры обработки текста определяются в настройках экземпляра поля. Другими словами, одно и то же поле может использоваться для двух (или более) типов контента, а параметры обработки текста могут быть «Обычный текст» для одного типа контента и «Отфильтрованный текст» для другого.

Drupal 8 имеет отдельные типы хранения полей Text (обычный) и Text (отформатированный). Также есть текст (обычный, длинный) и текст (отформатированный, длинный). Важной частью здесь является то, что этот выбор делается на уровне хранения в полевых условиях. Другими словами, обычный / форматированный выбор не может быть изменен для каждого типа контента.

Миграционная система не делает никаких предположений. Если система миграции обнаруживает конфликтующие параметры обработки текста, эти поля пропускаются с сообщением журнала. У конструктора сайта есть два варианта:

1. Настройки обработки текста можно изменить на сайте Drupal 7, чтобы все типы контента, использующие текстовое поле, имели одинаковые настройки обработки текста.

• Обратите внимание при выборе способа согласования параметров обработки, чтобы избежать возможных проблем безопасности межсайтового скриптинга (XSS).
• Если в Drupal 7 для вашего поля было задано значение «Простой текст», и недоверенные пользователи могли публиковать содержимое в этом поле, возможно, эти поля содержат вредоносный ввод. Это не привело к XSS на вашем сайте Drupal 7, потому что в поле было задано Обычный текст и, следовательно, вредоносный ввод не был выполнен. Если вы теперь измените поле сейчас на Отфильтрованный текст, убедитесь, что текстовый формат не является полным HTML или подобным, что допускает злонамеренный ввод.

2. Если вам нужно иметь две разные настройки форматирования в Drupal 8, вам нужно разработать собственную миграцию, которая разделяет поля Drupal 7 на два отдельных поля Drupal 8. Дополнительную информацию о настройке миграций при обновлении до Drupal 8 можно найти здесь: Настройте миграции при обновлении до Drupal 8.

Текст со сводкой + настройка форматирования простого текста в Drupal 7
Drupal 7 имеет тип поля Long text и summary. Соответствующий тип поля в Drupal 8 - Text (отформатированный, длинный, со сводкой). В Drupal 7 можно настроить в настройках экземпляра поля, что обработка текста - это обычный текст. Поля Text (отформатированный, длинный, со сводкой) всегда являются форматированным текстом в Drupal 8.

Миграционная система не делает никаких предположений. Если система миграции обнаруживает поле «Длинный текст» и «Сводка» с настройками форматирования обычного текста, поле пропускается с сообщением журнала. Конструктор сайтов имеет те же две опции, что и выше:

1. Измените настройку форматирования поля с Обычный текст на Фильтрованный текст в Drupal 7.

• Описанное выше замечание о межсайтовом скриптинге применимо и здесь.

2. Создайте собственный путь миграции и создайте свою собственную логику того, как вы хотите перенести поля в Drupal 8. Более подробную информацию о настройке миграций при обновлении до Drupal 8 можно найти здесь: Настройте миграции при обновлении до Drupal 8.

Статистика

Настройки журнала доступа и статистические данные не i18n переносятся. Консолидация статистических данных i18n перенесена с Drupal 8.5.2. См. # 2930101: i18n / statistics - счетчик узлов не обновляется для переводов.

Views

Views еще не перенесены, вам нужно будет создать представления в Drupal 8 вручную. Для получения дополнительной информации, пожалуйста, обратитесь к # 2500547: Путь обновления для Views из Drupal 6 и 7 и модуль Views Migration.

Потенциальные конфликты ID (от D6 или D7 до Drupal 8)

Проблема

Как описано на странице подготовки к обновлению, сайт Drupal 8 должен быть полностью пустым при выполнении процесса обновления. Процесс миграции сохраняет идентификаторы исходного сайта при импорте их на сайт Drupal 8. Если контент был создан на сайте Drupal 8 до обновления (например, узел с nid 1), вполне вероятно, что идентификаторы будут конфликтовать.

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

Сценарии, которые могут привести к конфликтам ID

• Целевой сайт Drupal 8 уже использовался на момент обновления, и контент уже был создан.
• Первоначальная миграция была завершена. После начальной миграции контент или другие объекты были созданы как на исходном, так и на целевом сайтах. Когда обновленный/вновь созданный контент был перенесен с исходного сайта, идентификаторы могут конфликтовать с контентом, созданным на сайте Drupal 8.
• Место назначения Drupal 8 было в чистом состоянии, но добавленные или пользовательские модули могли добавлять данные для собственного использования, когда они были включены в Drupal 8. Например, основной модуль форума Drupal 8 создает термин таксономии для своей категории общего обсуждения. и это обычно получит ID # 1 в новой установке. Если исходные данные содержат термин таксономии с идентификатором 1, он перезапишет название категории общего обсуждения на форуме.
• Источник может иметь данные, которые не имеют идентификатора, но пункт назначения требует, чтобы у них был идентификатор. Например, Drupal 6 обрабатывает пользовательские изображения как неуправляемые файлы без идентификатора, но назначение Drupal 8 требует, чтобы у них был идентификатор. Во время миграции будут созданы управляемые файловые поля с идентификаторами, которые могут конфликтовать с файлами, которые еще предстоит перенести.
• Возможные конфликты ID с переводами не определяются автоматически.

                            - Если вы выполняете полное обновление сразу и выполняете обновление до пустого сайта Drupal 8, все должно быть в порядке.
                            - Если вы выполняете частичную миграцию после первоначального обновления и добавили переводы на свой сайт Drupal 8 до переноса обновленного / вновь созданного контента, вторая миграция может перезаписать перевод, сделанный на сайте Drupal 8.

Решения

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

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

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

Обновление многоязычных сайтов (от D6 или D7 до Drupal 8)

Для всех многоязычных миграций из модулей интернационализации Drupal 6 и Drupal 7 (i18n) и модуля преобразования сущностей Drupal 7 потребуется, чтобы на сайте Drupal 8 был включен основной модуль Drupal 8 Migrate Drupal Multilingual Module (migrate_drupal_multilingual).

Обзор обновления многоязычного Drupal 6 до Drupal 8.