Pirks

select * from (select pr.sku, pr.product_id, pr.mpn, des.name, pr.quantity, pr.price from ocst_product pr left join ocst_product_to_category cat on cat.product_id = pr.product_id left join ocst_category_path cpa on cpa.category_id = cat.category_id left join ocst_product_description des on des.product_id = pr.product_id where cpa.path_id = [кода категории] order by des.name, pr.price DESC) dub group by dub.name HAVING count(*) > 1 Пока, вот такое решение.

ocst_product_description.name тут появилось еще одно условие - не учитывать цену равной 0

Добрый день! Интересно, задача - выключить дубли в главной категории одним запросом, решаема ? Но есть еще одно условие, оставить с минимальной ценой. )

Да, плюс этого решения не трогать модель и контроллер. Но надо все время держать в голове, что описание товара не простое ...

В нашей ситуации добавление товаров идет напрямую в базы данных Open Cart через другое приложение. А его интерфейс делается под нужды заказчика. Т.е свой АОП вне Open Cart

Мне нравится такое решение, но надо обдумать вопрос о проблемах с кастомными полями в будущем. Спасибо!

description_mini - делаем дополнительное поле в таблице product_description? Да, это второй вариант с выделением в основном описании. Погуглю про noindex Спасибо!

Задача такая: Хранить краткое и полное описание товара. в category.tpl выводить только краткое, в product.tpl полное описание товара или краткое и полное. Как это лучше реализовать? Варианты 1. Основное описание хранить как и положено в description, краткое в каком либо другом поле product_description. Вопрос - В каком именно, без ущерба для SEO, других модулей и т.д.? 2. Все сохранять в description но кратким описанием будет например первый абзац, как вариант можно вообще вводный текст выделять тегом. Что скажут по этому поводу гуру? )

А вот тут поподробнее, зачем? Вроде вы уже и так по ssh на сервере, уже пробились через все блокпосты. ) И как правильно говорит коллега выше, там, на гитхабе вот такое видно

Попробуйте вот это - https://github.com/iSenseLabs/oc_cli обращение к контроллеру OC из консоли . Скажу честно, попробовал мельком, не стал глубже копать - импорт - экспорт делаю своими скриптами через PHP PDO.

Я не претендую на истину, но здесь вроде бизнес - продажа услуг и разработок для open source проекта. И я гость в этой системе, но иногда заказчик. ) Если 10 сообщений по теме - 1 о жизни - это юмор. Если обратное соотношение это флуд. Я просто высказал свое мнение. Вам решать каким должен быть этот бизнес. )

Это канал, а я о чате.

Добрый день! Есть предложение переименовать чат в телеграме OpenCartForum Чат - в OpenCartForum - Флуд. ) ну или второй вариант OpenCartForum - Лимонов о жизни ... А для общения по теме чисто о Open Cart сделать отдельный чат. Я в теме Open Cart совсем недавно - около года и не могу указывать гуру OC как общаться, в созданной ими экосистеме - Open Cart. ) Но надо все-таки называть вещи своими именами. ) Это будет честно и по отношению к коллегам и что особенно важно, по отношению к заказчикам, которые я уверен иногда читают этот чат https://t.me/opencartforumchatru

Да, эта ссылка не меняется.

Нет конечно! ) Скачайте по ссылкам из предыдущего сообщения и убедитесь сами.

Да, можно в личку.

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

У нас пошел уже холивар, ну да ладно, надеюсь будет полезным для обоих. ) "Все реализовано" - это наверное n-модулей, где каждый разработчик модуля только за себя? ))

Ок. Подарю вам часть ТЗ на модуль или расширение. ) 1. Список поставщиков с параметрами. 2. Прайсы поставщиков - или склады, с остатками и ценами. 3. Динамическое обновление прайсов из различных источников 4. Контролер подключения к товару разных цен. 5. Учет реализации товаров разных поставщиков. Вот как-то так. )

Мне нужны технические решения - идеи, а реализовать уже их как получится, или самому или на аутсорс. Пока я вижу, что работа с поставщиками или складской учет вообще не реализованы в OC , пытаюсь выяснить, насколько затратно это сделать. Вообще, это же делается, оглядываюсь по сторонам. )

Не буду вас переубеждать, но зайдите на https://developers.google.com и сами убедитесь что такое сейчас Google API. ) Уже несколько лет как можно забирать таблицу Spread Sheet в любом формате по ссылке. Речь идет не о файлах, а о документах в данном случае - таблицах. И многие b2b сервисы работающие с прайсами могут забирать их по ссылке из Google Doc. Но меньше слов, больше дела. ) Например вот Таблица в Google Sheet А вот ее можно скачать в формате xlsx А здесь уже в формате csv Ну а что сейчас можно делать скриптами, а это JavaScript с документами на Google и с возможностью подключения через API на PHP, Go, Python ... извините но VBA отдыхает. )

1. Понадобится что-то типа кроссов в автомобильных запасных частях - замены оригиналов, соответствие кодов . Где будете вести эту базу данных и как? 2. Для формирования наценок и скидок тоже понадобится таблица база данных. 3. И этот пункт предусматривает ведение таблицы оригиналов. Готовых каталогов комплектующих нет? Например от поставщиков, с единой классификацией. С этого можно было бы начать.

Занимаюсь нестандартными решениями по обновлению Open Cart. Версия движка не важна. Только структура баз данных. Обновление скриптами из крона. Интерфейс для настроек и ведения журналов в Google Spread Sheet. Автоматический бэкап до каждого обновления и т.д. Возможно подключение системы визуализации мониторинга процессов обновления и состояния сервера - Grafana. Цель - полная автоматизация процессов. Бюджет только после детального ТЗ. Как правило сильно зависит от структуры прайсов доноров. Бонус - Telegram Bot для контроля обновлений. )

Дело мастера боится. ) Структура баз несложная, поэтому напрашивается сделать свой API ) Постоянно читаю, что разработчики модулей меняют запросы.

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