sv2109

это только на первый взгляд, я после почти 10 лет работы с движком это вижу совсем иначе Низкий порог это также: - плохой код - отсутствие нормальной системы расширений - куча конфликтов между модулями - неопытные разработчики - модули низкого качества и как результат 1. невозможность использовать движок для более серьезных проектов, особенно там где разработку нужно вести не в одиночку а в команде 2. недовольство движком разработчиков и студий, которые со временем разочаровываются в проекте и уходят, а разработчики это то, на чем держиться любой движок, так как они создают модули, темы, магазины на заказ, привлекают новых клиентов итд. 3. недовольство движком и самих пользователей из-за частых проблем из-за конфликтов, а также из-за того, что сложно найти нормального разработчика, так как многие опытные ушли, а осталось много неопытных новичков и как следствие -> падение популярности самого движка. И второй вариант: Более высокий порог -> более опытные разработчики, которым интересно работать с движком -> более качественный код -> больше качественных модулей -> намного меньше конфликтов и других проблем -> довольные пользователи -> рост популярности движка. Опять же, между низким порогом и высоким есть еще средний вариант, когда можно максимально сохранить простоту но при этом и добавить много интересного функционала.

Оформил в отдельный пост в блоге зачем это все нужно и что это даст

Предлагаю немного пофантазировать. Чего больше всего не хватает OpenCart, чтобы быть ну если не идеальным, то по крайней мере движком с которым было бы приятно работать всем нам? По моему мнению не так и много, как может показаться на первый взгляд. 1. Конструктор форм. Что есть сейчас? Каждый разработчик для каждого своего дополнения вручную пишет горы HTML кода со всеми классами, проверками валидности, javascript и так далее. А когда OpenCart меняет например версию Bootstrap с 4 на 5 то с этим меняются десятки css классов и весь этот HTML код нужно вручную переписывать для каждого модуля.. А теперь только представьте! Был бы в OpenCart какой-то простой конструктор форм, чтобы формы не создавать, как мартышки, вручную и потом изменять по пол дня каждую форму после очередного обновления. А чтобы форму создавать как-то так: $form = new Form(array( 'id' => 'my-module-form' 'action' => '...', 'field' => array( 'type' => 'input', 'name' => 'title', 'label' => 'Title' 'rules' => array ( 'required' => true, 'min_lenght' => 3 ) ) )); и потом делаем например $form->render() и передаем результат в шаблонизатор. Все. Что это даст? Модулю будет вообще все равно на какой версии bootstrap или twig работает админка движка, это все нужно знать только конструктору форм и со сменой версии он сам построит нужную форму со всем новым синтаксисом. То есть, мы можем еще под 1.5 создать в контроллере модуля свою форму и эта форма будет работать даже на OpenCart 4 и 5 версии бутстрапа! А если в каком-то OpenCart 5 появится React то нам и тогда будет все равно, потому что конструктор форм поменяется все за наc и модуль и дальше будет работать! В конструктор форм можно добавить событие, напр. form/render/before и перед рендерингом всех! форм любой модуль может получить объект этой формы и изменить его как угодно - например добавить какие-то свои поля или целый новый таб с кучей своих полей итд. То есть любой модуль может легко изменить любую форму в админке и каталоге как самого движка так и любого другого модуля. При чем сделает это не через модификаторы которые особенно при изменении шаблонов добавляют кучу конфликтов, а правильным способом через события и добавление новых полей в объект формы. В форму также можно добавить такие приятные плюшки как: автоматическую валидацию полей по заданным правилам, с выводом нужных сообщений об ошибках, причем валидация будет работать даже без перезагрузки страницы через аякс. Плюс будет куча встроенных правил для валидации напр. емейлов, ссылок, длины и так далее, просто добавил в правило поля напр. 'required' => true и все, форма сама создаст поле, проверку, вывод ошибки если условие не соблюдено и так далее. 2. Конструктор SQL запросов. Я не говорю о какой сложной ORM, а об очень простом конструкторе запросов. Что есть сейчас? Каждый разработчик пишет кучу SQL запросов вручную. При этом эти запросы изменить из своего модуля можно разве что через модификаторы, порождая тем самым кучу конфликтов. А теперь представьте если бы в движке был конструктор запросов и запросы создавались как-то так: $query = $this->db->select('*')->from('product')->where(...)->limit(10); $results = $query->execute(); Что это даст? И читать и писать такой код легче и понятнее Можно в сам конструктор добавить и добавление префикса таблицы и автоматическую обработку данных перед выполнением, не нужно для каждого поля вручную делать $this->db->escape, а это в свою очередь и упростит написание запросов и сделает их надежнее и безопаснее. Самое главное! Можно создать событие напр. db/execute/before и со своего модуля получить доступ ко всем! SQL запросам на сайте с возможностью изменить каждый, например добавить свой новый JOIN или условие, сортировку итд. Имея конструктор в будущем намного проще перейти на новую базу данных, при этом не нужно будет изменять код всех модулей, а только код самого конструктора, чтобы он по готовым правилам создал другой запрос по правилам другой базы данных. Для каких-то сложных запросов или ленивых разработчиков всегда останется возможно написать какой-то запрос вручную по-старому. 3. Нормальная система расширений. Для этого: Полностью выбросить на свалку истории vqmod и ocmod, как причину огромного к-ва конфликтов Сделать нормальную систему Событий. Писал об этом выше как можно расширить движок при наличии конструктора форм и SQL запросов. Это далеко не все, что нужно для полноценной системы Событий, просто показывает на примере как можно достаточно просто создать огромные возможности для правильного! изменения движка через События. Добавить другие инструменты такие как валидаторы, хелперы для например создания хлебных крошек, пагинации и десятков других вещей, для которых в движке нужно дублировать кучу кода в каждом модуле. Конечно, добавить еще можно много всего, но если хотя бы реализовать те 3 пункта что я описал выше мы уже бы получили качественно! другой движок. Потому что извините, но в 21 году писать вручную SQL запросы, HTML формы и дублировать тысячи строк кода это.. мне даже слова сложно подобрать, чтобы это описать и никого не обидеть.. одним словом - сюр какой-то. И еще один важный вопрос - усложнят ли все эти нововведения движок? На первый взгляд может показаться что - "да", так как нужно будет выучить новые инструменты. Но с другой стороны сколько времени это займет? Несколько дней? А сколько времени потом будет сэкономлено? В разы, десятки раз больше? Во сколько раз уменьшиться количество конфликтов в движке? В разы, десятки раз? На сколько нам всем будет приятнее работать с таким движком, в котором ты можешь писать код модуля и он после этого будет работать, даже если в движке кроме него установлено еще пару десятков других модулей? А со сменой версии движка не нужно будет вручную переписывать гору HTML кода под новую модную версию бутстрапа? Во сколько раз такой движок, в котором модули работают без конфликтов, а хороших и функциональных модулей будет больше, будет более привлекательным для пользователей? Неужели все эти преимущества не стоят этих изменений?

все так, вот только для того, чтобы была возможность расширять движок прежде всего нужна нормальная система расширений, а вместо нее вот уже почти 4 версия движка на подходе, а разработчикам все еще приходится писать sql запросы вручную в одну строку, писать для каждого модуля горы html кода вручную и изменять его постоянно опять вручную после каждого обновления версии бутстрапа или твига, а также изменять движок через ocmod, который буквально изменяет код самого движка создавая кучу конфликтов. О каком расширении в таком случае может идти речь? Я пришел в опенкарт уже почти 9 лет назад, тогда актуальной была еще версия вроде 1.5.3.1, хотя многие еще использовали 1.4.9 В ней например для загрузки языковых переменных нужно было сначала подключить файл языка, а потом в контроллере вручную прописать каждую!!! переменную языка типа $this->data['text_enabled'] = $this->language->get('text_enabled'); а везде можно было встретить примерно такой код: if (!$this->error) { return true; } else { return false; } Но я тогда подумал - да, в движке есть недостатки, но есть и преимущества! Он очень простой, быстрый, требует очень малых ресурсов, на нем можно создать даже сайт с сотнями тысяч товаров, который будет нормально работать даже на дешевом шаред хостинге! А недостатки они со временем пофиксятся, исправятся и мы получим почти идеальный движок - быстрый, простой и функциональный. Но.. время шло, а движок практически не изменялся функционально, не считая улучшений в дизайне. Поэтому мой вам совет - не ждите что что-то кардинально изменится в будущем (особенно в ближайшем) и или воспринимайте движок таким, каким он есть или ищите другие более правильные движки с более лучшим и правильным кодом. Иначе, будете (как раньше я сам) еще 10 лет жаловаться что все не так

да, тоже видел) а чтобы разработчики не скучали папку дополнений перенесли в другое место и бутстрап 5 добавили вместо 4, визуально мало что поменялось, но если посмотреть по коду любого модуля.. вместо class="pull-right" class="float-end" вместо <ul class="breadcrumb"> <ol class="breadcrumb"> вместо <li><a href="{{ breadcrumb.href }}">{{ breadcrumb.text }}</a></li> <li class="breadcrumb-item"><a href="{{ breadcrumb.href }}">{{ breadcrumb.text }}</a></li> вместо <div class="panel panel-default"> <div class="card"> ну и еще несколько десятков! подобных мелочей и нужно будет каждый модуль теперь пол дня переделывать чтобы получить по сути тот же самый вид, только уже под 5 бутстрап!

1. Потому что он никак не считает свое творение ненормальным решением, как раз таки наоборот он считает что создал чуть ли не идеальное решение, аналогов которому не существует во всем мире. 2. Потому что он вбил себе в голову что весь код должен быть максимально простым и чем проще, тем лучше, потому что тогда движок будет очень популярным. И думать так очень удобно для самого Даниела, потому что написал ядро 15 лет назад и все, обновляй версии бутстрапа много лет. А на все вопросы "а почему в движке нету ххххх" есть один универсальный ответ - "потому это нарушает философию движка". Поэтому все предложения добавить сюда что-то новое рубятся под корень ибо не положено, это будет слишком сложно..

по идее не только модификаторами но даже событиями из других модулей, так как эти события привязаны с оригинальному роуту, а не к новому. Если это так, то ломается вообще все. подобные вещи по любому должны быть в самом движке, должна быть одна точка входа, иначе завтра логика загрузки может измениться и этот код работать не будет. Как измениться? Например если в 4 версии уберут модификаторы и оставят недоделанные события то каждому разработчику придется или изобретать какой-то свой велосипед для изменения файлов движка или загружать в движок какой-то модуль аналог модификаторов (да и не факт что он будет один а не несколько) и этот файл шаблона потом может лежать по разным путям. И что тогда? Должна быть одна точка входа, тогда ее и изменить просто и работать с ней более удобно. Вот почему бы загрузку шаблона не закинуть вот сюда? catalog/controller/event/theme.php если в базе есть код шаблона (измененный через редактор) то загрузить его, если нету то загрузить из файла. Мне кажется, что это иллюзорная простота. Когда сначала - да, открыл модификатор, добавил пару правил и все работает. Быстро и просто. Но потом это вылазит в огромное к-во конфликтов которые исправлять приходится разработчикам, разбираясь в этом все кошмаре. И приходится иногда весь день тратить на всевозможные конфликты. И если на сайте установлено пару модулей то еще нормально, а если там десятки модулей + куча кастомного кода + еще тема в довесок на подобие какой-то джорнал и все, атас, попробуй найди причину почему что-то не работает? С другой стороны события они более сложны сначала (хотя если все нормально сделано, а не такая уродская пародия как сейчас, и есть нормальная документация то все изучается за буквально пару часов), но потом к-во конфликтов уменьшается в десятки раз. Ты просто пишеш код и он работает! представляете, так оказывается можно! И не зря все другие движки переходят на события или хуки или их аналоги, потому что они намного более предсказуемы и дают возможность различным разработчикам писать дополнения которые не конфликтуют между собой. Похоже что уже даже Даниел это понял, так как не зря же он начал разрабатывать события если и модификаторами можно было все что нужно сделать? И не зря же в 4 версии модификаторы хотят удалить.

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

как вариант, но все равно это очень кривое решение 1. как я могу быть уверен что если $code не пустой, что другой модуль до меня загрузил именно нужный мне файл? а не какой-то свой или что-то совсем другое? Ведь загрузить можно что угодно. Или что если я что-то изменю то кто-то другой после меня не загрузит свой вариант шаблона и не затрет все мои изменения? 2. каждому модулю вручную загружать код шаблона из файлов не имея вообще никакого апи и инструментов для этого? Я поэтому и не увидел этот вариант что не мог подумать что подобная дичь доступна в движке, ведь это 100% работа движка работать с файлами шаблонов, а не модулей. А после загрузки что? каждому модулю так же вручную изменять его с помощью чего? str_replace и preg_replace?... Да и чем этот вариант принципиально отличается от варианта с модификаторами? Там в шаблоне искали какой-то код и заменяли его на свой, создавая при этом кучу конфликтов и тут точно тоже самое, только если в модификаторах все делал сам движок по инструкциям в xml файле + было кеширование и возможность нормальной отладки, то тут каждый модуль будет это делать по своему через свой код и свои велосипеды (при чем код этот вообще может быть закрыт) в котором потом фиг разберешься, без кеша и возможности отладки..

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

как? можно вызывать какой-то свой код До выполнения любого контроллера и После него. И первый и второй практически бесполезны. Но изменить сам контроллер никак нельзя, какую-то логику внутри.

Ну я это видел. Но в первом случае в before $code - вообще пустой. Если кто-то не положит туда что-то из своего обработчика. Это не оригинальный шаблон, который можно изменить. А во втором случае смотрю по коду в 3037 в библиотеке шаблонизатора public function render($filename, $code = '') { if (!$code) { $file = DIR_TEMPLATE . $filename . '.twig'; if (is_file($file)) { $code = file_get_contents($file); } ... } // initialize Twig environment $config = array(...); try { $loader = new \Twig\Loader\ArrayLoader(array($filename . '.twig' => $code)); $twig = new \Twig\Environment($loader, $config); return $twig->render($filename . '.twig', $this->data); } ... } то есть этот $code, который сформирован обраточиком (или обработчиками) модулей просто заменяет оригинальный код шаблона. То есть изменить оригинальный код шаблона все равно никак нельзя.

Да, это кстати бы решило немало проблем, так как можно бы было через событие после выполнения модели добавить в результат какие-то свои данные и они автоматически бы попали в шаблон минуя контроллер. Иначе теперь нужно как-то их прописать в контроллере, а такой возможности тупо нету и зачем тогда их изменять если потом с помощью событий сделать с ними вообще ничего нельзя? И это все при том, что события существуют начиная со второй версии движка (если не ошибаюсь) а уже на подходе 4-я..

Там есть 2 события, а не одно, одно вызывается до рендеринга шаблона (before), а второе - после (after) В первом можно изменить массив данных, которые передаются в сам шаблон, изменить те, которые есть или добавить свои. НО никак нельзя изменить сам шаблон. Во втором случае можно изменить output, только это не шаблон, а уже отрендеренный готовый html. Да, его теоретически можно изменить в этом событии, но это еще хуже, чем через ocmod: 1. потому что изменяем мы не шаблон, а готовый html. Если в шаблоне напр. есть переменная {{ language }} и она одна, то в готовом html будет "Язык" или "Мова" или "Language" для каждого языка свое значение. Если в шаблоне напр. {{ price }} то в html будет своя цена для каждого товара итд. Если в шаблоне вывод 1 строки в цикле, то в готовом варианте будет 20 строк результата и что изменять каждую? 2. в окмод есть кеш и все изменения сохраняются в кеше и потом берутся из кеша, тут же все делается на лету при каждой загрузке страницы 3. в окмод через кеш можно видеть сам файл, какие там изменения. Тут же мы изменили html код на лету, отдали результат и его движок сразу отдал в браузер, поэтому отладить будет намного сложнее. А когда будет какой-то конфликт, когда один и тот же html код изменит несколько модулей то искать причину будет ой как весело.. А кто-то еще обязательно додумается свой обработчик события закодировать кубом и будет ад в энной степени))) Насчет "поставить свой" это совсем не вариант, так как если есть несколько модулей которым нужно изменить один html код и кто-то самый умный заменит его на свой то все другие модули просто перестанут работать. И это по-вашему "не самый плохой вариант"? Да это настоящая жесть еще большая чем сам ocmod. Если в таком виде все будет добавлено в релиз четверки то сразу после этого кто-то сделает модификаторы модулем и всем придется доставлять его как раньше доставляли vqmod и будет хорошо если это будет один модуль а если их вдруг появится несколько или каждый разработчик напишет свой велосипед? То это вообще будет настоящий ад. И плюс это только работа с шаблонами, а как изменить контроллер через события? Никак. Как изменить напр. sql запрос в модели если это нужно? Опять никак. Можно или подменить весь код на свой или изменить входные параметры и результат, но сами запросы - никак. Можно изменить данные при загрузке языков, но только от этого никакого, ведь потом их не вставишь ни в контроллер ни в шаблон через события. И вот в пользу этого всего сейчас удаляют модификаторы..

catalog/view/javascript/bootstrap/js/bootstrap.js "Bootstrap v5.0.0"

Очень навряд ли, если уже работают над 4 версией то какой смысл выпускать новую версию для тройки? Тем более что если ее выпустить то потом все правки придется заново переносить на 4 версию.

Сегодня немного поизучал 4 версию, и добавил новый пост в блогах о тех изменениях, которые нашел в 4 версии

На данный момент продолжается работа над 4 версией движка. На сегодня для тестирования доступна версия 4.0.0.0_b. Сроков выхода новой версии пока нету, но уже можно посмотреть какие там запланированы изменения. Из основного - минимальная версия PHP - 8 "Warning: You need to use PHP8 or above for OpenCart to work!" - убрали модификаторы (ocmod) Вот только не понятно как можно убирать модификаторы, если с помощью событий еще можно сделать очень мало? И как при этом писать дополнения? Или будет как в версии 1.5 движка - отдельно OpenCart и отдельно все скачивали vQmod? - добавлена схема для базы данных system/helper/db_schema.php Опять таки, зачем она нужна если запросы к базе все еще пишутся в одну строчку? - для товара добавлены варианты Можно указать главный товар и его варианты, например один товар с различными вариантами цветов, теперь это будут разные товары для каждого цвета со своими наборами опций, ценой, остатками и другими полями - папка дополнений переехала из /catalog и /admin в /extension/opencart/catalog /extension/opencart/admin Свои же дополнения будут храниться в /extension/username/catalog /extension/username/admin спасибо @chukcha за уточнение Суть это не меняет, но структуру файлов всех дополнений придется переделывать. - неймспейсы теперь везде было class ModelCatalogProduct extends Model { стало namespace Opencart\Catalog\Model\Catalog; class Product extends \Opencart\System\Engine\Model { - и строгая типизация было public function getProducts($data) { стало public function getProducts(array $data = []): array { Шаблон - Bootstrap обновлен до 5 версии при этом поддержку font-awesome убрали, видимо иконки уже есть в Bootstrap - jQuery 3.6 вместо 2.1 - возможно, в движок будет добавлен React или Vue Разговоры об этом идут, я уже писал об этом на форуме, также писал о том, насколько маловероятно что это будет реализовано - появилась новый шаблон product/thumb.twig для блока товара в категории, поиске, производителе итд. Более подробно тут - появился новый шаблон common/pagination.twig для пагинации Админка - появился новый тип дополнений - Startup предположительно для добавления своих скриптов, которые будут выполняться при загрузке магазина - появились задания крона wget "http://localhost/opencart/4.0b/admin/index.php?route=common/cron" --read-timeout=5400 - добавлено GDPR Approvals для пользователей - возле логотипа пользователя появился колокольчик для уведомлений о новостях, новых версиях и обновлениях от OpenCart но по идее это могут использовать и сами модули для создания своих уведомлений. Общие впечатления К сожалению, вот уже несколько новых мажорных версий, начиная со второй, вместо того, чтобы решать глобальные проблемы движка, такие как отсутствие нормальной системы расширений, отсутствие нормальных инструментов работы с базой данных, валидаторов, дублирование кода, устаревшее ядро движка, которое уже больше 10 лет как почти не изменяется, а также многие другие, OpenCart идет по пути "сделаем все красиво" и в каждой новой версии тратится куча времени для обновления дизайна, сначала добавили Bootstrap, потом в каждой новой версии его обновляют, добавили twig, обновили jQuery.. Каких-то кардинальных изменений я совсем не заметил, на мажорную версию это никак не тянет, максимум на 3.1. Хотя, работа над 4 версией еще не закончена, есть слабая надежда что еще что-то добавят. Если что-то пропустил - дополняйте или поправляйте в комментариях.

Теоретически - да, можно. Так и спросите - в каких таблицах базы данных и полях хранятся данные дополнительных вкладок.

Автор в ЛС отвечает в рабочее время, с 9 до 18, вчера последнее сообщение от вас было вчера в 9:55PM Инструкция находится в архиве модуля, там описал процесс установки модуля.

ответил в ЛС

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

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

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

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