lexxkrt

{{ [1, 2, 3, 4]|first }} {# outputs 1 #}

сформировать нужные данные в зависимости от входных данных в контроллере. в твиге (во вьюхе) вообще логики по минимуму должно быть. пишите сразу правильно

а category_id вообще существует? ну и правильнее данные в контроллере сперва подготовить

не загружайте меню в контроллере header, ну или пустую строку передавайте, когда меню не нужно

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

во всех orm и кверибилдерах есть возможность выполнять чистый sql запрос, ради бога если запрос сложный то делай его, а для простых запросов билдер упрощает работу. а инсерты в кверибилдерах например DB::table('products')->insert($data); а чистый sql как будет выглядеть при этом? причем $data это может быть не одна запись, а массив записей

первое возможно, а второе с чего бы, тот же кверибилдер собирает ту же sql строку, плюс сделает за вас грязную работу по экранированию да префиксы подставит

ну так данные ты передаешь $query->where('num','=', 334) $query->where('num,'=', '0000334') т.е. изначально ты подставляешь переменную нужного типа. из 0000334 после экранирования 334 не получится, как и наоборот

а какая разница как экранирует для mysql where id = 1 и where id = '1' это одно и тоже

нет я сосем про другое. там просто папка расширения вынесена, но контроллеры модели а также папки расширений лежат раньше самих файлов. я же предлагаю порядок extensions/author/module_name/{controller,model,language,view}. т.е. модуль целиком в единой папке, а не по разным

не проще. потому что в вашем случае, например, вы строку не экранируете

в принципе можно ничего и не добавлять. поработать с кодом, вычистить, избавиться от портянок, избавиться от дублирования кода, избавиться например от необходимости каждый раз создавать хлебные крошки, пусть генерируются от маршрута. избавиться от обработки переменных (объектов) в контроллерах. либо получать готовые из моделей, либо обрабатывать в твиге. переработать формирование урлов, опять же портянки. систему модулей/расширение я бы предложил сделать в одну папку, один модуль одна папка, т.е. тут же контроллер, рядом файл модели рядом языковые файлы и вьюхи. dbbuilder или голый sql это по сути одно и тоже вопрос предпочтений,

даже не знаю что добавить. вроде все сказано. может быть orm и composer (PSR).

А нужен не низкий порог входа, а эффективность. Если ты разработчик то разберешься с любым кодом, а если нет, то нечего тебе делать в коде, нанимай разработчиков. Судя по вопросам в разделах общие вопросы, тут и низкий порог входа не помогает.

и это "плохо" надо на PHP8 тащить. может разобраться с тем что есть сперва следует, а потом версию php поднимать.

Крик души. if (!empty($product_info)) { $data['model'] = $product_info['model']; } else { $data['model'] = ''; } Серьезно? зато PHP8 почему не $data['model'] = $product_info['model'] ?? ''; или вообще в твиге {{ product.model|default('') }} -- в контроллере $data['product'] = $product_info??null; Да и вообще в контроллере данные обрабатываться не должны. должно быть что то вроде $data['product'] = $this->model_catalog_product->getProduct($product_id); весь product_info должен в модели быть спрятан Реально код на PHP 5.3 зато выпендрился минимальную версию 8 поставил. неймспейсы по факту зачем тут. Ни автолоадера ни PSR, или это просто увидел новое слово надо внедрить. портянки-портянки-портянки. Честно не понимаю что происходит, меньше кода меньше повода для ошибок, легче обслуживать, это же очевидно. В твиге есть include. нет же видать даниэлю нравится портянки с километр. почему бы в админке, например в товарах, табы не подключать инклудами. Зато ненужную фигню добавляет, типа рекуринга, кому такую фигню нужно пусть бы модулями доставляли. нужен просто работающий нормальный движок с минимальным набором функционала, остальное расширяться по необходимости, при этом не распыляться на сомнительный функционал. Глядя на код и последний бэта релиз этого чуда в 2017 году, даже несмотря на современные копания в коде, возникает смутное чувство что версия 3 для опенкарта была последней.

не совсем понятно как вы собираетесь делить группы по которым надо показывать подгруппы, а по которым товары. Например корневая группа будет подгруппы показывать или все товары?

не установлено расширение

Делайте, кто вам запретит

реально

а забыл они еще иконки добавили в bs5, конечно как можно забыть об таком существенно значимом изменении

Это и есть опции, а то что вы хотите сделать называется изобрести велосипед. Много работы, а как вы хотели. Думали разместили сайт и все плюй в потолок. Для этого и нанимают контентщиков.

ты вообще понял о чем я писал. и да помимо jquery изменились названия марджинов паддингов. по моему мнению не в лучшую сторону. раньше было нативно понятно. все остальное не существенно

Вот только что специально скачал оксторе 3.0.3.7. в упор не наблюдаю где в конфиге seo_type. Суть не меняет. Проблема с модификаторами раз раньше работали, либо они не установлены, либо кэш непочищен.

как бы наводит на мысль что с модификаторами что то не то. ибо в файле system/config/catalog.php нет переменной seo_type