Блог Веб-разработчика.

27 сентября 2012 года, была официально прекращена поддержка joomla ветки 1.5. На сегодняшний день последней официальной версией этой ветки системы, выпущенной в марте 2013 года в рамках ограниченной поддержки, является версия 1.5.26. С тех пор никаких обновлений не выходило, и была официально распространена рекомендация обновиться до системы ветки 2.5. Несмотря на это, многие сайты продолжают работать на старых системах. И это не мудрено, ведь подобная миграция дело не простое, редко обходится без потерь, что критически может сказаться на работоспособности ресурса.

Однако, время не стоит на месте. Система и сообщество продолжают развиваться, создавая все больше новых полезных и интересных возможностей, которые для старых версий становятся все более недоступны. Поэтому рано или поздно остро встает проблема обновления системы ради самой возможности комфортно двигаться дальше и развиваться. Обновление “чистой” системы joomla 1.5, в целом, вопросов не вызывает, однако если в системе установлены сторонние компоненты - то они вносят в процесс миграции свои нюансы, в которых необходимо разбираться и учитывать их, иначе обновление невозможно. В данной статьей пойдет речь о системе сайта на joomla 1.5.26 в связке с интернет-магазином virtuemart 1.1.9.

Признаюсь честно, когда передо мной встала такая задача, то пришлось немного помучиться, так как в основном все материалы в сети по этой теме относились к концу 2012-го - началу 2013-го годов и содержали устаревший материал, так как с тех пор все несколько изменилось. Тем не менее задача решаема и сегодня.

Инструментарий

Для обновления системы joomla 1.5.X рекомендую использовать компонент RedMigrator. Расширение (вместе с плагином) имеется в свободном доступе на сайте разработчиков расширения (http://redcomponent.com/redcomponent/redmigrator, потребуется регистрация), а также можно скачать внизу данной статьи. Для обновления же системы магазина virtuemart, наилучшей возможностью будет использование встроенного в новую систему инструмента миграции. Однако, прежде чем его использовать необходимо подготовить базу данных исходного магазина. Но обо всем по порядку...

На определенном этапе потребуется отредактивароть дамп таблиц старого магазина, для этих целей подойдет любой доступный текстовый редактор (блокнот, AlkelPad, любая IDE и  другие).

Рекомендую все работы выполнять не на рабочем сайте, а на его резервной копии, развернутой на собственном ПК. Таким образом, желательно чтобы на вашей машине было установлено любое доступное и привычное вам ПО для организации локального сервера  (Denwer, XAMPP  и другие). Хотя это и не обязательно. Если не хочется заморачиваться с локальным сервером, то Вы можете новую систему joomla 2.5.X развернуть и на удаленном сервере. Но все же, проще и спокойнее когда миграция происходит где-то под рукой.

Если все есть - можно двигаться дальше.

Общая последовательность

Подготовка и рекомендации

В двух различных директориях локального сервера необходимо полностью развернуть старый сайт и новую систему joomla 2.5.x, чистую без демо данных. На всякий случай, пока без системы Virtuemart 2.X. Если же Вы работаете на удаленном сервере, то можете в отдельной директории и на поддомене установить только чистую joomla 2.5.X. Можете также локально развернуть только новую систему и осуществить миграцию через режим RESTful-взаимодействия. Что это такое, об этом чуть ниже...

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

В систему joomla 2.5.X необходимо установить компонент RedMigrator.

Далее Вам необходимо понять, возможно ли к базе данных старого сайта подключиться из системы нового, задав соответствующие настройки в компоненте RedMigrator. Если таковое невозможно (например, Вы осуществляете миграцию удаленно, обычно хостинговые компании запрещают настройками возможность внешнего обращения к базе данных сайта) - то Вам необходимо установить в joomla 1.5.X плагин plg_redMIGRATOR. Если же база данных сайта Вам доступна и Вы можете к ней подключиться - то в установке плагина нет необходимости.

Выше вскользь уже указывал, что процесс миграции данных со старого сайта на новый достаточно ресурсоемкий, поэтому есть смысл по возможности подготовить к подобной операции и сервер. Если Вы работаете на локальном сервере или Вам доступны настройки удаленного, то установите параметры max_execution_time и memory_limit в максимально возможные значения, обычно это делается через файл php.ini:

max_execution_time = 600
memory_limit = 512 M

Настройка компонента RedMigrator

В административной панели joomla 2.5.X через раздел “компоненты” перейдите в панель RedMigrator.

В верхнем левом углу перейдите к настройкам компонента (“Options”).

В первой вкладке “Global”, Вам необходимо выбрать режим миграции данных:

  • RESTful - режим, когда миграция (перенос данных в новую систему) происходит в процессе взаимодействия компонента с административной частью старого сайта (по протоколу HTTP), это очень удобно если нет возможности из компонента обратиться к базе данных старого сайта напрямую. Этот метод достаточно медленный, но зато отлично подходит в случае если Вы хотите произвести процесс миграции между двумя удаленным друг от друга серверам. Для использования этого режима, необходимо в joomla 1.5.X установить плагин plg_redMIGRATOR, идущий в комплекте с компонентом;
  • DataBase - режим прямого подключения к базе данных старого сайта и извлечения из нее всех данных, которые затем преобразуются и записываются в базу данных нового сайта. Данный режим значительно быстре и стабильнее чем RESTful. Если оба сайта развернуты на локальном сервере, то удобнее всего использовать именно этот метод.

Соответственно, исходя из Вашей ситуации выбирайте наиболее комфортный для Вас метод.

Если Вы выбрали режим RESTful, то в следующей вкладке настроек компонента RedMigrator необходимо указать хост старого сайта, логин и пароль суперадминистратора и секретный ключ, который Вы указали в настройках плагина plg_redMIGRATOR. Если еще не настраивали этот плагин, то это нужно сделать: в административной панели старого сайта. после установки плагина перейти в раздел “менеджер плагинов”, войти в управления plg_redMIGRATOR и в соответствующее поле ввести секретный ключ, после этого сохранить настройки. Вкладку “DataBase” настроек компонента RedMigrator в таком случае - можете пропустить.

Если же Вы имеете возможность напрямую коммуницировать с базой данных старого сайта и Вы выбрали режим DataBase, то вкладку RESTful можете пропустить и сразу перейти во вкладку DataBase. Здесь необходимо указать:

  • тип базы данных (скорее всего это MySQLi);
  • хост (обычно это localhost);
  • логин пользователя базы данных, у которого есть права доступа на чтение к базе данных старого сайта;
  • пароль этого пользователя;
  • название самой базы данных старой системы на основе joomla 1.5.X;
  • а также префикс таблиц этой БД.

Далее раздел настроек “пропуски” (“skips”).

Здесь Вы можете указать какие разделы сайта можно пропустить и не переносить на новый. Если у Вас нет созданных баннеров, контактов, веб ссылок и прочего, или в каких-то разделах находится только устаревшая информация, которую переносить нет необходимости - то соответствующий переключатель установите в положение “YES”. Если же ничего пропускать не нужно, и требуется перенести все данные со старого сайта - то оставьте в этом разделе настроек все без изменений.

Раздел настроек “Templates” следует оставить без изменений, если Вы в старой системе использовали шаблон “JA Purity” или “Beez”. Эти шаблоны адаптированные под joomla 1.5 или 2.5 имеют различные имена позиций модулей. Если этот параметр оставить в положении “NO” - все старые имена позиций будут преобразованы согласно новой системе, и в новом шаблоне модули будут выводится “географически” на прежних местах. Если же Вы использовали ранее иной шаблон и в новой системе будете использовать шаблон имеющий такие же имена позиций модулей и хотите чтобы на новом сайте модули выводились в тех же местах - то установите настройку в состояние “YES”, при миграции имена позици модулей будут, скорее всего, сохранены. Однако, если Вы используете шаблон  “JA Purity” или “Beez” - то данную настройку, возможно, лучше оставить без изменений.

Настройки группы “Permissions”, возможно, имеет смысл изменять только в том случае, если Вам необходимо на новом сайте задать не стандартные распределения прав доступа для различных групп пользователей. Если же такой задачи нет, и хотите оставить распределение прав по умолчанию - то оставьте эти растройки “как есть”.

Ну и наконец, последний раздел настроек “Debug” - это, так сказать, на любителя. Если Вы предпочитаете контролировать ход процесса и видеть какие шаги система выполняет, видеть текст ошибок, если таковые возникнут - то соответствующие настройки выставьте в положение “YES”, тогда система все свои шаги операции и их статусы будет выводить на монитор. Если же не хотите себя пугать большим количеством не форматированного текста, который не очень понятен - то оставьте эти настройки без изменений.

После того как все настройки выставлены, нажмите “Save and Close” (“Сохранить и закрыть”).

Миграция joomla 1.5.X - joomla 2.5.X

Вернувшись на главную панель компонента, нажмите на большую кнопку в центре “Start Upgrade” и ... ждите.

Если Вы выбрали режим RESTful, то возможно нужно запастись терпением, так как это будет довольно продолжительный процесс. Если же Вы в режиме DataBase - то при хорошем стечении обстоятельств все должно закончится довольно быстро, пара-тройка минут - максимум.

Окончание процесса будет обозначено сообщением “Migration Successful”.

Обычно на этом этапе проблем не возникает. Теперь можете вернуться в административную панель joomla по ссылке вверху слева, и убедиться что действительно все материалы, модули (родные), пользователи и прочее, что было возможно - перенесено.

Установка virtuemart 2. X и virtuemart AIO

На этом этапе все довольно просто, комментировать особо нечего. В систему joomla 2.5.X необходимо установить компонент магазина virtuemart 2.X без демо данных. После чего установить все дополнительные расширения магазина из архива AIO (All In One). Все это стандартным путем через менеджер расширений в административной панели joomla.

Подготовка базы данных старого магазина

Для продолжения процесса обновления системы, нам необходимо “скормить” инструменту миграции в virtuemart 2.X базу данных старого магазина. При этом у нас нет возможности из системы нового магазина подключиться к базе данных virtuemart 1.X напрямую. Поэтому здесь общий план таков: необходимо из базы данных старого магазина экспортировать все таблицы магазина и импортировать их в базу данных нового, предварительно поменяв префикс таблиц со старого на новый.

Чтобы все это выполнить, в интерфейсе phpMyAdmin заходим в базу данных старого сайта и выделяем все таблицы с перфиксом #_vm_:

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

Получившийся дамп таблиц магазина сохраняем себе на компьютер.

Скорее всего префиксы имен таблиц в базе данных старого сайта и нового будут отличаться, поэтому для корректной работы виртумартовского мигратора, необходимо предварительно переименовать все таблицы, изменив префикс. Проще всего это сделать в любом текстовом редакторе с использованием инструмента “найти и заменить”. При этом важно сохранить префикс старого магазина, то есть если сначала таблица имела название “jos_vm_product_type_parameter”, то новое имя таблицы будет иметь вид типа “faw_vm_product_type_parameter” (в случае если префикс таблиц нового сайта “faw_”). После этого текстовый документ необходимо сохранить, затем импортировать в базу данных нового сайта (joomla 2.5.X).

Перенос изображений старого магазина

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

/components/com_virtuemart/shop_image/

перенести в файловую систему нового сайта по адресу:

/images/stories/virtuemart/

при этом папку “virtuemart” необходимо предварительно создать.

Настройка virtuemart 2.X и запуск миграции магазина

Мы уже почти готовы к тому, чтобы запустить процесс миграции данных самого магазина. Прежде чем это сделать, войдите в административную панель магазина virtuemart 2.X и перейдите в подраздел “Настройки”. Во вкладке “Магазин”, в самом низу, поставьте галочку напротив “Разрешить обновление базы данных”. Таким образом Вы активируете инструменты позволяющие выполнять различные операции с базой данных магазина.

После того как данная настройка сохранена, перейдите в раздел “Инструменты”, далее подраздел “Инструменты и миграция” и во вкладку “Миграция”. Убедитесь чтобы в верхней части страницы были указаны допустимые значения настроек сервера по максимальному времени исполнения скриптов и лимиту памяти.

По опыту, значений 600 секунд и 512 Мб соответственно - более чем достаточно. Если там указаны значения меньшие, то по возможности отредактируйте файл php.ini, указав необходимые величины в разделе “Resource Limits”:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
 
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time=600
 
; Maximum amount of time each script may spend parsing request data. It"s a good
; idea to limit this time on productions servers in order to eliminate unexpectedly
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time=60
 
; Maximum input variable nesting level
; http://php.net/max-input-nesting-level
;max_input_nesting_level = 64
 
; How many GET/POST/COOKIE input variables may be accepted
; max_input_vars = 1000
 
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit=512M

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

Все! Теперь все готово для запуска миграции данных из старого магазина в новый. Проверьте чтобы указатель “Выберите задачу для миграции” стоял в положении “все”, по желанию определите галочки относящиеся к номерам заказов в системе, группам пользователей, шаблонам и прочее. Обратите внимание, что Вы можете также перенести атрибуты товаров и сопутствующие товары, но это следует сделать уже после переноса товаров в базу нового магазина. Если все проставлено и настроено как Вам необходимо - нажимайте “Начать миграцию” и ... снова ждите ... долго.

Очень долго.

Миграция данных в виртумарте действительно почему-то занимает очень много времени, порой кажется что процесс уже давным-давно умер, но нет ... через какое-то время страница обновляется и становится примерно такого вида:

Если все так, то поздравляю - процесс миграции данных завершен! Если Вам необходимо так же перенести атрибуты товаров, установите соответствующий указатель и снова нажмите “Начать миграцию” - на этот раз все пройдет значительно быстрее.

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

Все только начинается...

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

Наконец, возможно самое главное, что важно учитывать: вне зависимости от того использовали ли Вы ранее SEF или нет, адреса страниц нового сайта поменяются. Это означает, что все старые ссылки, какие имелись в индексной базе поисковых систем станут не активными, и при переходе по ним поисковых роботов и пользователей - система сайта будет возвращать ошибку 404 “не найдено” (not found). Поэтому если до этого Ваш сайт был в значительной степени раскручен и имел высокую посещаемость, ТИЦ - то все это может быть потеряно и бизнес, фактически, придется начинать с нуля. Чтобы этого не произошло, необходимо заранее технически решить вопрос грамотного перенаправления со всех старых адресов на новые, так чтобы поисковые системы смогли корректно это воспринять и изменить все адреса в поисковом индексе с минимальными потерями.

Но, если все грамотно, последовательно и внимательно сделать, то после обновления сайт продолжает жить, приносить пользу своим пользователям, а хозяину приносить деньги. Что вне всякого сомнения - очень важно!

Ссылки для скачивания.

Здесь Вы можете скачать сопроводительные материалы к статье:

pkg-redMIGRATOR-UNZIPFIRST.zip (1650Kb)

* * * * * * * * * * * *

Если информация этой статьи будет интересна и полезна Вашему кругу друзей и знакомых, то Вы можете опубликовать ссылку - тогда им проще будет ее найти. Они Вам будут благодарны:).

Комментарии к статье:


Всеволод Чупрыгин © webengineer.pro 2014. Все права защищены.
Копирование материалов сайта разрешено только с указанием имени автора (Всеволод Чупрыгин) и прямой индексируемой ссылки на источник на сайте www.WebEngineer.pro.
ИП Чупрыгин Всеволод Андреевич, ИНН: 333410747832, ОГРН: 311333426300044
http://vkontakte.ru/chuprygin_va, Google +

.
Проверить аттестат
Мы принимаем Webmoney Мы принимаем практически все платежи через Robokassa Мы принимаем Яндекс.Деньги Мы принимаем платежи через QIWI. Мы принимаем платежи через привязанные к QIWI карты VISA/Mastercard.