Миграция с Magento 1 на Magento 2

Миграция с Magento 1 на Magento 2

Если вы решили перейти с Magento 1 на Magento 2 то скорее всего вам потребуется миграция данных: текущие настройки магазина, товары, категории, атрибуты, клиенты и заказы.

Информация и пошаговое руководство v2.2 доступно на официальном сайте где можно ознакомиться и приступить к миграции. По ходу работы вам придется столкнутся с некоторыми нюансами, которые не описаны в документации. Если у вас установлено много модулей, которые внесли изменения в структуру таблиц, то с вероятностью 99% будут определенные трудности которые придется решать уже в процессе. В основном это исключение/добавление колонок определенных таблиц в файлы конфигурации, а так же фиксация ошибок связанных в основном с таблицами core_url_rewrite (чаще) и customer_entity (реже), возможно есть и другие варианты и появляются они в каком то отдельно взятом случае.

Установка инструмента миграции

composer config repositories.data-migration-tool git https://github.com/magento/data-migration-tool
composer require magento/data-migration-tool:2.2.0

 

После выполнения команды, вы возможно получите такое сообщение

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing magento/data-migration-tool (2.2.0): Downloading (100%)
Package sjparkinson/static-review is abandoned, you should avoid using it. Use phpro/grumphp instead.
Writing lock file
Generating autoload files

 

Решение

  1. Удаляем пакет composer remove sjparkinson/static-review
  2. Устанавливаем composer require phpro/grumphp (На момент установки требуемая версия PHP 7.1 Если вы используете версию 7.0 вам потребуется обновить ее и все модули с ним могут быть конфликты и установка/адаптация этого пакета может занять много времени). Но я не устанавливал этот пакет, по этому вы можете пропустить его установку тоже. Этот пакет еще один инструмент для тех, кто следит за качеством кода. Если вам нужно просто мигрировать данные, вы можете не обращать на него внимание.

Конфигурация миграции

Нам нужно выбрать с какой версии и какой платформы и на какую будем мигрировать, в нашем случае это CE -> CE (Open Source)

cd vendor/magento/data-migration-tool/etc/opensource-to-opensource

Доступные варианты: Commerce to Commerece (Enterprise Edition), Commutity Edition to Enterprise Edition и Commerce to Commerce (Community Edition)

Смотрим версию CMS Magento с которой будем мигрировать данные, номер находится в самом низу страницы (панель администратора), версия CMS с которой я будут мигрировать данные – 1.8.0.0

Далее нам нужно перейти в директорию, в которой будут файлы: config.xml.dist, map.xml.dist

cd vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.8.0.0/

Файл config.xml – это переименованный config.xml.dist, является основным, в котором мы задаем информацию о базе данных источника и приемника, а так же в других  конфигурационных файлах нужно внести определенные настройки (если они вам понадобятся) в основном это относится к названиям таблиц и полей, что сделать со значениями в процессе миграции.

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

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

 

Миграция конфигурации

Тут все достаточно просто, по этому следуем инструкциям и запускаем команду

bin/magento migrate:settings [-r|--reset] {<path to config.xml>}

 

Миграция данных

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

 

Проблемы с таблицами и атрибутами

Миграционный скрипт сравнивает таблицы в источнике и приемнике (Source & Destination) если они отличаются, то вы увидите сообщение об этом. По этому поводу не нужно сильно беспокоится, просто добавьте эти таблицы, колонки и атрибуты в стоп-лист /vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.8.0.0/map.xml

Источник находится в секции source, приемник в секции destination.

Если есть много таблиц, имена которых одинаково начинаются и чтобы не добавлять большое количество практически однотипных правил, можно создать общие правила типа

<?xml version="1.0" encoding="UTF-8"?>
<map xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="../../map.xsd">
    <destination>
        <document_rules>
            <ignore>
                <document>magefan_*</document>
            </ignore>
            <ignore>
                <document>magestore_*</document>
            </ignore>
        </document_rules>
    </destination>
</map>

тогда скрипт пропустит все таблицы, которые начинаются на magefan_ и на magestore_

 

Ошибка в пути класса атрибута

[ERROR]: Class eav/entity_attribute_source_boolean does not exist but mentioned in: eav_attribute.source_model for attribute_id=135

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

 

Ошибка в создании набора атрибутов

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-Migration_Default' for key 'EAV_ATTRIBUTE_SET_ENTITY_TYPE_ID_ATTRIBUTE_SET_NAME'

Довольно распространенная ошибка и решается она путем удаления существующих значений в таблице eav_attribute_set  в Magento 2.

Но, на самом деле удаление записей сделает миграционный скрипт, когда вы его повторно запустите с флагом -r и следующая ошибка будет приблизительно такая Undefined offset 1.

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

 

Ошибка миграции адресов (URL core_url_rewrite)  Duplicate entry “reques path” 

Причина ошибки такая же как и с импортом клиентов (см. ниже) решается путем удаления дубликатов из таблицы.

 

Ошибка миграции/импорта клиентов

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test@test.com-3' for key 'CUSTOMER_ENTITY_EMAIL_WEBSITE_ID'

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

 

Если у вас версия PHP 7.1.0 и выше

Скорее всего вы увидите ошибку

A non well formed numeric value encountered.

Фиксация ошибки файл /vendor/magento/data-migration-tool/src/Migration/ResourceModel/AbstractResource.php строка 224

 

Integrity constraint violation: 1062 Duplicate entry ‘0’ for key ‘PRIMARY’

При попытке импорта групп пользователей, вы получаете ошибку дублирования записи. Помогает увеличение лимита на добавление записей, в файле vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.8.0.0/config.xml увеличиваем bulk_size до 100 в принципе можно и больше, все зависит от того, на сколько мощный у вас компьютер.

Я пробовал установить на 500, но все еще получал ошибку, значение 100 является на мой взгляд самым оптимальным.

 

При открытии товаров в админ панели вместо информации о атрибутах видим сообщение Unable to unserialize value

Связано с тем, что значения уже сериализированы. В сети есть решение, но в моем случае его потребовалось переработать.

В файле vendor/magento/framework/Serialize/Serializer/Json.php ориентировочно 50 строка, есть функция, ниже ее измененный вид

<?php

/**
 * {@inheritDoc}
 * @since 100.2.0
 */
public function unserialize($string)
{
    
    //Checking. If value already serialized
    if (is_array($mixArray = @unserialize($string))){
        $string = json_encode($mixArray);
    }

    $result = json_decode($string, true);

    if (json_last_error() !== JSON_ERROR_NONE) {

        throw new \InvalidArgumentException('Unable to unserialize value.');
    }

    return $result;
}

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

 

Процесс миграции для каждого проекта может быть и простым и сложным, все зависит от состояния данных (база данных SQL), есть ли в них ошибки, а так же какой объем информации нужно перенести. Как и любая задача это решается, это только лишь вопрос времени 🙂

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

 

Миграция с Magento 1 на Magento 2, консультации и другие решения, можно спросить по электро почте в контактах

eCommerce/Magento Developer, PHP architect, based in Ukraine