sv2109

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 акция отображаться, поэтому модуль и не поддерживает ситуацию, когда один товар добавлен в несколько акций. если нужно чтобы отображалась какая конкретная акция для какого-то товара то удалите этот товар с других акций.

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

так и есть, теперь в шаблоне напр. категории {% for product in products %} <div class="product-layout product-list col-12">{{ product }}</div> {% endfor %} а в контроллере $data['products'][] = $this->load->controller('product/thumb', $product_data); контроллер thumb namespace Opencart\Catalog\Controller\Product; class Thumb extends \Opencart\System\Engine\Controller { public function index(array $data): string { $this->load->language('product/thumb'); $data['review_status'] = $this->config->get('config_review_status'); return $this->load->view('product/thumb', $data); } } правда опять же зачем так делать? Подключить шаблон из шаблона можно через инструкцию твига include {% include 'thumb.twig' with product %} или если уже создавать отдельный контроллер для thumb то почему бы тогда в него не винести и всю остальную логику, которая дублируется в каждом контроллер для картинок товара, цены, налогов и других полей.

Обновил модуль, добавил 4 версию, ниже перечень основных отличий 4 версии модуля от предыдущих версий. Модуль был очень сильно изменен и почти полностью переписан. На странице модуля есть скриншоты а также ссылка на демо сайт. Что нового в версии 4 PRO? Эта версия добавляет множество новых функций в модуль, основные из них: Сжатие CSS и JavaScript файлов (поддержка встроенных стилей и скриптов) для ускоренной загрузки страниц Ленивая загрузка CSS и JavaSсript файлов, загрузку некоторых некритичных скриптов и стилей можно отложить, это ускорит загрузку страницу Перевод изображений в более легкий формат webp для ускоренной загрузки страниц Ленивая загрузка изображений, изображения, которые не видны пользователю будут загружаться по мере прокрутки страницы, это экономит трафик и ускоряет загрузку страниц Кеширование запросов базы данных Автоматическая генерация кеша Улучшенная работа с AJAX, теперь через AJAX можно даже подгружать цены товаров или наличие на складе, а также любую другую информацию. Обработка Last-Modified заголовков Удобный блок отображения и отладки информации Улучшен пользовательский интерфейс, добавлены кнопки быстрого доступа к модулю, включения/отключения и очистки кеша с любого места в панели управления. Десятки других улучшений

модуль поддерживает php 7.2 в архиве модуля скопируйте файлы с папки php_versions/7.1

graphql очень интересная штука, не нужно создавать кучу роутов для каждого API запроса, просто есть одна точка входа и можно самостоятельно написав нужный запрос получить результат со всеми необходимыми полями их связями итд. + он просто идеально подходит для react / vue + на его основе можно строить любое приложение напр. какие-то мобильные приложения, которые будут брать данные с движка и как-то их обрабатывать и выводить итд. Но увы.. думаю в ближайшем будущем с той скоростью с которой разрабатывается опенкарт это нереально.. я с vue не работал, только с реактом. Но сдается мне что Даниел не совсем понимает во что он ввязался)) он наверное думает что перевести все на реакт это как перейти на новую версию бутстрапа, за 2 вечера и сделал)) Но реально там совершенно другой подход к разработке нужен. Ведь современные js фреймворки используют все самые новые фичи языка ES6-7-8 синтаксис, а он далеко не всеми браузерами поддерживается, поэтому нужен бабель, но бабель пихать в продакшен это очень плохая идея, нужен вебпак со своим окружением, чтобы все запаковать, для вебпака нужен npm, а для него нужно уже устанавливать node.js ))

Читаю на ночь глядя репозиторий движка и что я вижу.. ветка https://github.com/opencart/opencart/issues/9634 и 2 ответа от Даниела 1. https://github.com/opencart/opencart/issues/9634#issuecomment-830994245 2. https://github.com/opencart/opencart/issues/9634#issuecomment-833821476