«Исходная база данных не содержит узнаваемую версию Drupal».

Я установил два сайта Drupal в своей локальной среде Ubuntu для настольных компьютеров 15.10 Apache2 (2.4.12): один представляет собой свежую установку Drupal 8, а второй - копию существующего рабочего сайта, созданного с использованием Drupal 7 (который в основном состоит из модулей ядра). основанный, очень скромный с помощью страниц). Оба сайта работают без проблем, где угодно.

Моя цель - в первую очередь обновить сайт Drupal 7 до Drupal 8. Я выполнил все предварительные этапы, такие как настройка одних и тех же языков, сохранение минимума с помощью модулей (удаление любых модулей на сайте D7, которые я мог бы легко вернуть после обновления ), убедившись, что на обоих сайтах установлены одинаковые модули и т. д., и теперь я просто хочу «превзойти» (надеюсь, это хорошая формулировка) мой сайт Drupal 7 в свежий Drupal 8.

Для достижения моей цели я установил модуль обновления Drupal на своем сайте Drupal 8, зашел в localhost / sitename / upgrade и заполнил все детали сайта Drupal 7.

Когда я нажал кнопку «Обзор обновления», я получил ошибку:

Исходная база данных не содержит узнаваемую версию Drupal.

Я погуглил эту ошибку как точную фразу («Ошибка») и нашел очень мало результатов; Мне кажется, что большинство из них требуют знаний по программированию на PHP, которые я уже приобрел, поэтому я не могу определить, связана ли ошибка с ошибкой (тем более что этот модуль все еще находится в стадии разработки) или из-за моей ошибки в понимание концепции \ функциональности этого модуля.

1. По каким причинам модуль обновления D8 Drupal не «нравится» предоставленной мною базе данных D7? Тем более что сайт Drupal 7 работает нормально как онлайн, так и локально.

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

Я пошел в /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;

Тогда эта ошибка появилась в верхней части экрана.

На данном этапе, я не думаю, что есть simpleвозможность обновить с 7 до 8. Как вы можете видеть в примечании к выпуску:

Когда вы будете готовы, ядро ​​Drupal 8 также включает модуль Migrate для непосредственного обновления существующих сайтов 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должен выглядеть процесс:

1. Создайте заново сайт с той же функциональностью, что и на вашем сайте d7.
2. Воссоздать тему (используя шаблон ветки)
3. Перенос контента поверх

Стоимость этого процесса (к сожалению) одинакова для создания нового сайта или более. С № 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, и определить версию базы данных, процесс обновления просматривает таблицу 'system' - эта таблица присутствует в базе данных, которую вы указали в форме? Является ли установка Drupal в этой базе данных префиксом (и если да, вводили ли вы префикс в разделе «Дополнительные параметры» формы)? ».

• Далее следует комментарий № 4 в той же проблеме: «Предоставление префикса таблиц решило проблему».

И, конечно же, комментарий от benjy (спасибо!) Также поможет получить более подробную информацию о фактической ошибке, с которой вы столкнулись, а именно:

вы можете распечатать $ e-> getException () здесь cgit.drupalcode.org/migrate_upgrade/tree/src/… и тогда вы увидите ошибку PDO

Вы можете (временно) добавить такой отпечаток между строками 122 и 123 в коде, показанном по ссылке.

В тот момент, когда вы заставляете кодовую базу пропустить чтение {system}, она умирает, так как не находит следующую таблицу базы данных, {field_config_instance}. Другими словами: он не читает вашу базу данных D7. Возможно, он пытается прочитать D8, может быть, что-то совсем другое, откуда мы можем знать? Скорее всего, вы вводите неправильную конфигурацию БД (скажем, два сайта находятся на разных серверах, а mysql-сервер является localhost на обоих, но localhost - это не один и тот же сервер). Я только что проверил модуль вклада Migrate Upgrade и код модуля миграции ядра, и было бы очень удивительно, если бы была ошибка, связанная с префиксом, поскольку оба обрабатывают весь массив настроек базы данных, а не по частям.

Без доступа к вашей инфраструктуре невозможно сказать, как это исправить. Сожалею. Если бы я мог, я бы проголосовал, чтобы закрыть его, но, поскольку есть щедрость, я не могу. Мы не можем вам помочь, и этот вопрос не поможет другим. Единственная возможная помощь заключается в следующем: прочитайте и поймите ваш файл настроек Drupal 7 и предоставьте правильные учетные данные для модуля Migrate Upgrade (огромное количество комментариев уже показывает, что это ни к чему не приведет).

Одно возможное долгосрочное решение будет включать функцию в модуле contrib, где люди могут загрузить свои settings.php, и тогда мы сможем попробовать это использовать. Это очень хрупко, но, я думаю, стоит того. Когда кто-то успеет его закодировать ...

Я понятия не имею, почему люди так сильно проголосовали за это. Есть ли кто-нибудь еще, кто имеет такую ​​же проблему?

Много времени прошло с тех пор, как я опубликовал это, но я думаю, что теперь я знаю, в чем была проблема:

Я оставил 2-3 установленных модуля, которые я (тогда) считал «такими базовыми», поэтому я был уверен, что у них есть путь миграции, как и у всех основных модулей.

Это были, если я правильно помню: Metatag и Redirect (вы переходите от D7 Globalredirect & Redirect к просто Redirect в Drupal 8).

Я не только оставил их на сайте D7, но и установил их на D8, поэтому ни одна из версий моего сайта не была доступна только для ядра.

Это была моя первая миграция, и я совершил эту ошибку как первокурсник проекта. Я был действительно убежден, что «этого не может быть», что у этих модулей не будет пути миграции (и когда вы думаете об этом, они действительно должны иметь), но потом я обнаружил, что, действительно, обычно только основные модули имеют и что-нибудь еще остальное должно иметь пользовательский путь или путь миграции contrib.

Точно так же, как вы знаете --- Эти и другие модули имеют пути миграции contrib, которые вы можете использовать, исправляя их с помощью этого пути миграции (вы «внедряете» его в модуль вместе с путем).

Во всяком случае, это было не так для меня тогда, и я был уверен, что это идет с системой ...

Я был ужасно неправ, и это кажется мне единственной причиной, почему миграция выше не удалась; Я даже подкрепил это предположение небольшим экспериментом, который я провел перед моей последней успешной миграцией около 2 месяцев назад.

Однажды я получил это сообщение об ошибке. Оказалось, что $ db_prefix установлен мной "drupal_". Вы должны поместить это в дополнительные параметры.

С уважением, Карлос Алеман