OpenCart перетворюється на декілька проєктів? Фактично, така ситуація з'явилась ще тоді, коли випустили публічний реліз 4.0.x.x з великою кількістю проблем. Засновник Деніел Керр у вересні 2026 року опублікував на GitHub дорожню карту версії 5.x.x.x, у якій описав майбутній OpenCart як систему із заздалегідь згенерованих статичних файлів HTML, CSS і JS, що розміщуються на Cloudflare, AWS або GitHub. Паралельно він запропонував запустити окремий репозиторій з робочою назвою opencart.js і передати master-гілку спільноті. Для тисяч магазинів, які працюють на OpenCart, і для розробників модулів ці рішення визначатимуть технічну стратегію на найближчі роки. Ми оцінили нову концепцію з погляду реальної експлуатації інтернет-магазинів.
Як OpenCart дійшов до цього
Нинішня ситуація стала наслідком кількох років нестабільного розвитку. Реліз 4.0.0.0 приніс PHP 8.1, Bootstrap 5, нову систему розширень на подіях і варіанти товарів. У тому ж релізі з ядра прибрали OCMOD і всі сторонні розширення. Для розробників модулів це означало переписування коду під нову архітектуру. Згодом у версії 4.1.0.0 OCMOD повернули, і частину роботи довелося переглядати вдруге.
Колаборатор проєкту stalker780 описав цей період так: щонайменше шість років власники магазинів обирали між застарілою третьою версією з Bootstrap 3 зразка 2013 року і нестабільною четвертою, яка ламала сумісність майже з кожним мінорним оновленням. Частина продавців за цей час перейшла на WooCommerce, Shopify і маркетплейси.
Стабілізацію забезпечила спільнота. 11 серпня 2026 року одночасно вийшли версії 3.0.5.1 і 4.1.0.4 з офіційною підтримкою PHP 8.5. Попередній стабільний реліз гілки 4.1 з'явився 24 березня 2025 року, тобто майже за сімнадцять місяців до цього. Команда OpenCartBot додала до релізу 4.1.0.4 десять власних виправлень. Основну роботу з підтримки обох гілок останніми роками виконує колаборатор mhcwebdesign разом з іншими учасниками спільноти.
Концепція OpenCart 5
Керр пояснює зміну курсу змінами на ринку. На його думку, власники бізнесу більше не хочуть утримувати власний скрипт, який потребує постійних перевірок безпеки й оновлень. Звідси ідея магазину, який складається з готових файлів і майже не має серверної частини. Дорожня карта 5.x.x.x містить такі зміни:
- вітрина працює на файлах HTML, CSS, JS, JSON, YAML і CSV;
- описи товарів пишуться в Markdown;
- PHP відповідає тільки за генерацію статичних сторінок, прийом форм і відправку листів;
- адмінка також складається зі статичних сторінок;
- розширення активуються за меншу кількість кроків;
- вбудовані конектори вивантажують готовий магазин на хостинг, Cloudflare чи AWS.
Керр також заявив, що одна cPanel-панель зможе керувати мільйонами таких магазинів. Технічного опису, прототипу чи термінів для цієї заяви поки немає.
Сильні сторони статичної архітектури
Модель попередньо згенерованих сторінок перевірена роками на генераторах Hugo, Eleventy та Astro. Для інтернет-магазину вона дає кілька вимірюваних переваг. Статичні сторінки віддаються з CDN за десятки мілісекунд, що позитивно впливає на Core Web Vitals і ранжування в Google. Вартість розміщення мінімальна: Cloudflare Pages і GitHub Pages обслуговують статичні сайти безкоштовно в межах лімітів. Поверхня атаки різко скорочується, оскільки на вітрині немає бази даних і PHP-коду, через які найчастіше зламують магазини.
Аргумент безпеки має реальне підґрунтя. Масові атаки на CMS із плагінами відбуваються регулярно, і власники малих магазинів рідко встигають вчасно встановлювати патчі. Статична вітрина знімає значну частину цього ризику.
Обмеження статичного підходу для інтернет-торгівлі
Магазин складається з процесів, які змінюються постійно. Ціни для груп покупців, акції з датами, залишки на складі, купони, податки, мультивалютність, кошик і оформлення замовлення вимагають актуальних даних у момент дії покупця. Опублікована дорожня карта не описує, де зберігатимуться замовлення, облікові записи клієнтів і залишки товарів.
Регенерація сторінок створює окреме навантаження. Каталог на 10 000 товарів трьома мовами містить 30 000 карток, до яких додаються категорії, сторінки виробників і фільтри. Зміна ціни одного товару потребує перебудови його картки, усіх списків з цим товаром і пошукового індексу. Магазин, що синхронізує залишки з обліковою системою кілька разів на годину, фактично перебуватиме в безперервному циклі генерації.
Для українського ринку список серверних задач ще довший. Вибір відділення Нової пошти й розрахунок доставки працюють через API в реальному часі. LiqPay, monobank і WayForPay надсилають callback-запити, підпис яких перевіряється на сервері. Фіскалізація через ПРРО на зразок Checkbox, вивантаження товарів на Prom і Rozetka, обмін з BAS чи 1С теж вимагають серверного коду. Уся ця логіка потребуватиме оновлень і захисту, тому проблема безпеки переноситься в іншу частину системи.
Розробник з Бразилії в обговоренні дорожньої карти звернув увагу ще на один аспект. OpenCart колись поширився завдяки простому встановленню на будь-якому недорогому хостингу, і перехід на Cloudflare чи AWS може виявитися складним для малого бізнесу. Налаштування збірки, деплою і серверних функцій потребує кваліфікації, якої немає в більшості власників невеликих магазинів.
PHP залишається основою масового e-commerce
Керр обґрунтовує новий напрям тим, що веброзробка відходить від PHP. Статистика підтверджує цю тезу лише для певного сегмента. За даними W3Techs на серпень 2026 року, PHP використовують 70,3% сайтів з відомою серверною мовою, серверний JavaScript має 7,2%. Серед тисячі найбільших сайтів співвідношення становить 59,2% для PHP і 29,2% для JavaScript.
Зсув до JavaScript відбувається серед високонавантажених проєктів з власними командами розробників. Аудиторія OpenCart належить до малого й середнього бізнесу, де PHP домінує і найближчими роками залишатиметься стандартом. Тому PHP-версія OpenCart зберігає свою ринкову нішу незалежно від долі opencart.js.
Два напрями розвитку OpenCart
Після дискусії на GitHub контури нової структури проєкту стали зрозумілими. Колаборатори запропонували розділити репозиторій на гілки за номером версії:
- 3.0.x.x отримує виправлення і підтримку нових версій PHP;
- 4.1.x.x отримує виправлення і підтримку нових версій PHP;
- 4.2.x.x стає гілкою розробки наступної PHP-версії і відкривається в репозиторії за замовчуванням.
mhcwebdesign підтримав цю схему і підтвердив, що master-гілка вже суттєво відійшла від PHP у бік статичних сторінок і JS/JSON, тому її логічно виділити в окремий проєкт opencart.js. Учасники обговорення запропонували закласти в 4.2 нову структуру бази даних і доопрацювати ядро, систему подій та OCMod. Керр погодився передати master-гілку спільноті й працювати над новим проєктом в окремій гілці.
У результаті OpenCart 4.2 розвиватиметься як еволюційне продовження четвертої версії зі збереженням сумісності. Opencart.js стає експериментальним продуктом з іншою архітектурою, який Керр планує запропонувати користувачам після завершення. Організаційні питання залишаються відкритими. Учасники попросили надати активним колабораторам права мейнтейнерів, налаштувати GitHub Projects для планування і створити чат для координації. Від відповіді на ці запити залежить швидкість виходу наступних релізів.
Екосистема модулів у новій конфігурації
Для ринку розширень два напрями означають різні сценарії. Модулі для гілки 4.1 без суттєвих змін повинні працювати і в 4.2, якщо спільнота дотримається курсу на зворотну сумісність, про який колаборатори говорять як про пріоритет. Нова структура бази даних у 4.2 може вимагати адаптації модулів, що працюють напряму з таблицями товарів і замовлень.
Для opencart.js сумісності з наявними модулями не буде. Контролери, моделі, Twig-шаблони, події й модифікації OCMOD не мають відповідників у статичній архітектурі. Будь-який платіжний, доставочний чи обмінний модуль доведеться проєктувати заново, щойно з'явиться специфікація API розширень. Досвід переходу з третьої на четверту версію показує, що на відновлення екосистеми після такої зміни йдуть роки.
Стратегія для магазинів на найближчі роки
Магазинам на третій версії варто оновитися до 3.0.5.1. Ця збірка працює з PHP 8.5, тому майбутнє відключення старих версій PHP на хостингу не створить термінових проблем. Нові проєкти доцільно запускати на 4.1.0.4, оскільки саме ця гілка стане основою для 4.2 і отримуватиме виправлення від спільноти.
Відкладати оновлення в очікуванні OpenCart 5 не варто. Статична версія існує у вигляді плану з кількох абзаців, без архітектурного документа, дат і шляху міграції. Швидкість, яку обіцяє статика, магазин на 4.1 може отримати вже зараз через повносторінкове кешування, Redis і кешування каталогу на рівні Cloudflare.
Розробникам модулів варто будувати розширення на системі подій і OCMOD гілки 4.1 та відстежувати зміни структури бази даних у 4.2. Власникам бізнесу, які планують роботу на OpenCart на кілька років уперед, корисно стежити за репозиторієм і брати участь у тестуванні релізів-кандидатів. PHP-версія тепер розвиватиметься силами спільноти, і кожен звіт про помилку чи пул-реквест прямо впливає на терміни виходу 4.2.
