[Решено] Апгрейд Drupal 6.22 на 7.8

Главные вкладки

Аватар пользователя AlGin@drupal.org AlGin@drupal.org 21 сентября 2011 в 1:59

Приветствую!
Сразу хочу отметить, что проблема обозначена в названии темы. Есть сайт о моём хобби, использующий как "движок" Drupal, тоже моё маленькое хобби. Построен на D5, без проблем переведённый на D6, и переживший все минорные апгрейды до D6.22. Решил вдохнуть новую жизнь в своё детище, в честь 10-летия в инете, но сначала перейти на D7. Проанализировал параметры хостинга (платный, виртуальный сервер) - ОК. Удалил, скрипя сердцем, некоторые модули, перевёл на тему с поддержкой D7. Скачал дистрибутив D7.8. Внимательно прочитал UPGRADE.TXT несколько раз. И в выходные выделил время для эксперементов прямо "на живую" - ещё раз повторюсь, сайт не коммерческий, хостинг с CPanel, восстановление из бэкапа 10-15 минут. Конечно в UPGRADE.TXT написано, что если не получилось с первого раза, надо остановиться, восстановить сайт из бэкапа и обратиться за поддержкой. Я так и делал, примерно. Изучал drupal.ru и drupal.org, но ответов не нашёл. И так раз 7. Теперь точно следую совету из UPGRADE.TXT и хочу обратиться с вопросом.

Кто либо из здесь присутствующих сделал апгрэйд Drupal 6.22 на Drupal 7.8 УСПЕШНО?

Если да, то где я не "тут"?

Исходные данные - Drupal 6.22, модули:
1. Administration menu 6.x-3.0-alpha4
2. AdSense 6.x-1.3
3. Localization update 6.x-1.0-beta1
4. Printer-friendly pages 6.x-1.14
5. Skinr 6.x-2.x-dev
6. CAPTCHA 6.x-2.4
7. CKEditor 6.x-1.6
8. External Links 6.x-1.11
9. Comment Notify 6.x-1.6
10. IMCE 6.x-2.2
11. Lightbox2 6.x-1.11
12. simple_gmap
13. Site map 6.x-2.2
14. Taxonomy Manager 6.x-2.2
остальные корректно удалил.

После 3 попытки апгрейда решил проверить свой файл sites/default/settings.php. Дело в том, что в UPGRADE.TXT упоминается стока $update_free_access = FALSE, при проблеме запуска скриптов через update.php (у меня апдейт запускался, но заканчивался всегда ошибкой). Такой строки в settings.php моего рабочего сайта не было. Скачал дистрибутив D6.22, в текстовом редакторе дополнил свой установочный файл, загрузил на сайт, запустил update.php, проверил "Отчёт о состоянии" - всё ОК.

Дальнейшие попытки апгрейда также не принесли успеха.
Привожу два окна сообщения об ошибках. Во всех случаях повторное нажатие F5, или попытка перейти по ссылкам "администрирование" или "лог сайта" приводили к белому экрану с ошибкой.

Окно 1 ===========================================
Warning: Cannot use a scalar value as an array in /home6/yl3bu/public_html/modules/locale/locale.module on line 680
The following updates returned messages
user module
Update #7000
User passwords rehashed to improve security
Update #7002
Migrated user time zones
Update #7014
Renamed the 'post comments without approval' permission to 'skip comment approval'.
Update #7017
The ability to send users their passwords in plain text has been removed in Drupal 7. Your existing email templates have been modified to remove it. You should review these templates to make sure they read properly.
system module
Update #7007
Inserted into {role_permission} the permissions for role ID 1, Inserted into {role_permission} the permissions for role ID 2, Inserted into {role_permission} the permissions for role ID 3, Inserted into {role_permission} the permissions for role ID 5
Update #7061
Upload module has been migrated to File module.
Fatal error: Call to undefined function db_result() in /home6/yl3bu/public_html/modules/php/php.module(74) : eval()'d code on line 2

Окно 2 ===============================================
Error
DatabaseSchemaObjectExistsException: Cannot add index system_list to table system: index already exists. in DatabaseSchema_mysql->addIndex() (line 432 of /home6/yl3bu/public_html/includes/database/mysql/schema.inc).
The website encountered an unexpected error. Please try again later.
Uncaught exception thrown in session handler.
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 4b34d037448c0c76320650e451f3ae83 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 203 of /home6/yl3bu/public_html/includes/session.inc).

Я не гуру, хотя написал для своих нужд 2 модуля, но был перерыв около 2-х лет, может что-то подзабыл.
Подскажите где рыть, если это возможно. На "хабре" наткнулся на нелестные отзывы о развитии Drupala, упоминаются подобные проблемы перехода с D6 на D7, с выводом, что D7 ещё далеко не готов. Неужели всё так плохо?
Спасибо.
С уважением,
Александр.
Рига

Комментарии

Аватар пользователя mak-vardugin mak-vardugin 21 сентября 2011 в 4:47

Не торопитесь, Александр. Часть модулей еще не готова, skinr точно еще не фурычит.
Ответьте хотя бы себе зачем переводить хорошо работающий сайт на 7?
Перечисленные вами модули еще долго будут сохраняться в актуальном состоянии.

Аватар пользователя AlGin@drupal.org AlGin@drupal.org 21 сентября 2011 в 10:11

"mak-vardugin" wrote:
Не торопитесь, Александр. Часть модулей еще не готова

Спасибо за ответ. Да, очевидно поторопился, но уже начал - убил дизайн, снёс часть модулей, готов и ещё некоторые убрать. В последнее время захватила волна "минимализма" Lol Но, очевидно, и не в модулях дело, а в неготовности самого ядра D7. Процедуру апгрейда D6 на D7 я тоже отношу к ядру семёрки, я думаю, это логично. И если само ядро D7 ещё доводится молотком, то подгонять к нему отдельно взятые модули мелкой наждачкой будут ещё долго. И раз я уж устроил себе этот "праздник", мне просто интересно - вдруг кто-то всё-таки перешёл на 7-ку (?), и хотя бы, без существенных осложнений.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 21 сентября 2011 в 10:14

"<a href="mailto:AlGin@drupal.org">AlGin@drupal.org</a>" wrote:
и не в модулях дело, а в неготовности самого ядра D7. Процедуру апгрейда D6 на D7 я тоже отношу к ядру семёрки, я думаю, это логично.

Меньше думайте, причины неудачного апгрейда семёрки в большинстве случаев в кривом апдейте на шестёрку

Аватар пользователя AlGin@drupal.org AlGin@drupal.org 21 сентября 2011 в 10:46

"RxB" wrote:
Меньше думайте, причины неудачного апгрейда семёрки в большинстве случаев в кривом апдейте на шестёрку

Виктор, огромное спасибо за ссылку, очень интересно - анализ и работа проделана большая и получен результат.
Как я понял, надо оставить 7-ку в покое и критически присмотреться к своей родной и "правильной" шестёрке.

Аватар пользователя AlGin@drupal.org AlGin@drupal.org 3 октября 2011 в 13:33

Да, заглянул в свою базу данных D6.22, там больше 140 таблиц ... Как я понимаю, это очень много - результаты эксперементов за последние годы. При сносе модулей я всегда делал и "Удаление", чтобы очистить и БД, но, очевидно, не всегда это корректно отрабатывало. Загрузил модуль "Схема", он рапортует о примерно 70 таблицах в БД не соответсвующих API (остальные примерно 70 - ОК).
Честно говоря за долгое время я и забыл что я точно ставил и сносил.
Как сделать анализ что из этого списка таблиц нужно, а что не нужно и можно удалить?
Где можно посмотреть список таблиц чистой БД D6.22, чтобы сравнить с моей и принять решение об удалении ненужных таблиц?
Спасибо.

02.10.2011

Отключил и удалил максимальное количество модулей, которые не влияют на основные функции сайта.
Например: Taxonomy Manager, Site Map, External Link, Print и т.д. Естественно, в первую очередь, не портированные в D7, например Birthday. Скрипя сердцем и Capcha тоже.

Взял список таблиц "Extra" из рапорта модуля схема и начал их переименовывать, добавляя префикс "DEL_". Делал бекапы, проверял функциональность сайта, запускал update.php и крон на всякий случай. Заодно знакомился с БД и с назначением каждой таблицы, соответствие таблиц D6 и D7. После переименования всех таблиц и окончательной проверки все таблицы с моим прификсом "DEL_" были удалены. Как и писал Виктор (RxB), и моя БД представляла смесь таблиц двух версий Друпала после неудачной попытки апргрейда.

После этого сделал апгрейд в точности согласно UPGRADE.txt. Апгрейд прошёл успешно.

Всё это было сделано с копией сайта на локальной машине и Денвере. И после этого повторено на "живом" сайте.

Кстати на локальной машине (у меня P4, 2.6GHz) и Денвере апгрейд проходил очень тяжело. На Денвере а php.ini увеличил "maximum_execution_time" (кажется так правильно это называлось) до 300 секунд и даже после этого получал "белое окно", нажимал F5 раз пять и, уже не надеясь на лучшее, ждал когда это безобразие закончится. И оно закончилось, и успешно, чем меня поразило. На хостинге с живым сайтом этот процесс пролетел, как говорят "со свистом".

Вот всё.
Спасибо.