Само дни след излизането на OpenCart 3.0.5.1 и OpenCart 4.1.0.4 в официалното GitHub repository на OpenCart се появи нещо много по-интересно.

В основния master branch версията вече е обозначена като:

define('VERSION', '5.0.0.0 Alpha');

Това е първият достатъчно ясен технически сигнал, че разработката на OpenCart 5 е започнала.

Важно е обаче още в началото да направим едно уточнение.

OpenCart 5 все още не е официална стабилна версия и не трябва да се използва за production магазини.

Става дума за 5.0.0.0 Alpha – ранен етап на разработка, в който архитектурата, API-тата и отделни функционалности могат да бъдат променяни.

Но точно сега е най-интересният момент да погледнем накъде тръгва OpenCart.

OpenCart 5.0.0.0 Alpha вече е в master

В официалното repository:

github.com/opencart/opencart

основният файл:

upload/index.php

вече съдържа:

// Version
define('VERSION', '5.0.0.0 Alpha');

Това не е community fork, не е експериментален repository и не е предложение в GitHub Discussions.

Промяната е в официалния master branch на OpenCart.

Следователно вече можем спокойно да кажем:

OpenCart 5 е в процес на разработка.

Това обаче не означава, че Daniel Kerr е обявил дата за release или че настоящият master представлява окончателната архитектура на OpenCart 5.

Alpha означава точно обратното – предстоят промени.

Защо OpenCart преминава към версия 5?

Това е може би най-интересният въпрос.

OpenCart 4 беше една от най-сериозните архитектурни промени в историята на платформата.

При OpenCart 4 видяхме:

нова extension структура;
премахване на OCMOD в първоначалната концепция;
много по-сериозно използване на Events;
namespaces и autoloading;
Bootstrap 5;
CKEditor 5;
нов installer;
нов upgrade механизъм;
преработен order editor;
product variants;
cron jobs;
GDPR функционалности;
нова структура на extensions.

Проблемът беше, че толкова много промени наведнъж имаха цена.

Огромна част от OpenCart ecosystem-а остана на OpenCart 3.

Много разработчици трябваше практически да пренаписват своите extensions, а съществуващите магазини нямаха достатъчно силна бизнес причина да мигрират.

В GitHub Discussions през последните години това се превърна в постоянна тема.

Някои разработчици настояваха OpenCart 4 първо да бъде стабилизиран.

Други предлагаха следващата голяма стъпка директно да бъде OpenCart 5.

Имаше дори предложения OpenCart 5 да се опита да върне част от простотата и developer-friendly философията, която направи OpenCart 2 и OpenCart 3 толкова популярни.

И изглежда, че точно тази нова глава вече започва.

OpenCart 5 няма да бъде просто OpenCart 4 с нов номер

Това е нещо, което ще следим много внимателно.

Самата промяна на major версията от 4 към 5 подсказва, че не трябва да очакваме обикновен maintenance release.

Но е твърде рано да твърдим кои от експериментите в master ще останат до stable release.

В момента OpenCart продължава да използва собствената си позната архитектура с:

Registry;
Loader;
Actions;
Events;
Controllers;
Models;
Templates;
собствен routing механизъм.

В system/framework.php ясно се вижда lifecycle-ът на приложението.

Създават се и регистрират основните компоненти:

$registry
$config
$log
$event
$loader
$request
$response
$db
$session
$cache
$template
$language
$url
$document

След това заявката преминава през pre-actions, routing, controller events и dispatch.

Това е важно.

Засега OpenCart не изглежда като платформа, която просто е изхвърлила собственото си ядро и го е заменила с готов framework.

А какво стана с идеята за Symfony?

Тук историята става още по-интересна.

През 2025 г. в официалния GitHub на OpenCart се появи дискусия:

“OpenCart + Symfony? – What do you guys think about this?”

Тя предизвика сериозна реакция сред разработчиците.

Причината е проста.

Една от най-големите сили на OpenCart винаги е била сравнително простата му архитектура.

Можеш да отвориш:

catalog/controller/
catalog/model/
catalog/view/

и сравнително бързо да разбереш какво се случва.

Добавянето на голям framework като Symfony би могло да даде на OpenCart:

dependency injection;
стандартизирани компоненти;
по-добър routing;
console tooling;
validation;
queues;
по-модерна архитектура.

Но би имало и цена:

по-висока сложност;
по-стръмна learning curve;
повече dependencies;
по-трудна миграция на старите extensions;
загуба на част от простотата, с която OpenCart е известен.

Community реакцията именно около този баланс беше доста интересна.

Symfony все пак вече присъства

В актуалния composer.json на OpenCart виждаме dependency:

"symfony/yaml": "^7.4.1"

Това обаче не означава, че OpenCart 5 е Symfony приложение.

Symfony е съставен от множество независими компоненти, които могат да се използват отделно.

В случая наличието на symfony/yaml показва използване на конкретен Symfony компонент, а не преминаване към Symfony Framework.

Това разграничение е важно, защото лесно може да се стигне до гръмки, но технически неверни заглавия от типа:

„OpenCart 5 преминава на Symfony“.

Към момента няма основание да твърдим подобно нещо.

По-точно би било:

OpenCart започва да използва отделни модерни PHP компоненти, докато запазва собственото си ядро.

PHP изискванията

Интересен детайл в текущия composer.json е:

"php": ">=8.0.2"

Това е текущото изискване в master.

Тук обаче бих бил предпазлив.

При Alpha версия тези изисквания могат да бъдат променени преди окончателния OpenCart 5 release.

Предвид развитието на PHP ecosystem-а би било логично OpenCart 5 постепенно да се ориентира към по-нови PHP версии.

Но докато това не бъде променено официално в repository-то, няма смисъл да спекулираме.

Какво означава OpenCart 5 за разработчиците на extensions?

Това вероятно ще бъде най-важният въпрос през следващите месеци.

При OpenCart 4 migration cost-ът за extension разработчиците беше значителен.

Промениха се:

namespaces;
директории;
routes;
extension architecture;
events;
installer;
modification механизмът;
голяма част от admin и catalog структурата.

Затова за OpenCart 5 ще следим особено внимателно няколко неща.

1. Extension architecture

Ще бъде ли запазена структурата от OpenCart 4:

extension/vendor/

или ще има нова организация?

2. Events

OpenCart 4 разчита сериозно на event system-а.

Ще бъде ли той разширен така, че extensions да могат да модифицират практически всички важни части от lifecycle-а?

3. OCMOD

Това вероятно ще бъде една от най-дискутираните теми.

OCMOD беше изключително важен за ecosystem-а на OpenCart 2 и OpenCart 3.

Премахването му в OpenCart 4 беше една от най-спорните промени.

Ще видим ли някаква форма на OCMOD или нов modification layer в OpenCart 5?

Това все още предстои да разберем.

4. Backward compatibility

Ще могат ли OpenCart 4 extensions да бъдат адаптирани сравнително лесно?

А още по-интересният въпрос:

ще има ли някакъв compatibility bridge към OpenCart 3 ecosystem-а?

В community discussions вече имаше предложения в тази посока.

Но предложение от community не трябва да се бърка с официално решение.

Един много важен сигнал: OpenCart 3 продължава да живее

Появата на OpenCart 5 не означава автоматичен край на OpenCart 3.

Напротив.

През август 2026 г. беше публикуван:

OpenCart 3.0.5.1

а паралелно с него:

OpenCart 4.1.0.4

Това показва доста интересна стратегия.

В момента реално имаме три поколения:

OpenCart 3 → активно поддържана legacy/stable екосистема

OpenCart 4 → текущото модерно поколение

OpenCart 5 → следващото поколение в Alpha разработка

Това е необичайна, но напълно разбираема ситуация.

OpenCart 3 има огромна инсталирана база и extension ecosystem.

OpenCart 4 носи архитектурните промени.

OpenCart 5 вероятно ще трябва да намери баланса между двете.

Какво според мен трябва да реши OpenCart 5

След повече от десетилетие работа с OpenCart смятам, че следващата версия не се нуждае просто от още функции.

OpenCart винаги е печелил с три неща:

простота, производителност и възможност за модификация.

Един OpenCart магазин можеше да бъде разбран от PHP developer сравнително бързо.

Не беше необходимо да познаваш огромен framework ecosystem, за да промениш checkout-а, продуктовата страница или admin панела.

Точно това според мен OpenCart 5 не трябва да губи.

Но едновременно с това платформата има нужда от модернизация.

Какво бих искал да видя в OpenCart 5

По-добра extension система

Extensions трябва да могат да разширяват core функционалността без директна промяна на файловете.

Events са правилна посока, но трябва да покриват практически всички реални extension use cases.

Стабилно API

В 2026 г. e-commerce платформата вече не е само storefront.

Тя комуникира с:

ERP;
CRM;
куриери;
платежни системи;
marketplaces;
mobile приложения;
fulfillment услуги;
accounting software;
marketing automation;
AI услуги.

OpenCart 5 има нужда от предвидимо и добре документирано API.

По-добър checkout architecture

Checkout-ът е една от най-често модифицираните части на OpenCart.

Той трябва да позволява лесна интеграция на:

payment methods;
shipping methods;
pickup points;
lockers;
dynamic pricing;
VAT validation;
one-page checkout решения.

Без разработчикът да се налага да „воюва“ с core архитектурата.

По-добър dependency management

Composer трябва постепенно да стане истинска част от developer workflow-а на OpenCart.

Не непременно магазинът да се превърне в огромен Composer проект, но dependency management-ът трябва да бъде предвидим.

CLI

Една модерна OpenCart версия би спечелила много от официален CLI.

Например:

php oc cache:clear
php oc extension:install
php oc extension:enable
php oc cron:run
php oc maintenance:on
php oc maintenance:off

За developers и DevOps това би било огромно подобрение.

По-добри migrations

Database upgrade-ите между версиите трябва да бъдат deterministic и лесни за автоматизация.

По-добър logging и debugging

При сложен магазин трябва лесно да може да се проследи:

Request
↓
Route
↓
Controller
↓
Events
↓
Model
↓
Extension
↓
Payment / Shipping API
↓
Response

Това би спестило огромно количество време на extension разработчиците.

Security by default

Бих искал OpenCart 5 да обърне сериозно внимание на:

2FA за администрацията;
по-добра password policy;
CSRF protection;
secure session configuration;
rate limiting;
security headers;
audit log;
login history.

За модерна e-commerce платформа това вече не са „екстри“.

А какво не трябва да прави OpenCart 5?

Според мен най-голямата грешка би била OpenCart да се опита да стане Laravel, Symfony или Magento.

Няма нужда.

Laravel вече е прекрасен Laravel.

Symfony вече е прекрасен Symfony.

Magento вече заема enterprise сегмента със собствената си философия.

OpenCart има друга сила:

Малък и среден онлайн магазин може да бъде разработен, модифициран и поддържан сравнително лесно.

Това е огромно конкурентно предимство.

Модерни PHP практики – да.

Composer – да.

PSR стандарти – да.

По-добър dependency injection – да.

По-добро API – абсолютно.

Но всичко това трябва да бъде направено без OpenCart да изгуби причината, поради която толкова developers го използват.

OpenCart 3 → OpenCart 4 → OpenCart 5

Историята на последните поколения може грубо да бъде описана така:

OpenCart 3

Зряла екосистема, огромен брой extensions и сравнително проста архитектура.

OpenCart 4

Опит за сериозна модернизация на architecture и extension system.

OpenCart 5

Вероятно опит да се намери правилният баланс между модерната архитектура и простотата, която направи OpenCart популярен.

Последното все още е наша интерпретация.

OpenCart 5 е Alpha и тепърва ще видим реалната посока.

Трябва ли да инсталирате OpenCart 5 сега?

Не за production магазин.

Категорично.

5.0.0.0 Alpha означава development версия.

Може да има:

незавършени функционалности;
database промени;
breaking changes;
bugs;
липсваща compatibility;
промени в API;
промени в extension architecture.

За developers обаче ситуацията е различна.

Ако разработвате OpenCart extensions, точно сега е моментът да започнете да следите master branch.

Защото решенията, които се вземат в Alpha периода, могат да определят OpenCart ecosystem-а за следващите години.

Ще следим OpenCart 5 отблизо

OpenCart 5 вече не е само идея от GitHub Discussions.

Официалният master branch вече се идентифицира като:

OpenCart 5.0.0.0 Alpha.

Това е началото, не краят на разработката.

През следващите седмици и месеци ще следя промените в repository-то и ще публикувам анализи на по-важните архитектурни решения.

Особено интересни ще бъдат:

extension system;
Events;
OCMOD/modifications;
API;
checkout;
Composer dependencies;
database layer;
routing;
security;
backward compatibility;
PHP requirements;
upgrade path от OpenCart 3 и OpenCart 4.

OpenCart 4 беше голям експеримент за модернизацията на платформата.

Сега започва следващата глава.

OpenCart 5.

И този път ще следим разработката още от Alpha.