sv2109

можна, пишіть в ЛС

ну тоді модуль ніяк не знає коли саме відбувається ваш запис в базу і вам потрібно оновлювати індекси вручну, якщо товар новий то можна просто добавити нові індекси, а якщо старий то або перезбережіть даний товар через адмінку або видаліть та створіть всі індекси щоб оновити їх. або ще є варіант через крон але він по замовчуванню створює нові індекси, а вам потрібно редагувати існуючі.

якщо ви змінюєте товар через адмінку опенкарта то пошукові індекси повинні оновлюватися автоматично.

модуль показує всі категорії, до яких належить товар, можливо у вас один товар належить до декількох категорій одночасно, напр. головна, підкатегорія другого рівня, третього ітд. тоді модуль буде показувати їх всі. Якоїсь настройки в модулі щоб змінити цю логіку не має.

Все повинно працювати, проблем бути не повинно. Модуль Search Suggestion буде працювати замість пошуку в шаблоні.

Это не работает только на иврите? Ну русском работает или как? Может пишите мне лучше в ЛС чтобы не засорять ветку.

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

во вкладке с полями включите для нужных полей "фильтр по частям речи" и обновите поисковые индексы. Но обычно они не мешают. просто установите логику поиска И и все.

Мій модуль не має функціоналу імпорту чи експорту, якщо вам потрібен такий функціонал то звертайтеся до автора модуля імпорт-експорт щоб від добавив це у свій модуль.

Так, є.

Я можу зробити темізацію модуля під шаблон, тобто виправити грубі помилки в дизайні, конфлікти ітд. В результаті модуль буде працювати на вашому сайті. Але переробити дизайн модуля під ваш намальований дизайн - я таким не займаюся. ПС не побачив що це пост у темі підтримки шаблону був, подумав що це тема підтримки мого модуля.

В последнее время начал немного изучать Python. Это на сегодня очень популярный язык программирования, входит в тройку наиболее популярных языков и по количеству вопросов на разных сайтах типа стековерфолоу и по колличеству репозиториев на гитхабе. Или вот сравнение по гугл трендах https://trends.google.com/trends/explore?date=today 5-y&geo=UA&q=%2Fm%2F05z1_,PHP&hl=ru Или вот информация с сайта TIOBE, они для анализа используют очень много параметров: https://www.tiobe.com/tiobe-index/ Согласно их данным Python сейчас занимает первую позицию в рейтинге, обограм даже C++, C, C# и Java, а PHP занимает 8 позицию (год назад была 9-тая, то есть за год немного даже подрос). За последние 15 лет Python взлетел из 7 позиции на 1-вую, а PHP медленно опустился с 5-той на 8-9. Вся информация по ссылке выше. Для чего используют Python: для учебы. Если раньте школьников и студентов учили на паскале и бейсике которые вообще нигде не используются, то сейчас все дружно перешли на Python и это правильно, язык простой, живой, очень активно развивается и также активно используется. Наверное из-за этого и такой бурный рост языка, так как вчерашние студенты, которые выучили основы языка во время учебы потом начинают его использовать и в работе. для различной автоматизации рабочих процессов. Например спарсить какой-то сайт, обработать пачку ексель документов, дернуть какую-то апишку и тысячи других не очень больших задач. На Python есть тысячи готовых библиотек с помощь которых можно делать что угодно от парсинга всего что только можно спарсить до распознавания лиц, синтеза речи и машинного обучения. для робототехники. Например можно взять какой-нибудь конструктор лего программируемый или плату типа Arduino, подключаем к ней какие-то датчики, моторчики, камеры итд. пишем на Python программу управления и вуаля получаем какую-то машинку на радиоуправлении, или квадрокоптер или сигнализацию для дома или кучу других интересных вещей, как я жалею что в годы моего детства такого не было)) для обработки больших данных, дата саенс, машинного обучения, нейронных сетей итд. И тут Python вообще первый среди всех языков программирования, в нем есть огромное к-во библиотек для всего этого. Эти библиотеки часто используют часть кода на C++ для ресурсоемких задач. Часть аналогов есть на node.js, а на PHP практически ничего нету. для веба и создание API серверов. Есть там фреймворк Django, наверное самый популярный, и на нем много чего делают. Его плюс в том что к нему есть очень много модулей, но сам по себе он гм.. я немного посмотрел его возможности и это мне напомнило PHP фреймворки и микрофреймворки лет так 10-15 назад.. ну то есть все очень бедно по функционалу, если сравнить его с напр. ларавел то это просто небо и земля Короче, мне сложно представить как на Python можно сделать что-то реально большое, скорее какие-то простые, небольшие сайты. Есть фреймворк FastAPI очень популярный в последнее время, на нем делают разные api сервисы. консольные программы игры, точнее больше или какие-то несложные 2D игры или какие-то части для больших игр по например обработке данных десктопные приложения программы для мобильных устройств.. но последние 2 пункта это как по мне скорее исключение, примерно как натягивание совы на глобус так как для это есть специальные инструменты. его также майкрософт уже добавил в свой Excel, его также добавляют в браузер.. короче, скоро наверное вообще не останется ни одной области, где бы не было Python-а)) Плюсы Python простота изучения, отлично подходит в качестве первого языка программирования, мне он очень напоминает как в студенческие годы изучал паскаль)) огромное к-во библиотек на все случаи жизни огромное сообщество очень активно развивается в среде машинного обучения ему практически нету альтернативы много вакансий Минусы Python скорость, он как и все скриптовые языки достаточно медленный, причем тот же PHP последних версий 7,8 значительно обгоняет Python по скорости. Хотя, для тех задач для которых его используют скорости там вполне себе хватает. отсутствие хорошего ООП, тут нету ни нормальных приватных классов и методов, особенно протектед, здесь вообще нету интерфейсов, абстрактные классы реализованы как какой-то костыль через сторонний модуль итд. PHP версии 4! если не ошибаюсь был более функциональным в этом плане. рядом с очень классными библиотеками, написанными хорошими программистами, есть также множество говнокода и очень слабых программистов, так как пишут на Python вообще все кому не лень)) Немного сравнения синтаксиса Python и PHP расширение файлов *.py не нужно открывать никаких тегов тира <?php в PHP, открыли файл и пишете код каждый файл это модуль, можно подгрузить, импортировать не весь файл, а только какую-то его функцию или класс, напр import random или from random import randint нету $ для переменных, ; в конце каждой строки и {} для классов, функций, условий, циклов.. () для условий и циклов также не пишутся, вместо этого есть отступы! не всем это нравится, но зато код стает очень понятным и написать код неправильно его отформатировав просто невозможно. def my_func(x): #comment return x*x это функция, вместо function - def функция может возвращать не одно значение а несколько, например return x,x*2,x*3 и потом делаем x,y,z = my_func(x) нету оператора ++ вместо него просто пишут x +=1 Нету тернарного оператора $x = true ? 1 : 0; вместо этого дают так: x = 1 if True else 0 вроде логически даже более правильно - 1 если истина иначе 0, но не привычно) True и False с большой буквы вместо NULL - None В классах уже писал нету нормальных private, protected, interface, трейтов итд. А то, что есть скорее костыли какие-то. То есть по сути нету нормальной инкапсуляции. Скорее есть набор правил, которым должны следовать программисты, но при желании это все обходится и можно легко получить доступ к приватным переменным. Фанаты языка в один голос повторяют что Python это самый лучший язык, а раз там этого нету, значит там это и не нужно. До недавнего времени они тоже самое говорили и о динамической типизации, а потом (вроде с версии 3.6) в язык завезли типизацию (правда использовать ее не обязательно). Кстати, тоже самое буквально слово в слово можно услышать и от фанатов опенкарта)) опенкарт - самый лучший, а раз там этого нету, значит оно тут и не надо)) Категорически с этим не согласен, так как наличие какого-то функционала не заставляет им пользоваться, но дает выбор, а отсутствие практически лишает вообще какого-либо выбора. Но в тоже время классы в пайтоне имеют одну очень интересную особенность - там есть тьма магических методов (которые начинаются и заканчиваются на __), которые позволяют выполнять с этим классом почти все (или вообще все) возможные операции, разные +, -, сложение, деление, возведение в степень, сравнение, преобразование в число, строку, массив итд. например создаете метод класса __add__() со своей логикой и можно делать object3 = object1+object2 Классы также поддерживают множественное наследование, чего не поддерживает PHP, но PHP поддерживает множественную имплементацию интерфейсов и трейтов, чего нету в пайтоне. В Python метод конструктора и деструктора это __init__ и __del__ соответственно Наоборот: В Python self указывает на объект класса (аналог $this в PHP), а в PHP на сам класс (для обращения к переменным класса и методам класса) В Python есть понятие статического метода класса и метода класса. Первое это просто функция которая не имеет доступа к переменным класса, а второе - имеет, как раз второй вариант работает как статический метод в PHP. Вместо одного массива array или [] как в PHP есть аж 4 вида типа массивов: list или список, обычный одномерные массив [1,2,"foo","bar"] tuple (кортеж) - очень похож на список, только его нельзя изменять. Через него сделаны возвраты нескольких значений из функции. Через него также можно легко поменять значения переменных местами, например x,y=y,x и все) теперь в переменной x значение из y и наоборот. (1,2,"foo","bar") set набор - имеет все элементы уникальные {1,2,"foo","bar"} dictionary - словарь, аналог ассотиативного массива в PHP {1: 2, "foo": "bar"} есть срезы, очень удобная штука, например получить элементы массива с 1 по 3 new_list = old_list[1:3] или перевернет все элементы, кто был первым станет последним итд. seq[::-1] тоже самое со строками, так как строка работает как список, можно делать срезы, использовать циклы перебора символов итд. string = 'строка' string[1:3] # 'тр' или вот такая магия используется очень часто: squares = [i * i for i in range(10)] print(squares) #[0, 1, 4, 9, 16, 25, 36, 49, 64, 81] То есть в одну строку кода можно создать список, набор, словарь И достаточно много подобное магии Если вкратце по синтаксису - все, если где ошибся то поправьте кто более знаком с этим языком или добавьте если есть что, так как я только начинаю его учить, вполне возможно что-то и упустил. Нужно ли учить этот язык? Мне кажется - однозначно - да. он простой, выучить его можно достаточно быстро, тем более что по пайтону есть просто куча бесплатных курсов, видео на ютубе итд. на нем интересно писать код, просто открываешь редактор и пишешь)) он очень популярный и есть много вакансий тут огромное сообщество и тьма библиотек на все случаи жизни, это открывает большие возможности можно работать в области машинного обучение и нейронных сетей, а сейчас это вообще очень популярная область и Python тут похоже вне конкуренции, он завоевал тут почти все)) очень полезно для общего развития очень полезно для резюме, даже если вы программист PHP то иметь в резюме Python как второй язык будет огромным плюсом для вас как для специалиста мне кажется, что очень хорошо подойдет для разработчиков OpenCart, тут нету сложных конструкций как в ларавел, тут простой код и синтаксис, ну почти как в самом опенкарте

я бачив ваше повідомлення, просто зараз не встигаю зробити всю роботу, тому відповім як звільнюся.

Підтримую повністю. + останнім часом було кілька випадків, що користувач купував модуль, а на пошту нічого не прийшло (в спамі також пусто) Раніше такого жодного разу не було. Також дуже незручно, так як на пошті у мене копія всіх покупок з можливістю швидкого пошуку.

1. я не знаю таких модулей фильтров 2. цена в базе одна для всех магазинов

если через группы - то да, можна модуль изменяет цены для групп покупателей для категорий и производителей. модуль может или изменять базовую цену в базе, она одна, для одной группы по умолчанию. или изменять цена "на лету". с фильтрами модуль не совместим в плане цены, так как фильтры берут цену из базы. Ну то есть сам фильтр у вас работать будет но в фильтре по цене цены будут такие как в базе, если они не сильно отличаются то не особо страшно, но если сильно то фильтр по цене будет работать не корректно.

S.O.L.I.D. - это принципы программирования, которые сильно помогают при написании больших приложений, делая их более гибкими, расширяемыми, уменьшая при этом количество ошибок и конфликтов, а также время и деньги на поддержку и сопровождение этого приложения в будущем. Принципы были описал еще в 2000 году Робертом Мартином, вы скорее всего слышали о его книгах, таких как "Чистый код" и "Чистая архитектура". Эти принципы настолько важны, что многие работодатели даже указывают в вакансиях их знание как обязательное условие при устройстве на работу. Попробую описать эти принципы своими словами, максимально просто и понятно. Как можно было догадаться из названия - принципов всего 5 по первым буквам названия: S - Single Responsibility Principle - Принцип единой ответственности O - Open-closed Principle - Принцип открытости/закрытости L - Liskov Substitution Principle - Принцип подстановки Барбары Лисков I - Interface Segregation Principle - Принцип разделения интерфейсов D - Dependency Inversion Principle - Принцип инверсии зависимостей Single Responsibility Principle - Принцип единой ответственности Достаточно простой, понятный но в тоже время очень важный, фундаментальный, принцип. Он говорит о том, что любая программная сущность (класс, метод, функция итд.) должна иметь только одну ответственность, то есть решать только одну задачу. Правда Роберт Мартин изначально вкладывал в этот принцип немного другой смысл. Этот принцип очень часто нарушается в OpenCart, когда в контроллер добавляют все, что только можно - тут и валидация данных и создание ошибок, хлебных крошек, пагинации, картинок и вообще вся логика, так как в модели только получение данных из базы, а все остальное - в контроллере. Из-за этого мы получаем довольно распространенную ошибку MVC шаблона - очень большой контроллер, что является неправильным, контроллер должен быть очень простым и легким, его основная задача - получить запрос от пользователя (Request), передать его кому-то другому на обработку и результа вернуть назад пользователю (Response), но делать вообще всю работу он никак не должен. Open-closed Principle - Принцип открытости/закрытости Еще один очень важные принцип, который также полностью нашурается опенкартом. Он говорит о том, что программные сущности должны быть открыты для расширения и закрыты для изменения (модификации кода) То есть, эти сущности должны иметь возможность расширить их функционал, но никак не через непосредственное изменение их кода, а через другие методы, например через наследование, интерфейсы, внедрение зависимостей, Events или в некоторых системах hooks, модули и плагины для CMS и так далее. В OpenCart же по сути вообще вся система расширений построена на модификаторах (ocmod) или на изменении кода самого движка, то есть на полном нарушении этого принципа. Liskov Substitution Principle - Принцип подстановки Барбары Лисков Он говорит о том, что если какая-то программная сущность работает с объектом класса родителя то она точно также без каких-либо изменений кода должна работать и со всеми потомками этого родителя. То есть, чтобы мы могли вместо класса родителя подставить класс любого его потомка и при этом наша программа работала точно также как и работала до этого. Это также улучшает расширяемость приложения и переплетается со вторым принципом - открытости/закрытости. Как это достигается? Например через контроль всех возвращаемых данных методами классов, если метод родителя возвращает массив определенного формата то и все потомки должны точно также возвращать точно такой же формат массива. Или есть в родителе реализован какой-то метод то этот метод должен быть обязательно реализован и всеми потомками и так далее. Interface Segregation Principle - Принцип разделения интерфейсов Он говорит о том, что если какой-то класс реализовывает интерфейс, то он должен реализовывать абсолютно все его методы, а не только какие-то из них. Например, если нам нужно создать какой-то класс и мы видим, что у нас уже есть интерфейс, который очень похож на тот, который нам нужен, например там есть 10 методов из которых нам нужны 8, то использовать этот интерфейс для этого класса мы не можем, нужно разделить этот интерфейс на несколько более мелких и использовать именно то, что нам нужно (тем более что PHP поддерживает реализацию классом нескольких интерфейсов). Иначе получится ситуация, когда какой-то наш метод работая с этим интерфейсом будет предполагать, что в любом классе, который его реализует обязательно должен быть реализован какой-то метод, но в одних классах он будет реализован, а в других будет например выбрасываться исключение и нам придется в нашей программе в куче мест писать кучу условий и держать в голове всю логику в каком классе какие методы есть а каких нету.. зачем? если сама идея интерфейсов и состоить в том, чтобы оградить нас от всех этих проблем. К сожалению OpenCart, похоже, вообще не использует интерфейсы. Да, на весь движок из сотен файлов нету ни одного интерфейса, не считая сторонних библиотек. Dependency Inversion Principle - Принцип инверсии зависимостей Еще один крайне важный принцип, который отлично реализован в Laravel через сервис контейнеры. Упрощенно он говорит о том, что все зависимости в приложении должны строится на базе интерфейсов, а не через конкретные реализации. Объясню лучше на примере. У нас есть больше приложение, которое сохраняет данные в базе данных. Для этого у нас есть класс DB и методы select() для получения данных из базы и insert() для сохранения. Все отлично работает, но в один момент нам (или заказчику) понадобилось реализовать сохранение данных в, например, файлах. И у нас даже есть готовый класс для этого FileStorage с методами read() и write() соответственно. Но беда в том, что нам теперь нужно переписать гору кода в десятках файлов чтобы заменить не только все названия методов но и их аргументы и возвращаемые значения.. А теперь представьте насколько было бы проще, если бы все было реализовано через интерфейсы и у нас был интерфейс StorageInterface, в котором бы были методы например get() и set() и везде в коде мы использует именно эти методы. Теперь, если нам нужно сохранять данные в базе, мы создаем класс DB который реализовывает наш интерфейс StorageInterface с определенными методами, а для файлов создаем другой класс, который реализовывает тот же самый интерфейс с теми же самыми методами. Если в будущем нам понадобиться работать с LLM и сохранять данные в какой-то векторной базе данных напр. Chroma или Pinecone, без проблем, мы просто реализуем новым классом VectorStorage наш интерфейс и без проблем сможет использовать этот класс в своем приложении и у нас ничего не поломается. Мы сможем даже подключать разные классы работы с данными динамически в зависимости от условий, например в зависимости от переменных окружения, если мы в режиме разработки то использовать один класс данных, если в продакшене то другой, а если в режиме тестирования то какой-нибудь FakeStorage и все будет замечательно работать без каких-либо изменений в коде. Надеюсь, у меня получилось донести что такое принципы S.O.L.I.D., как они работают и почему так важно их использовать в работе. Плохо, что основной разработчик OpenCart, похоже, вообще ничего о них не слышал и поэтому у нас сейчас такой бардак в OpenCart, который похоже никогда не закончится.. И OpenCart это как раз очень наглядный пример как незнание или игнорирования базовых принципов программирования при построении больших систем может со временем парализовать развитие всего проекта.

Появилась поддержка модуля фильтра OCFilter - Модуль фильтра товаров так же напоминаю, что также есть поддержка фильтра Фильтр товаров - FilterVier_SEO По всем вопросам по этим модулям обращайтесь к их разработчикам.

Давно прописав собі фільтр в gmail У мене у спам ніколи не попаде

все есть, напишите в лс подскажу как пользоваться

З чергами не поки не працював, по артізан писав у пості. А фасади, так, дуже крута та зручна штука, як і весь сервіс контейнер. І до речі, дуже просто все зроблено і будь-який клас можна легко перевести в фасад та через статичний метод запускати методи цього класу з любого місця програми. от наприклад весь класс фасаду class Log extends Facade { /** * Get the registered name of the component. * * @return string */ protected static function getFacadeAccessor() { return 'log'; } } і це все! тобто створюємо класс, який наслідуємо від абстрактного класу Facade, у якому є всього один метод який повертає ім'я зареєстрованого компоненту і все.. Взагалі чим більше працюю з ларавел тим більше дивуюся наскільки тут все зручно для роботи та продумано до дрібниць, видно, що це фреймворк створювався програмістами для програмістів і тут автоматизовано все, що тільки можна автоматизувати, практично всі стандартні задачі для веб.

Якшо ви особисто з якимось двіжком не працюєте то це зовсім не означає що він мертвий)) Ось наприклад по друпалу, він зараз десь у 5 разів популярніший за опенкарт! https://trends.google.com.ua/trends/explore?date=today 5-y&q=%2Fg%2F11b5m9hl85,%2Fm%2F01641s&hl=uk Але масово ви про них і не будете чути, бо і друпал і магенто це зовсім інший сегмент сайтів, це корпоративні сайти, на друпалі колись працював сайт білого дому, не знаю як зараз + різні дуже великі сайти та портали, напр. redhat.com, europa.eu ітд. на магенто розробляють магазини типу allo.ua та інші подібні та дуже великі магазини. Розробники там беруть до 200 і навіть більше $ за годину! і за один день заробляють більше, ніж середньостатистичний розробник під опенкарт заробляє за місяць)) Просто це корпоративний сегмент і туди дуже тяжко пробитися якомусь одному фрілансеру, там заказчики це дуже великі контори які навіть дивитися у сторону фрілансерів не будуть, вони краще заплатять декілька десятків а то і сотень тис.$ якісь великій софтверній фірмі, ніж в десятки разів менше, але якомусь фрілансеру..

згоден, саме з цим я не працював, але колись працював з першими версіями Codeigniter -а так він навіть по синтаксису дуууже сильно нагадує опенкарт, мені навіть здається що на я етапі створення опенкарту Даніель просто злизав частину коду з цього фреймворку. Але в плані фреймворка опенкарт не дотягує навіть до перших версій Codeigniter-а.. що вже говорити про інші більш сучасні фреймворки. А так, да, взяти якийсь дуже простий фреймворк, перенести ядро на нього і дописувати тільки сам функціонал самого магазину і взагалі не паритися на рахунок ядра, над яким працюють інші розробники, постійно його вдосконалюючи, випускаючи нові версії, виправлячи баги, добавляючи нові функції ітд. Цим шляхом до речі у свій час пішов Друпал, раніше десь до 6,7 версії у них все працювати на своїх власних велосипедах і вони витрачали реально купу часу щоб все це підтримувати, потім плюнули та перевели весь Друпал на симфоні, скинувши зі своїх плеч величезний об'єм роботи, бо це все вже і так реалізовано та підтримується величезною спільнотою симфоні. І в результаті від цього всі тільки виграли.

а то я мабуть 10 років з якимось іншим опенкартом працюю))) при використанні модифікаторів конфлікти будуть завжди! Причому їх буде дуже багато. Бо модифікатор змінює код самого опенкарту. І питання тут не у тому правильно написаний той модифікатор чи ні, конфлікти будуть у будь-якому випадку бо модулі пишуть різні розробники і один взагалі нічого не знає і не може знати що у голові у іншого... Я пишу свій модуль і прив'язуюся в модифікаторі до якогось конкретного куска коду в стандартному опенкарті, добавляю свій код після нього. І все працює, бо у стандартному опенкарті цей код є. А до мене якийсь інший розробник змінив цей кусок коду на інший чи дописав щось своє, бо для його модуля саме це треба було зробити, і що буде? мій модуль вже не знайде потрібний код та не добавить свій код після нього. І що це як не конфлікт? маємо помилку і або один модуль не буде працювати або два. Або і ще гірше - два модуля будуть працювати і жодних помилок не буде, але логіка роботи зміниться і наприклад десь у корзині якась ціна буде нараховуватися неправильно.. і подібні помилки взагалі дуже тяжко виправляти бо все вроді працює і в логах чисто.. Так ще не розповідайте басні, що ніяких конфліктів не буде, якщо у магазині встановлено декілька десятків модулів (практично у кожному магазині так) і кожен із модулів вносить десятки змін у код самого опенкарту + ще встановлена якась тема тиду джорнал яка сама по собі переписує половину опенкарту і в результаті отримуємо опенкарт, встановити якийсь новий модуль на який ще те задоволення.. сидиш і тупо виправляєш конфлікти бо все не так як треба.

Дуже спірно, як на мене. Data Mapping це по суті ORM, ORM це дуже крута штука, згідний, але для опенкарту це буде занадто складно, особливо зараз. Зараз люди звичайний конструктор запитів не можуть прийняти бо для них це заскладно, то як вони повинні прийняти цілу ORM яка буде значно складнішою? + вона також буде працювати повільніше, бо це ще один великий шар абстракції. До ORM потрібно дорости і опенкарт як на мене ще взагалі не доріс що цього. ORM дуже зручна якщо мова йде про не складні запити, але коли з'являються зв'язки, особливо зв'язки many to many де в ідеалі потрібно створювати ще одну проміжну pivot таблицю і працювати через неї, щоб побудувати цей зв'язок то це значно ускладнює все. Взяти наприклад таблицю товару в опенкарті (яка пов'язана ще мабуть із десятком інших таблиць, а ті ще з іншими) і як це все перенести на ORM? Перенести то можна, але що в результаті вийде і як воно потім буде працювати по швидкості? Та і рішення яке вийде буде ніяк не простим. Ну і + ORM це штука, яка добре працює у великих системах, де крім самої ORM є ще дуже багато всього (різні міграції, фабрики, кешування, події, інтеграція із шаблонізатором ітд.) і все працює як одне ціле, наприклад в Laravel я через ORM отримую колекцію (по замовчуванню отримується тільки поля основної таблиці, без зв'язків, щоб зробити запит швидким), передаю її у шаблонизатор, там в циклі прохожуся по якомусь зв'язку цієї таблиці і все працює (знову ж таки, потрібно добре розуміти як це все працює під капотом, щоб розуміти скільки запитів до бази при цьому буде створено). А не так що взяти одну ORM і всунути її у опенкарт бо це круто і правильно. У той час як конструктор запитів до бази даних, так, він не такий функціональний, але він і набагато простіший, легший в освоєнні та швидший. І для опенкарт на зараз як на мене підійшов би просто ідеально, як заміна сьогоднішнього підходу коли всі SQL запити тупо пишуть вручну.. Зараз це була б золота середина між голими запитами як зараз та ORM, яка накладає свої обмеження та складнощі. Пізніше коли б всі звикли до конструктора то можна було би подумати щоб впроваджувати щось більш складне та функціональне, але на зараз як на мене це зайве. Якось так, моя досить аргументована позиція))