"Исходная база данных не содержит узнаваемой версии Drupal".
Я установил два сайта Drupal в своей локальной среде Ubuntu desktop 15.10 Apache2 (2.4.12): один - это новая установка Drupal 8, а второй - копия существующего рабочего сайта, построенного с помощью Drupal 7 (который в основном основан на основных модулях, очень скромный с помощью страниц). Оба сайта работают нормально, без каких-либо проблем, где угодно.
Моя цель - в первую очередь обновить сайт Drupal 7 до Drupal 8. Я выполнил все предварительные этапы, такие как настройка те же языки, Сохраняйте минимум с помощью модулей (удалите все модули на сайте D7, которые я мог бы легко вернуть после обновления), убедитесь, что на обоих сайтах установлены одни и те же модули и т. Д., И теперь я просто хочу "Превзойти" (надеюсь, это хорошая формулировка) мой сайт Drupal 7 в новый сайт Drupal 8.
Для достижения своей цели я установил модуль Обновления Drupal на своем сайте Drupal 8, зашел на локальный хост/имя сайта/обновление и заполнил все детали Drupal 7 сайт.
Когда я нажал кнопку "Просмотреть обновление", я получил сообщение об ошибке:
Исходная база данных не содержит узнаваемой версии Drupal.
Я прогуглил эту ошибку как точную фразу ("Ошибка") и нашел очень мало результатов; Большинство из них, как мне кажется, требуют знаний в области программирования на PHP, которые я еще не приобрел, поэтому я не могу определить, вызвана ли ошибка ошибкой (тем более, что этот модуль все еще находится в стадии разработки) или из-за моей ошибки в понимание концепции\функциональности этого модуля.
По каким причинам модуль обновления D8 Drupal не "нравится" базе данных D7, которую я предоставил? Особенно в то время как сайт Drupal 7 отлично работает как онлайн, так и локально.
Будет ли миграция достойной альтернативой для обновления, если обновление невозможно по какой-либо причине? Если да, то какое лучшее и самое простое решение Вы могли бы придумать для миграция?
Я пошел в/var/www/html/benia/modules/migrate_upgrade/src/MigrationCreationTrait.php и сделал:
-- return $version_string ? substr($version_string, 0, 1) : FALSE;
++ return 7;
++ return $version_string ? substr($version_string, 0, 1) : FALSE;
Чем получил эту ошибку в верхней части экрана.
5 answers
На данном этапе я не думаю, что есть возможность simple обновить с 7 до 8. Как вы можете видеть в примечании к выпуску:
Как только вы будете готовы, ядро Drupal 8 также включает модуль миграции для прямого обновления существующих сайтов Drupal 7 и 6 до Drupal 8. Миграция помечена как "экспериментальная" в Drupal 8.0.0, но будет полностью поддерживаться в следующем выпуске. https://www.drupal.org/news/drupal-8.0.0-released
Немного техническая отсталость сцена:
С 7 по 8 версии они сохраняют ту же концепцию при создании сайта (например, узел, сущность, разрешение, представления...), но не ядро. Я бы сказал: они изменили все на ООП, компонент Symfony, архитектуру...
Таким образом, нет способа upgrade перевести ваш сайт drupal непосредственно с достойной версии на 8.0, вам нужно migrate. Вот как должен выглядеть процесс migrating:
- Создайте сайт с той же функциональностью, что и на вашем сайте d7.
- Воссоздайте тему (используя веточку шаблон)
- Перенос содержимого через
Стоимость этого процесса (к сожалению) одинакова для воссоздания нового сайта или более. С номером 3 взгляните на эту статью по этапу 2: https://www.phase2technology.com/blog/upgrading-to-a-drupal-8-site/
Ваше сообщение об ошибке точно совпадает со строкой, содержащейся в строке по адресу http://cgit.drupalcode.org/migrate_upgrade/tree/src/MigrationCreationTrait.php#n40 в коде модуля "Обновление Drupal" (https://www.drupal.org/project/migrate_upgrade).
Это показывает, что это не ошибка, а "выбрасываемое исключение". Глядя на 3 предшествующие строки этого кода, я думаю, что проблема заключается только в настройке соединения.
Может быть это также помогает:
-
Цитата из выпуска https://www.drupal.org/node/2628440 (комментарий №3):
Чтобы проверить, что исходная база данных является действительной базой данных Drupal, и определить версию базы данных, процесс обновления просматривает таблицу "система" - присутствует ли эта таблица в базе данных, указанной вами в форме? Имеет ли установка Drupal в этой базе данных префикс (и если да, то ввели ли вы префикс в разделе "Дополнительные параметры" форма)?".
-
С последующим комментарием № 4 в том же выпуске: "Предоставление префикса таблиц решило проблему".
И, конечно, комментарий от бенджи (спасибо!) также поможет получить более подробную информацию о фактической ошибке, с которой вы столкнулись, т.Е.:
Вы можете распечатать $e->getexception() здесь cgit.drupalcode.org/migrate_upgrade/tree/src /...и тогда вы увидите ошибку PDO
Вы могли бы (временно) добавить такую печать между строками 122 и 123 в коде, показанном по ссылке.
В тот момент, когда вы заставляете базу кода пропустить чтение {system}, она умирает, не найдя следующую таблицу базы данных, {field_config_instance}. Другими словами: он не читает вашу базу данных D7. Возможно, он пытается прочитать D8, возможно, что-то совершенно другое, как мы могли знать? Более чем вероятно, что вы вводите неправильную конфигурацию БД (скажем, два сайта находятся на разных серверах, причем сервер mysql является локальным хостом на обоих, но локальный хост не является одним и тем же сервером). Я только что проверил Модуль переноса содержимого обновления и основной код модуля переноса, и было бы крайне удивительно, если бы возникла ошибка, связанная с префиксом, поскольку оба обрабатывают весь массив настроек базы данных, а не по частям.
Невозможно сказать, не имея доступа к вашей инфре о том, как это исправить. Извините. Если бы я мог, я бы проголосовал за его закрытие, но, поскольку есть награда, я не могу. Мы не можем помочь вам, и этот вопрос не поможет другим. Единственная возможная помощь заключается в следующем: прочитайте и поймите ваш файл настроек Drupal 7 и предоставьте правильные учетные данные модулю обновления миграции (огромное количество комментариев уже показывает, что это никуда не приведет.)
Одним из возможных долгосрочных решений было бы включение функции в модуль contrib, где люди могут загружать свои settings.php и тогда мы могли бы попробовать использовать это. Это чрезвычайно хрупко, но, думаю, стоит попробовать. Когда у кого-то будет время его закодировать...
Я понятия не имею, почему люди так сильно поддержали это. Есть у кого-нибудь еще есть такая же проблема?
Прошло много времени с тех пор, как я опубликовал это, но я думаю, что теперь я знаю, в чем была проблема:
Я оставил 2-3 установленных модуля, которые я (тогда) считал "такими простыми", поэтому я был уверен, что у них есть путь миграции, как и у всех основных модулей.
Это были, если я правильно помню: Метатег и перенаправление (вы переходите с D7 Globalredirect & Redirect на просто перенаправление в Drupal 8).
Я не только оставил их на сайте D7, я также установил их в D8, так что ни один из версии моего сайта были только основными, по мере необходимости.
Это была моя первая миграция, и я совершил эту ошибку, будучи новичком в проекте. Я был действительно убежден, что "этого не может быть", что у этих модулей не будет пути миграции (и, если подумать, у них действительно должен быть путь миграции), но затем я обнаружил, что на самом деле, как правило, есть только основные модули, и все остальное должно иметь пользовательский или дополнительный путь миграции.
Просто чтобы вы знали --- В этих и других модулях есть contrib пути миграции, которые вы можете использовать, исправляя их с помощью этого пути миграции (вы "вводите" его в модуль вместе с путем).
В любом случае, тогда это было не так для меня, и я был уверен, что это входит в систему...
Я был болезненно неправ, и мне кажется, что это единственная причина, по которой вышеприведенная миграция не удалась; Я даже подкрепил это предположение небольшим экспериментом, который я провел перед своей последней успешной миграцией около 2 месяцев назад.
Как только я получил это сообщение об ошибке. Оказалось, что это $db_prefix, установленный мной "drupal_". Вы должны указать это в дополнительных параметрах.
С уважением, Карлос Алеман