"Джерельна база даних не містить впізнаваної версії Drupal."

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

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

Для досягнення своєї мети я встановив модуль Drupal Upgrade на своєму 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- вийшов

Трохи технічно за сценою: від 7 до 8 версії вони зберігають ту саму концепцію під час створення сайту (як вузол, сутність, дозвіл, перегляди ...), але не ядро. Я б сказав: вони змінили все на OOP, 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 Upgrade" ( https: / /www.drupal.org/project/migrate_upgrade ).

Це показує, що це не помилка, а натомість "виняток, який кидають". Переглядаючи 3 попередні рядки цього коду, я думаю, що це лише проблема в налаштуванні з'єднання.

Можливо, це також допомагає:

• цитата з випуску https://www.drupal.org/node/2628440 (коментар № 3):

  Щоб перевірити, чи є вихідна база даних дійсною базою даних Drupal, і щоб визначити версію бази даних, процес оновлення дивиться на таблицю "система" - чи є ця таблиця в базі даних, яку ви вказали у формі? Чи встановлено 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 і надайте правильні дані модулю міграції оновлення (величезна кількість коментарів уже показує, що це вже нікуди.)

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

Я поняття не маю, чому люди так сильно протистояли цьому. Чи є ще хтось із тією ж проблемою?

З моменту публікації цього часу минуло багато часу, але я думаю, що тепер знаю, у чому проблема:

У мене залишилось встановлено 2-3 модулі, які я (тоді) вважав "такими основними", тому я був впевнений, що вони мають шлях міграції так само, як і всі основні модулі.

Це, якщо я правильно пам’ятаю: метатаг та перенаправлення (ви переходите від D7 Globalredirect & Redirect до просто перенаправлення в Drupal 8).

Я не тільки залишив їх на сайті D7, але і встановив їх у D8, тому жодна з версій мого сайту не була лише базовою.

Це була моя перша міграція, і я допустив цю помилку, будучи першокурсником проекту. Я дійсно був переконаний, що "не може бути", що ці модулі не матимуть шлях міграції (а коли ви думаєте про це, вони насправді повинні мати), але потім я виявив, що, як правило, зазвичай є тільки основні модулі і все, що завгодно інше повинно мати спеціальний або внести шлях міграції.

Просто так ви знаєте --- Ці та інші модулі мають вкладні шляхи міграції, якими ви можете скористатися, закріпивши їх цим міграційним шляхом (ви "вводите" його в модуль разом із контуром).

У всякому разі, для мене тоді це було не так, і я був впевнений, що це стосується системи ...

Я болісно помилявся, і це здається мені єдиною причиною того, що міграція вище не вдалася; Я навіть підкріпив це припущення невеликим експериментом, який я зробив до моєї останньої успішної міграції близько 2 місяців тому.

Як тільки я отримав це повідомлення про помилку. Виявилося, це $ db_prefix, встановлений мною "drupal_". Ви повинні поставити це в розширених варіантах.

З повагою, Карлос Алеман