Домой / OpenCart 2x / Перенос данных OpenCart с версии 1.5.5.1 на 2.0.2.0

Перенос данных OpenCart с версии 1.5.5.1 на 2.0.2.0

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

Итак, исходные данные задачи: имеется работающий магазин на OpenCart 1.5.5.1, решено перенести на VPS-хостинг, при этом доменное имя сохраняется, а вот версия магазина должна быть уже 2.0.2.0.

С одной стороны, казалось-бы задача несложная, так-как домен и адрес магазина по сути не меняются. А с другой - всё осложняется тем, что каждая последующая ветка OpenCart имеет несколько отличную структуру базы данных, чем предыдущая. Поэтому просто скопировать базу данных не получится...

Почему я не использовал специальный модуль

В каталоге дополнений OpenCart я нашёл модуль, который вроде-бы осуществляет такой перенос данных. Но модуль платный, стоит около $100...

По началу я собирался воспользоваться этим модулем и уже запросил у руководства выделение средств на его покупку. Но вот характер у меня вредный, иногда сам не рад - в тот момент, когда руководство дало согласие на выделение указанной суммы, меня вдруг посетила мысль: «Что-ж я, дурнее паровоза, что-ли?». И я дал «Отбой». После чего пришлось включать собственные мозги... Как говорится - дурная голова ногам покоя не даёт. 😀

Определяемся с задачей

Что нам по сути нужно и важно? Из всей базы данных мне нужно было сохранить базу клиентов и историю их заказов. Что-бы во-первых, не пострадала статистика магазина, во-вторых, не потерять этих самых клиентов, в-третьих, чтобы они могли заходить в новый магазин под своими логинами и паролями и в-четвёртых - могли видеть историю своих покупок.

Все остальные данные я настраивал в новом магазине заново. Например, можно было перенести ещё и статусы заказов, но в старом магазине я просто перевёл их все с английского на русский, а там их штук 15, если не больше, из которых реально использовались только 3 - 4. Поэтому в новом варианте я сразу удалил все лишние статусы и оставил только используемые.

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

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

Все эти таблицы я скопировал себе на компьютер при помощи SQL-запросов через PhpMyAdmin. Об этом чуть ниже...

Вот, сделал некую справочную таблицу по этому поводу:

Таблица Описание sql-файл
customer Данные клиентов customer.sql
customer_ip С каких IP заходили customer_ip.sql
order Заказы order.sql
order_history История заказов order_history.sql
order_product Товары в заказах order_product.sql
order_status Статусы, присвоенные конкретным заказам order_status.sql
order_total Итоговые данные по заказам order_total.sql

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

Практический перенос данных

Давайте уже от слов перейдём к делу и для начала получим эти самые SQL-фалы на свой компьютер.

Как говорят иногда после показа некоторых видеороликов - не советуем повторять это дома... 😆  Особено, если Вы незнакомы с PhpMyAdmin и не понимаете, что такое SQL-запрос.

Получение SQL-файлов

PhpMyAdmin Для начала запускаем PhpMyAdmin на хосте старого магазина и выбираем нужную базу данных...
PhpMyAdmin 

Затем выбираем нужную таблицу - её данные должны отобразиться в центре.

После чего кликаем на вкладке «Экспорт»

 

 PhpMyAdmin

 Здесь ничего не меняем и просто кликаем на кнопку «Ок».

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

SQL экспорт

Появится вот такое окно и нам ничего больше не остаётся, как сохранить этот файл себе на компьютер.

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

Как видите - ничего сложного тут нет.

Готовим данные к переносу

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

Открываем полученный файл (всё на примере того-же customer.sql) и удаляем из него всё с самого начала и до строк 52 - 54, они выделены в конце кода. Эти строки и всё, что ниже их должно остаться.

-- phpMyAdmin SQL Dump
-- version 4.0.8
-- http://www.phpmyadmin.net
--
-- Хост: localhost
-- Время создания: Июн 08 2015 г., 09:24
-- Версия сервера: 5.5.35-cll
-- Версия PHP: 5.3.17

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;

--
-- База данных: `ddwshop_ok`
--

-- --------------------------------------------------------

--
-- Структура таблицы `customer`
--

CREATE TABLE IF NOT EXISTS `customer` (
  `customer_id` int(11) NOT NULL AUTO_INCREMENT,
  `store_id` int(11) NOT NULL DEFAULT '0',
  `firstname` varchar(32) NOT NULL,
  `lastname` varchar(32) NOT NULL,
  `email` varchar(96) NOT NULL,
  `telephone` varchar(32) NOT NULL,
  `fax` varchar(32) NOT NULL,
  `password` varchar(40) NOT NULL,
  `salt` varchar(9) NOT NULL,
  `cart` text,
  `wishlist` text,
  `newsletter` tinyint(1) NOT NULL DEFAULT '0',
  `address_id` int(11) NOT NULL DEFAULT '0',
  `customer_group_id` int(11) NOT NULL,
  `ip` varchar(40) NOT NULL DEFAULT '0',
  `status` tinyint(1) NOT NULL,
  `approved` tinyint(1) NOT NULL,
  `token` varchar(255) NOT NULL,
  `date_added` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`customer_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=173 ;

--
-- Дамп данных таблицы `customer`
--

 Номера строк могут быть и другими, но тут ключевыми словами, своеобразной зацепкой является фраза: «Дамп данных таблицы... » 

Теперь пролистываем файл в самый низ и там, под данными клиентов, удаляем вот такие (или подобные) строки:

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

 По итогу, у нас должно остаться вот это:

--
-- Дамп данных таблицы `customer`
--

INSERT INTO `customer` (`customer_id`, `store_id`, `firstname`, `lastname`, `email`, `telephone`, `fax`, `password`, `salt`, `cart`, `wishlist`, `newsletter`, `address_id`, `customer_group_id`, `ip`, `status`, `approved`, `token`, `date_added`) VALUES
(1, 0, 'Александр', 'Каратаев', 'ddw2@yandex.ru', '293-ХХ-ХХ', '', '50d45586424685242df2958fb3782e76aac38c48', '59cb9e002', 'a:0:{}', 'a:3:{i:0;s:4:"3340";i:1;s:3:"239";i:2;s:4:"1872";}', 1, 1, 1, 'ХХ.ХХ.ХХ.ХХХ', 1, 1, '', '2013-02-12 15:14:37'),
--- тут куча данных по другим клиентам 
(172, 0, 'Иван', 'Пупкин', 'pupkin.@mail.ru', '8707XXXXXXX', '', '89a6b6b85481b5a1801c5f82717eb0266b734864', 'f68626671', 'a:1:{i:9373;i:1;}', 'a:33:{i:0;s:4:"9373";i:1;s:4:"9374";i:2;s:4:"9459";i:3;s:4:"9463";i:4;s:4:"9465";i:5;s:4:"9487";i:6;s:5:"12164";i:7;s:4:"9488";i:8;s:4:"9496";i:9;s:4:"9490";i:10;s:4:"9503";i:11;s:4:"9493";i:12;s:4:"9499";i:13;s:4:"9494";i:14;s:4:"9492";i:15;s:4:"9497";i:16;s:4:"9500";i:17;s:4:"9501";i:18;s:4:"9408";i:19;s:4:"9410";i:20;s:4:"9411";i:21;s:4:"9688";i:22;s:4:"9692";i:23;s:4:"9693";i:24;s:4:"9537";i:25;s:5:"12229";i:26;s:4:"9565";i:27;s:4:"9567";i:28;s:4:"9568";i:29;s:4:"9573";i:30;s:4:"9694";i:31;s:4:"7769";i:32;s:4:"7662";}', 0, 186, 1, 'ХХ.ХХ.ХХ.Х', 1, 1, '', '2015-06-03 14:45:11');

  Естественно, что цифры даже в закодированных паролях я случайным образом изменил, а в каких-то данных вместо цифр проставил «Х»... Ну так... На всякий случай...

И, наконец, последним шагом подготовки этого файла является замена имени самой таблицы. Дело в том, что в старом магазине таблица называлась «customer», а в новом она называется по другому - «ok_customer».

Эту замену надо произвести в команде INSERT. Просто меняем там старое имя на новое.

Было: INSERT INTO `customer`

Стало: INSERT INTO `ok_customer`

 

 

 При этом надо учесть, что таких команд по файлу может быть несколько - зависит от объёма данных. Замену нужно сделать во всех таких командах.

Всё, файл готов для переноса информации в новый магазин. Точно так-же поступаем и со всеми остальными sql-файлами. Кому-то это может показаться сложным, но на самом деле это не так. Главное уловить суть - убрать из файла всё, что не касается вставки данных в таблицу.

Готовим базу нового магазина к приёму данных

Помните, я говорил, что в разных версиях OpenCart есть различия в структуре некоторых таблиц?

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

SQL

Подобные ошибки могут появиться по нескольким таблицам.

Причина - несоответствие структуры таблиц.

Поэтому мы не будем нарываться на это безобразие, а заранее устраним причину.

Запускаем всё тот-же PhpMyAdmin, но уже на хосте нового магазина.

PhpMyAdmin Как и в первом случае выбираем нашу базу, но вкладку теперь используем другую - «SQL».
SQL

Сам SQL-запрос я покажу ниже.

Не забываем нажать кнопку «Ок».

 А вот и нужный нам SQL-запрос. Он одним махом устраняет несоответствия по всем таблицам, которые мы затрагиваем переносом данных.

ALTER TABLE `ok_order` ADD `payment_company_id` VARCHAR( 32 ) NOT NULL AFTER `payment_company` ;
ALTER TABLE `ok_order` ADD `payment_tax_id` VARCHAR( 32 ) NOT NULL AFTER `payment_code` ;
ALTER TABLE `ok_order_total` ADD `text` VARCHAR( 255 ) NOT NULL AFTER `title` ;

  В нашем случае несоответствия структуры присутствуют всего в двух таблицах.  В одну мы добавили два недостающих поля, в другую одно. И всё это мы сделали одним запросом.

Теперь уже ничто не препятствует нам перенести данные.

Импорт данных в новый магазин

Импорт, в принципе, можно осуществить двумя способами. Оба они предполагают использование всё того-же PhpMyAdmin, естественно, что на новом хосте.

  1. Способ первый, точно такой-же, которым мы устраняли несоответствия в таблицах. Только в поле SQL-запроса нужно поочерёдно вставлять весь код из каждого подготовленного нами sql-файла, не забывая каждый раз нажимать кнопку «Ок».
  2. Способ второй. В PhpMyAdmin выбираем не вкладку «SQL», а вкладку «Импорт».
Импорт

Этот способ мне кажется более удобным.

Выбираем нашу базу, жмём «Импорт», Выбираем поочерёдно подготовленные sql-файлы и нажимаем кнопку «Ок».

Лично я использовал второй способ.

Прибираем за собой

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

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

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

Это мы сейчас и сделает тем-же самым способом, которым добавляли поля, только сам SQL-запрос, естественно, будет несколько иным.

Вот он:

ALTER TABLE `ok_order` DROP `payment_company_id` 
ALTER TABLE `ok_order` DROP `payment_tax_id` 
ALTER TABLE `ok_order_total` DROP `text` 

 Как и в случае с добавлением полей всё делаем одним SQL-запросом.

На этом наша задача выполнена. Магазин полностью готов. Он без потерь подхватил эстафету старого OpenCart 1.5.5.1 и сходу включился в работу как ни в чём ни бывало.

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

Заключение

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

В частности вот эту самую статью я планировал написать давно, что называется - по горячим следам. Да всё руки как-то не доходили.

А ведь представленный здесь окончательный и вылизанный вариант рождался путём проб и получения кучи ошибок на каждом этапе. Многое достигалось методом научного и не очень тыка. Благо был тестовый магазин, на котором и проводились все эти эксперименты. К рабочему магазину был применён уже окончательный вариант, описанный в статье.

Но время шло и какие-то нюансы уже начали меркнуть в моём мутнеющем сознании, занятом к тому-же совершенно другими задачами, иными проектами вообще никак не связанными с OpenCart. Хорошо ещё в своё время я сообразил сделать несколько скриншотов и сохранить какие-то коды. И как знать? Может подобная задача возникнет когда-то в будущем...

Я прекрасно понимаю, что моим читателям эта статья будет совершенно не интересна - вы, дорогие мои, не работаете с OpenCart, а если вдруг кто-то и работает, то очень сомнительно, что ему надо куда-то переносить какие-то данные. Поэтому, соответственно не жду здесь никаких комментариев.

Тем не менее, если вдруг кто-то в поисках решения забредёт на мой блог и статья окажется ему полезной - я буду только рад.

На этом всё. Удачи Вам и до встречи на наших блогах.

34 комментария

  1. Саша, привет! Прочитал с интересом, правда не все понял, но знакомые слова и функции, встречались. Так что благодаря тебе, учимся  потихоньку. Мало ли, вдруг пригодится. 

  2. Добрый день. А мне только сегодня пришло уведомление о новой статье,в 11-12 Москвы 🙂  но хорошо, что хоть вообще дошло.

    Да, сознаюсь, мне статья неинтересна :), я не понимаю ничего в этих алгоритмах и кодах. Но рада, что это будет полезно умным людям, в чём не сомневаюсь.

    Саша, тебе новых идей!

    • А мне только сегодня пришло уведомление о новой статье

      Люда, привет! Спасибо, что зашла. Я рассылку только сегодня и сделал… Обычно UniSender автоматом RSS с блога рассылал, но в последнее время там висит статус "Адрес RSS ленты недоступен". Хотя на самом деле лента доступна. У них там два валидатора, причём один показывает, что всё нормально, а тот, что срабатывает перед самой рассылкой — выдаёт ошибку. Техподдержка, если честно меня разочаровала — говорят решение проблемы поставлено в очередь… Но уже с 9-го числа эта проблема у них висит в тикетах…

      Так, что пришлось эту рассылку оформлять ручками… Немного недоработал её, в следующий раз учту все моменты… А может уже и проблему решат к следующему разу…

  3. Ага, нашла я статью о смене хостинга! А я то уж подумала, что ты свой блог на новый хостинг перенёс. Я тоже задумываюсь о переезде, но боюсь рисковать, хочется сначала найти хороший хостинг, и не так, что кто то рекомендует, потому что зарабатывает там на привлечении клиентов, а так, что человек советует потому что сам живёт на хостинге без проблем, зависаний и отписок.

    А статья действительно нужная, трудно удержать такую информацию в голове, я тоже часто пишу шпаргалки больше для того, чтобы были под рукой! 

    no

    • Ирина, а почему вы хотите сменить хостинг? Спрашиваю потому что сам на таком же сижу. С этим хостингом у меня проблем нету.

      • Потому что у меня постоянные проблемы с доступностью сайта, хотя посещаемость не большая, а потребление ресурсов зашкаливает. Просила тех поддержку сказать в чём причина, они посоветовали перейти на тариф выше, я сменила тариф, а проблемы остались, опять написала, ответили, что нужно ещё выше. А куда выше? На моём тарифе должны пять полноценных сайтов работать без проблем, А у меня один сайт, и тот вечно недоступен. Трафик теряю из за этого. Вот думаю тему поменять. Она у меня давно не обновлялась. Я уже вычистила всё, что могла, снесла половину плагинов, удалила дубли изображений, очистила базу, а проблема осталась. 

        • Значит, что-то с блогом. У вас одни только виджеты социальных сетей съедают немалое количество ресурсов. Лучше уберите их все и сделайте обычные кнопки на эти сети. Отключите смайлики Эмоджи. Уберите лишние счетчики. Оставьте только самые необходимые. Gif изображения замените на обычные. Уберите лишние виджеты: свежие записи, общительные люди. Кроме оптимизации базы, удалите из нее весь мусор от неиспользуемых плагинов, различной статистики и так далее.

          • Спасибо за совет, мусор я базы я удаляла, чистила её по описанию веб мастера. (нашла на одном из блогов). А вот про виджеты не подумала. Пойду убирать их. А вот насчёт смайлов, я сама в растерянности, не знаю откуда они взялись. Я устанавливала другие смайлы, потом два месяца была без доступа к интернету, а когда зашла на блог, смотрю, моих смайлов нет, а есть то, что есть. Подскажите как их убрать? Может кто знает в какой они папке?

        • Присоединяюсь к рекомендациям Сергея. А если ничего не поможет, то наверное действительно надо хостинг менять… enlightened

        • Такие смайлы появились в новой версии WordPress. Поставьте плагин Disable Emojis. Он отключает такой вид смайлов. Я у себя их тоже отключил и вывожу красивые колобки.))

          • Спасибо, Сергей, за совет! Я уже лишние виджеты и счётчики убрала, А зачем же в новую версию добавили эти смайлы? Мне они совсем не нравятся!!! У меня тоже были красивые колобки. А плагин не тяжёлый? Блог не нагрузит? Может быть просто где то в коде удалить показ таких смайлов?

        • Да, плагин не тяжелый. Считай что никакой нагрузки от него нету. А лишний код лучше не удалять. Это надо в системные файлы лезть, а это не безопасно. Лучше заблокировать функцию плагином или скриптом.

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

          • Я пока просто удалила эти смайлы в папке smilies. Позже поставлю плагин. А блог у меня тормозит из за частого вмешательства в коды. Нужно нанимать специалиста для анализа. Я поэтому и тему хочу поменять, чтобы убрать всё, что я вставляла в текущей теме. Все эти скрипты поначалу работали исправно, а как обновился движок до предпоследней версии, пошло торможение блога. Видно что то не стыкуется. Вот и думай после этого, что лучше, плагины или скрипты.

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

          Меня тоже раньше пугали этими плагинами.))) Тогда я у себя держал 7 плагинов на блог. Теперь не боюсь их ставить. Сейчас у меня стоит 31 плагин и нормально. В дальнейшем еще буду ставить, так как хочется добавить полезные функции на свой блог. 

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

          • И опять я на 200% согласен с Сергеем! Даже когда-то писал статью по этому поводу… О плагинах и кодах WordPress.

             

          • И я с вами не спорю, согласна на 300%, на своём горьком опыте убедилась, что плагины лучше и надёжнее скриптов. А статью я эту читала, и полностью поддерживаю ваше мнение. Мне в начале все толковали, что лучше установить код, а плагины — вред. Вот я и на устанавливала на свою голову. 

    • Ирина, я не сменил хостинг, просто на этом-же хостинге мы купили VPS и теперь переношу всё туда. Сначала перенёс интернет-магазин, о чём собственно и написана эта статья, а буквально вчера перенёс и вот этот самый блог. С переносом блога всё, конечно-же гораздо проще и быстрее, практически чистое копирование файлов. Даже и статью не напишешь, настолько всё просто…

  4. Когда приходилось для своей организации делать выбор движка интернет-магазина между Опенкарт и Престашоп, остановился на Престашоп. Прочел десятки отзывов, из которых сделал вывод, что связать с 1С: Престу проще, чем Опенкарт. О выборе, в принципе не жалею. Но хотел спросить, если не секрет, каким образом вы реализовывали обмен данными (цены, остатки) между магазином и бухгалтерской программой?

    И еще… мысли не по теме пришли. Все думаю, почему Вы не возьмете себе для блога отдельный домен. Даже интереса ради посмотрел здесь, убедился, что в зонах .net и .kz ваш фамильный домен еще не занят. Можно было бы блог целиком перенести, а со старого адреса сделать 301-й редирект… Понятно, что поддомен (и хостинг) вообще бесплатен, но он, как я понимаю, на рабочем домене, да Вы и сами говорили, что Яндекс его упорно привязывает совсем не туда. Вобщем, это не вопрос, так, мысли вслух… отвечать не обязательно.

    • Константин, спасибо за очень дельный комментарий!

      Но хотел спросить, если не секрет, каким образом вы реализовывали обмен данными (цены, остатки) между магазином и бухгалтерской программой?

      Я-же программист… cheeky И вся компания работает на моей торговой программе… В ней я сделал функцию выгрузки нужных данных в файлы CSV, которые на самом OpenCart загружаются специальным модулем CSV Product Import… И весь наш ассортимент, а это более 5000 позиций в куче категорий (в данное время их 12, но в каждой ещё и подгруппы) загружается на сайт в 5 минут… Со всеми сопутствующими данными…

      Наша бухгалтерия пользуется 1С, но там тоже настроено так, что 1С гребёт все данные из моей программы… Так, что наши бухгалтера избавлены от необходимости заносить накладные, новые товары и т.д…

      Все думаю, почему Вы не возьмете себе для блога отдельный домен.

      Частично я причину объяснял ещё в 2014 году в статье про подведение итогов… Этот блог не планировалось вести вообще, просто тест движка WordPress… Но как-то втянулся…

      Хотя признаюсь, что мысль о собственном домене в последнее время посещает меня всё чаще.

      Практическая сторона реализации, включая 301 редирект и всё прочее сложностей не представляет никаких. Тут главное препятствие — бардак в моей собственной голове… Вроде и хочется и уже рука тянется к покупке домена, но в то-же время думаешь — а зачем?

      Однако судя по тенденции увеличения частоты возникновения желания перенести на собственный домен — скорее всего этим и кончится, в смысле покупкой домена и переносом блога туда… 

  5. Вадим Кочубей

    это хорошо когда твой мозг работает в данном направлении. Так сказать не дурак ))), но …

    а может кто0нить сможет сориентировать по стоимости услуги: есть тема опенкарт на 1.5.6, 1.5.6.1, 1.5.6.2, 1.5.6.3, 1.5.6.4 ….. а хочется чтобы она работала на 2.2 и т.д.  !

    Хотеть то не вредно ))).

    И есть один большой плюс … БАЗА пуста !! Тема только куплена.

    • Тема линейки 1.5 вряд-ли будет работать на движке 2-ки… Разве что к автору шаблона обратиться, может у него уже есть наработки… Думаю, в любом случае проще подобрать новую тему, похожую на старую, а может и превосходящую её, чем переделывать старую для нового движка…

  6. Скажите, а можно таким образом товары и категории перенести?

    • Скорее всего можно. Но я товары переношу из нашей корпоративной базы специальным модулем при помощи csv, сразу несколько тысяч позиций вместе с категориями… Так что мне это было не актуально.

      • Добрый день, Александр. У меня как раз по поводу переноса товаров, категорий и остальных подобных данных возник вопрос. Если структуры таблиц разные, как можно перенести данные из базы 1.5 опенкарт в базу 2.хх??? А может подскажете, где найти подобный модуль?  Пытаюсь с экономить бюджет. И попытаться руками перевести магазин на новую версию движка. А статья очень полезная. спасибо!

        • Макс, здравствуйте. Насчёт товаров и категорий… А магазин версии 1.5… Вы руками заполняете? Какой-то модуль же есть? Или нет? У меня, например, там несколько тысяч позиций товара и куча категорий. Для выгрузки и обновления на сайт из нашей базы использую модуль CSV Product Import

          Это для ветки 2.х ссылка, но там поищите, есть и для 1.5 от того же разработчика… Кстати, если что-то будете у него спрашивать, то можете спокойно по русски — он русский… cheeky У него есть и модули экспорта. То есть можно из старого сделать экспорт, а в новый импорт. Модули эти, кстати, недорогие…

          Там же есть и другие подобные модули, поищите, может и подберёте себе что-то подходящее.

          В остальном-же, для меня главное было сохранить клиентов и их статистику — этот момент я и показал в статье…

          • Ярослав

            Добрый день!

            Не подскажете правильную последовательность переезда?

            есть рабочий магазин, параллельно создал поддомен для переноса на 2.х

            в БД поддомена согласно Вашей статье удается перенести пользователей.

            но помимо этого нужно перенести все остальные данные.

            кроме того, нужно восстановить минимально необходимый функционал.

            т.е. пока все это буду делать, то на рабочем магазине БД уже изрядно дополнится новыми данными…

            их снова ручками придется переносить?

          • Здравствуйте, Ярослав!

            Переезд осуществляется на уже полностью подготовленный к работе магазин. А рабочий, с которого переезжаете, на этот момент ставится в режим обслуживания. Тогда и не придётся вновь появившиеся данные ещё раз переносить.

            До момента переезда поэкспериментируйте с экспортом и импортом баз со старого в новый. Возможно появятся ошибки отсутствующих полей — это можно решить по аналогии с тем, как я показывал в статье. Когда это отработаете, то уже сам реальный переезд займёт не так уж много времени.

            Если же возникают трудности, то можно найти платный модуль, который всё сделает сам. Модули лучше искать вот здесь.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *