Міграція OpenCart 3 на 4: що ламається при переході
Зміст
Стаття
Питання «чи переходити на OpenCart 4» звучить дедалі частіше, і відповідь на нього не така очевидна, як здається. Розберемо, що насправді змінилось і чого чекати від переходу.
Головне: 4.0 і 4.1 — це різні платформи
Найпоширеніша помилка — вважати «четвірку» однією версією. Різниця між 4.0 і 4.1 місцями більша, ніж між 2.3 і 3.0.
У OpenCart 4.0 механізму OCMOD немає взагалі — ні відповідного розділу в адмінці, ні таблиці модифікацій у базі. Усі ваші модифікації, які роками патчили ядро, там просто не існують як клас рішень. У 4.1 механізм повернули, але в іншому вигляді: файли розширень лежать окремо, і оновлення списку стирає їх повністю.
Практичний висновок: перш ніж планувати перехід, треба точно знати, на яку саме підверсію ви йдете.
Що зламається у вашому магазині
Модифікації
Кожна модифікація шукає в коді ядра конкретний фрагмент і вставляє свій. У новій версії цей фрагмент виглядає інакше — пошук не знаходить збігу, і зміна тихо не застосовується. Найнеприємніше, що помилки при цьому може не бути: модуль ніби встановлений, а не працює.
Тема
Шаблони переїжджають рідко коли безболісно. Навіть у межах третьої гілки перехід із 3.0.3.7 на 3.0.4.1 ламає теми, бо змінилась версія шаблонізатора: конструкції, що працювали, віддають помилку завантаження шаблону. У четвертій гілці змінилась і структура файлів теми.
Платні модулі
Тут усе залежить від автора. Якщо модуль підтримується — буде версія під нову гілку, зазвичай за окрему плату. Якщо автор зник, а модуль критичний для магазину — це головний аргумент проти переходу.
Власні доробки
Код, написаний під вашу специфіку, доведеться портувати. У четвертій гілці змінились простори імен, структура контролерів і назви методів роботи із замовленнями.
Чи потрібна вам міграція взагалі
Чесна відповідь: часто ні. Аргументи «за» вагомі, якщо ваша версія не працює на підтримуваній PHP, якщо ви впираєтесь в архітектурні обмеження або будуєте щось на тривалу перспективу.
Аргументи «проти» так само реальні: третя гілка стабільна, під неї є величезна екосистема модулів, а незалежні заміри показують, що вона не повільніша за четверту. Якщо магазин працює, оновлений до сучасної PHP і має робочі модулі — переходити заради версії немає сенсу.
Як виглядає безпечний перехід
- Інвентаризація. Точна версія, форк, перелік модифікацій, тема, платні модулі. На цьому етапі часто з'ясовується, що переходити нікуди — половина функціоналу тримається на модулі, якого під нову гілку не існує.
- Стенд. Копія магазину окремо від бойового.
- Перенесення даних. Товари, категорії, замовлення, клієнти й обов'язково SEO-адреси — інакше після переходу ви отримаєте сотні сторінок 404 замість позицій.
- Адаптація коду. Тема, модулі, власні доробки.
- Наскрізний тест. Не «сайт відкрився», а повний сценарій: пошук, картка, кошик, оформлення, оплата, лист, обробка в адмінці.
- Перемикання з планом відкату.
Скільки це триває
Для магазину без екзотики — від тижня. З великою кількістю модифікацій і кастомною темою — місяць і більше, причому основний час іде саме на адаптацію коду, а не на перенесення даних.
Якщо ви зважуєте перехід і хочете спершу зрозуміти масштаб — почніть з аудиту поточного стану: він показує, що саме зламається, до того, як ви щось запустили. Саму роботу закриває послуга міграції між версіями. Часто виявляється, що потрібне не оновлення платформи, а перехід на сучасну PHP — це дешевше й швидше.
