Тема, модуль доставки, фід, правка в кошику — і через кілька років ніхто не скаже, що в рушії штатне. Чотири місця, де каталог на OpenCart упирається в ядро, перевірка кожного за кілька хвилин і чесна межа: що лікується без зміни платформи, а що ні.
Магазин на OpenCart рідко ламається одним днем. Спершу купується тема, потім модуль доставки, потім фід для маркетплейсу, далі хтось дописує правку в кошик. Через кілька років власник уже не може сказати, що в його рушії штатне, а що прикручене зверху. При оновленні OpenCart чи модуля такі доробки доводиться перевіряти й часто переписувати.
Ця стаття для тих, хто вже на OpenCart або вибирає його. Тут немає огляду того, що видно ззовні у 43 магазинах на трьох платформах, — він є окремо в статті «Prom, Хорошоп чи OpenCart». Тут — перевірка самого ядра: чотири місця, де каталог найчастіше впирається в архітектуру, і як кожне з них перевірити у своєму магазині без розробника.
Почнемо з того, що часто купують даремно. Гуртові ціни в простому вигляді в ядрі вже є: на вкладці Discount у картці товару задається ціна для групи клієнтів, мінімальна кількість, пріоритет і дати дії. У базі це окрема таблиця oc_product_discount з полями групи, кількості, пріоритету, ціни й дат. Якщо ваш гурт — це «дилер від 10 штук платить менше», модуль для цього не потрібен.
Так само штатно в картці є поля Model і SKU, кількість на складі та перемикач Subtract Stock, тобто чи списувати залишок при замовленні. У значень опцій товару є власна кількість і своя надбавка до ціни.
Тепер про те, де штатного вже не вистачає.
Далі — чотири ознаки, кожну можна перевірити у своїй адмінці.
Візьміть позицію, яка лежить у двох місцях, і спробуйте з адмінки сказати, скільки її на кожному. Поле Quantity у картці одне, і це не обмеження інтерфейсу: і в гілці 3.0, і в 4.1 кількість лежить одним цілим числом у таблиці товару, поруч з однією ціною. Таблиці складів у штатній схемі немає.
Якщо розбивка живе в таблиці менеджера, ви вже на межі: усе, що читає штатне поле кількості, бачить одне число. Чому одна ціна ламається з другим складом і різною закупкою, ми розібрали в статті «Кілька складів — одна ціна товару не працює».
Штатна знижка знає дві речі: групу клієнта й кількість. Межа проходить там, де ціна починає залежати від чогось третього. Найчастіше це склад, з якого відвантажують, або персональна домовленість з конкретним покупцем на конкретну позицію. Ще одна типова вимога — мінімальна сума замовлення для гурту.
Попросіть менеджера записати, як він насправді рахує ціну для найскладнішого постійного клієнта. Вмістилося в рядок «група плюс кількість» — ядро впорається. З'явилося «але з цього складу» чи «а цьому клієнту на цей бренд окремо» — таку логіку доводиться дописувати патчами в розрахунок ціни, і вони можуть конфліктувати з іншими модулями, що правлять те саме місце.
Учора в картці було 12, сьогодні 9. Хто й коли змінив число? У штатній схемі 3.0 є таблиці історії для замовлень, клієнтів, купонів, сертифікатів і повернень. Таблиці рухів залишку немає. Кількість у картці просто перезаписується — замовленням, імпортом чи рукою менеджера, і попереднє значення ніде не лишається.
Якщо без логів сервера й розпитувань відповіді не знайти, складського обліку у вас немає — є лише поточна цифра.
Для гілки 3.0 є ще одна перевірка. Відкрийте базу в phpMyAdmin і подивіться колонку Engine у списку таблиць. Штатний інсталятор 3.0.5.1 створює 132 таблиці зі 134 на MyISAM, а цей рушій, за документацією MySQL, транзакцій не підтримує. Тобто кілька пов'язаних записів одного замовлення не можна ні виконати разом, ні разом відкотити, якщо посередині щось пішло не так. У гілці 4.1 інсталятор уже ставить InnoDB. Переведення таблиць на InnoDB зазвичай можна зробити без зміни платформи, але його варто перевірити на копії бази; журналу рухів воно не додасть.
Для магазинів запчастин, інструменту й будь-якого гурту це найдорожча ознака, бо покупець приходить з артикулом у буфері обміну.
Ось як шукає штатний OpenCart (ми читали код моделі каталогу в гілках 3.0 і 4.1). Назва розбивається на слова, і кожне слово шукається входженням. Модель і в 3.0, і в 4.1 порівнюється з запитом цілком, без урахування регістру. SKU, EAN та інші коди в 3.0 теж порівнюються цілком, а в 4.1 — за початком рядка.
Тож якщо артикула AB-1234 немає в назві товару, запити AB 1234, ab1234 чи 1234 у пошуку вітрини здебільшого повернуть порожню сторінку — спробуйте на своєму каталозі, це дві хвилини. Покупець не знає, як саме у вас записаний код, і йде туди, де знайшло.
Типові діри, які ми знаходили у вимірі ринку, лежать не в ядрі. Повільна відповідь сервера, застаріла версія PHP, карта сайту з дублями, відсутній canonical — усе це виправляється на тому самому рушії, докладно — у вимірі технічної бази ринку.
Гуртові рівні в межах «група плюс кількість» закриваються вкладкою Discount. Таблиці переводяться на InnoDB. Новий шаблон міняє вигляд вітрини. Якщо ваші болі тут, міняти платформу не треба, і ми скажемо це першим листом. Пошук по артикулу — пограничний випадок: його переробляють і на OpenCart, але це вже доробка ядра пошуку, а не налаштування.
Межа — не одна ознака, а їхній збіг. Коли від складу залежить ціна, а замовлення доводиться розбивати між складами й вести журнал рухів залишку, це вже модель даних, і функцією її не додаси. Її доводиться вбудовувати в ядро чужого рушія, і при оновленні OpenCart чи модуля її доводиться перевіряти й часто переписувати.
Під цей випадок ми робимо Stable Shop — власний рушій LIONEX на Laravel. У ядрі там один артикул лежить на кількох складах, і в кожного своя ціна, залишок і термін доставки, а замовлення розбивається автоматично. Групи клієнтів мають кілька рівнів гурту, персональні ціни на позицію й мінімальні суми замовлення. Кожен рух залишку записується окремим рядком з автором і часом, операції йдуть у транзакціях з блокуванням рядка. Пошук працює на Meilisearch з лематизацією української, і артикул знаходиться з пробілами, дефісами й крапками. Код і дані лишаються на вашому сервері.
Чого там ще немає, кажемо так само прямо: імпорту з OpenCart поки немає, резервування товару з таймером у кошику немає, Rozetka Delivery і Meest поки заглушки, а магазин розширень для сторонніх розробників ще в розробці. Продукт зараз на етапі підготовки запуску. Детальніше — на картці Stable Shop і сторінці магазину на власній платформі.
Коли задача типова: під неї вже є готовий модуль, і його дешевше поставити, ніж написати. Якщо склад один, а ціни вміщаються в групу й кількість, опенкарт робить свою роботу, і переписування рушія коштувало б більше, ніж дасть. Ми переважно працюємо з OpenCart і розробку на ньому продовжуємо робити.
Якщо після чотирьох перевірок у вас дві-три ознаки збіглися, надішліть адресу магазину й опис того, як рахуються ціни й залишки. Безкоштовний розбір каталогу покаже, що можна вилікувати на поточному рушії, а що впирається в ядро. Відповідаємо протягом двох годин, а сума, якщо дійде до роботи, фіксується в договорі після розбору.
Ваша думка допомагає нам створювати кращий контент
Допоможіть іншим дізнатись про це — поділіться статтею в соціальних мережах
Дякуємо, що допомагаєте нам рости
Пише про те, що робить руками: інтернет-магазини на OpenCart, застосунки на Next.js, інтеграції та швидкість сайтів. У статтях — заміри й перевірки, які читач може повторити на своєму проєкті, а не загальні поради. Комерційна розробка з 2015 року.
Відповіді на популярні питання по темі
Для простого гурту — ні. На вкладці Discount у картці товару задається ціна для групи клієнтів, мінімальна кількість, пріоритет і дати дії. Модуль або доробка знадобляться, коли ціна залежить ще від складу, персональної домовленості з клієнтом чи мінімальної суми замовлення.
Штатно ні: і в гілці 3.0, і в 4.1 кількість товару зберігається одним числом у таблиці товару, а таблиці складів у стандартній схемі немає. Усе, що читає штатне поле кількості, бачить одне число на товар, тож розбивку по складах доводиться вести окремо від ядра.
Візьміть артикул із дефісом і введіть у пошук вітрини варіанти з пробілом, без дефіса й лише цифрову частину. Штатний пошук OpenCart порівнює модель із запитом цілком, а назву шукає за словами, тому якщо артикула немає в назві, частина варіантів не знайдеться.
Це рушій таблиць MySQL, який за документацією MySQL не підтримує транзакцій. Штатний інсталятор OpenCart 3.0.5.1 створює на ньому 132 таблиці зі 134, а гілка 4.1 уже ставить InnoDB. Перевірити можна в phpMyAdmin, колонка Engine. Переведення на InnoDB зазвичай можна зробити без зміни платформи, перевіривши спершу на копії бази, але журналу рухів залишку воно не додає.
Коли задача типова й під неї вже є готовий модуль, який дешевше поставити, ніж написати. Якщо склад один, а ціни вміщаються в правило «група клієнта плюс кількість», переписування рушія коштує більше, ніж дасть.
Прямого імпорту з OpenCart у Stable Shop зараз немає, це відкрита межа поточної версії. Що й як переноситься у вашому випадку, видно після безкоштовного розбору каталогу.
Підпишіться на нашу розсилку та отримуйте корисні поради, інсайти та новини про веб-розробку, маркетинг та бізнес.
E-commerce та БізнесКомісія від 4,2 %, 10 грн за кожне оформлене замовлення на сайті з власним доменом, а сайти на піддоменах, зареєстровані від 30.05.2025, не індексуються. Що ви платите Prom, що можна забрати з собою, що Prom і далі робить краще і як перевірити рішення за власним вивантаженням замовлень. Умови — за даними на 14.10.2026.
E-commerce та БізнесКартка тарифу Хорошопу показує нижню межу. Рахунок рухають лічильник товарів із модифікаціями, ліміт замовлень і функції, які відкриваються лише у старших тарифах. Розбір за сторінкою цін на 14.10.2026 і чесна відповідь, коли оренда вигідніша, а коли власний рушій.
E-commerce та БізнесДовідка за текстом постанови КМУ № 738 у редакції від 01.09.2026: хто може отримати грант на власну справу, суми для старту й масштабування, надбавки 5–50 %, таблиця лімітів витрат за п. 7 з розрахунком для грантів 300 000 і 1 000 000 грн, бізнес-план і підстави для відмови.
