sv2109

пишите в ЛС на демо сайте такой ошибки нету http://demo.sv2109.com/ocstore2302/index.php?route=product/search&search= 3D %26 Touch № %23 %3B + этот модуль не делает никакой переадресации значил скорее всего проблема где-то у вас, возможно в модуле чпу

Этот модуль не задает цены, цены вы можете задавать или в самом товаре в акция или в модуле Разные цены для групп покупателей. Этот модуль поддерживает 2 этих вараинта.

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

поддерживается, наверное подписка слетела

где есть? помню несколько лет тому назад на оф. сайте появился какой-то свой облачный сервис для опенкарта, я еще тогда писал, то этот проект не взлетит и кто им сегодня пользуется? Мое мнение - из опенкарта (того, что есть на сегодня) невозможно сделать хороший (!) конструктор сайтов. Потому что хороший конструктор обязательно должен включать в себя возможность расширение функционала через сторонние дополнения. Потому что каждый магазин индивидуальный, каждому нужны какие-то свои фишки, варианты оплаты, доставки, интеграция со сторонними сервисами, индивидуальный функционал итд. Всего невозможно включить в коробку и нужна обязательно возможность расширения. А расширения в опенкарт сегодня сделаны так (да и весь опенкарт спроектирован так), чтобы в любой момент можно было что-то "подпилить напильником" чтобы оно работало или через прямое изменение кода движка или через модификаторы (сути это не меняет) и это неплохо работает если есть доступ к коду, так как весь движок работает на своем сервере. Но такой подход абсолютно не годится для конструктора, где такой возможности не будет. Тут нужна сложная система расширений которая будет работать без изменения кода самого движка, а этого в движке просто нету. Чтобы понять о чем я можно посмотреть в сторону например шопифай как там все реализовано в плане расширяемости, какое там шикарное API и возможности для разработчиков.

В последнее время работал над новой версией модуля, так как накопилось достаточно много пожеланий от пользователей, многие из них, особенно самые востребованные получилось реализовать, такие как: несколько подарков для одной акции, подарок от суммы заказа итд. Достаточно много времени заняла работа над новой версией, так как работы оказалось намного больше, чем планировалось с самого начала, некоторый функционал пришлось полностью переписать, чтобы получить возможность дописать новый функционал. Но сегодня на конец обновил описание модуля и загрузил новую версию. Новое в версии 4.0 PRO Основные изменения: Подарок от суммы заказа. Подарок добавится в корзину с нулевой ценой только если сумма заказа будет больше указанной в настройках акции суммы. Если сумма заказа меньше в корзине будет отображаться сообщение на какую сумму нужно увеличить заказ для получения подарка. Несколько подарков на выбор. Можно создать акцию с несколькими подарками, покупатель сможет выбрать из списка один. Стикеры для акции. Для товаров у которых есть акция можно отображать отдельный стикер на картинке товара для дополнительного привлечения внимания покупателей к этому товару. Поддержка сео ссылок (seo_url и seo_pro) Улучшена кастомизация. Теперь можно изменить любую переменную или добавить новую перед созданием HTML кода блока акции, стикера, подарков, информационного окна акции. Улучшено добавление товаров в акцию. Теперь можно добавлять товары по цене, атрибуту, категории, производителю. Множество более мелких улучшений.

Готового ответа вам никто не даст, потому что его просто нету. У каждого варианта есть куча своих как преимуществ так и недостатков. + все зависит и от специфики каждого бизнеса. Основной плюс конструкторов - простота, пару кликов и магазин работает. Основной недостаток - что это не ваше и в любой момент может изменится политика площадки и вы потеряете деньги. Основное преимущество своего магазина - что он свой, есть и будет всегда (если не прозевать оплату домена), основной недостаток - что создать свой магазин далеко не так просто так пишут некоторые выше, особенно если нужно что-то сложнее базового функционала, тут нужно или нанимать специалиста, который все сделает или самому вникать в множество вещей, такие как хостинг, домен, FTP, базы данных, какие-то основы веб разработки, маркетинга, seo итд.

Если я вас правильно понял, то есть вот такой модуль: https://opencartforum.com/files/file/7330-otobrazhenie-raznyh-cen-dlja-raznyh-grupp-pokupatelej/

Подсказываю: Если вы задаете подобные вопросы то ищите вы не подсказку, а чтобы кто-то за вас сделал вашу работу да еще и бесплатно. Подсказать это показать ваш код и попросить напр. найти в нем ошибку или подсказать какой-то конкретный момент, если же вы не написали ни одной строчки кода и просите "подсказать" то в таком случае найдите исполнителя, заплатите ему за работу и он все сделает.

Если изображение акции не загружено и у акции есть подарок и у этого подарка есть картка то вместо картинки акции используется картинка подарка. То есть изображение подарка у вас есть в массиве даже не подарка, а самой акции и оно автоматически выводится в блоке акции в категории и товаре. + вы можете вывести его куда угодно вручную через шаблон модуля + как я вам выше написал: в массиве товара есть поле image в котором есть изображение. + для получения этого массива модуль использует стандартную модель $promotion['gift'] = $this->model_catalog_product->getProduct($promotion['gift_id']); поэтому если какого-то поля нету то его можно добавить в model_catalog_product в массив товара и оно появится в шаблоне модуля. Поэтому вы можете вывести в шаблон любое поле подарка.

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

Есть вот такой модуль, там можно делать скидки или наценки на категории или бренды

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

По умолчанию нет, но если это нужно то не сложно изменить модуль чтобы он это делал.

можно, пишите в ЛС

Ответил вам на почту только что

А теперь другому модулю нужно изменить этот запрос, добавив новый джойн и какие-то свои новые условия. И что делать? Изменять все через модификатор? а потом третьему модулю нужно добавить свой новый джойн и свои условия, он пытается сделать этот тоже через модификатор и все, или не работает один модуль и автору нужно вручную ковыряться в коде чтобы исправить конфликт или другой или ошибка 500 и вообще ничего не работает или что еще хуже код может работать но логика работы будет другой, не такой как задумывалось, потому что предвидеть эти моменты как другие модули изменять один и тот же кусок кода невозможно. Конструкторы усложнят код - да, не сильно но усложняют. Но они дают преимущества, которые с лихвой перекрываю это. Одно из самых больших преимуществ - возможность использовать систему Событий для изменения любого! запроса в движке. И при системе событий и 2 и 3 и даже больше модулей могут изменить один запрос и конфликтов при этом будет в десятки раз меньше, так как все будет делаться через понятный api а не через str_replace или preg_replace.

Я вам ответил на ваш вопрос в ЛС, зачем вы спрашиваете тоже самое еще и на форуме? Возможность поиска по точному совпадению значит, что точный поиск имеет более высокий приоритет и товары где есть точный поиск будут отображаться выше, но товары, у которых есть совпадение по части слова тоже будут отображаться, только будут иметь более низкий приоритет. При этом если вы ищите слова с одним символом, например "9" то этот символ может встречаться и в других полях, поэтому сделать какой-то более точный поиск по одному символу практически не возможно. + если у вас включен поиск по целому слову то лучше отключить логику И и заменить ее на ИЛИ.

именно для табов подобный подход будет исключительно полезен, так как тот, кому хоть раз приходилось делать форму в которой были табы с двойной или даже тройной вложенностью, те понимают какой это ад, я когда-то создавал с тройной вложенностью, был верхний горизонтальный, потом вертикальный и потом еще табы для разных языков. Эту форму я писал несколько дней. И если в ней вдруг забыть случайно закрыть какой-то див или удалить случайно что-то, то все, можно и пол дня искать причину.. В конструкторе же можно легко сделать 'tab' => array( 'name' => 'Tab1', 'fields' => (...), ) или 'tab' => array( 'name' => 'Tab1', 'tabs' => (...) ) И все работает, и можно делать хоть 2 вложенности хоть 3 хоть даже больше. вы или плохо читали пост или не поняли его суть. Суть не в том, чтобы каждый использовал свой собственный инструмент, потому что толку с этого не будет никакого. Мало того, это будет настоящий ад потому что придется изучать синтаксис каждого модуля отдельно чтобы понять как с ним работать. + вопросы совместимости, производительности, конфликтов итд. Нужно что бы это было в самом движке, только тогда можно сделать систему Событий, которая позволит со всем этим работать и сможет дать расширяемость движка и уменьшение конфликтов. Опять же если какому-то разработчику будет не удобно работать напр. с конструктором запросов или форм, то он по прежнему сможет писать код по старому и он будет работать.

ну каких 100? я выше дал ссылку на то чего мне не хватает в движке, на сколько это увеличит сложность движка? на 5%? 10%? 20%? На столько же увеличится и цена дополнений и если модуль стоил 10 долларов а будет стоить 11 или 12 то что это изменит для пользователя? При том что и конфликтов будет в разы меньше и других проблем? Опять же не нужно смотреть на ситуации как на 2 безальтернативных варианта: или супер просто и дешево или супер сложно и модули за 100$ как в магенто. Есть масса промежуточных вариантов когда и качество движка можно значительно улучшить и сложность со стоимостью - да, увеличится но очень незначительно (10-20%).

это только на первый взгляд, я после почти 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 бутстрап!