Drupal7+Commerce+организация магазина

Главные вкладки

Аватар пользователя DanTeS DanTeS 3 октября 2012 в 17:08

Есть магазин с большим количеством видов товара, которые отличаются по своим характеристикам. например ноутбуки, мышки, карты памяти + стиралиные машины, морозилки и тд
Вопросы:

  1. каким образом лучше организовать product types и product display
  2. сделать 1 тип продукта или 1 дисплей или много продуктов много дисплеев (для каждого типа свое) и тд
  3. каким образом лучше для этого варианта организовать каталог товаров и их вывод (taxonomy views)

Комментарии

Аватар пользователя divined divined 3 октября 2012 в 17:13

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

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

Опять таки, какие фильтры в поиске, на сколько они различаются между группами товаров. Если различия большие то вы никуда не денетесь и все-равно придете к большому количеству типов.

Аватар пользователя thumper thumper 3 октября 2012 в 17:31

Также интересует такой вопрос.
Проблема заключается в том, что магазин продает разную продукцию - Бытовая техника, телевизоры, автомобильная техника и другое.
Выгрузка товара происходит из 1С через csv файл.
Хотелось бы организовать магазин наиболее удобным образом Smile
Так, чтобы была возможность создания удобного каталога, удобных фильтров...

Полей для фильтрации достаточно много. Характеристики у холодильников и мобильных телефонов не то что отличаются - они разные Smile
В базе 1С одинаковые модели с разными параметрами (цвет) хранятся как отдельный товар, конечно хотелось бы их как-нибудь объеденить.

Друпал (7) был выбран из-за гибкости.
Commerce по советам в интернете, да и, на сколько я понял, Уберкарт подходит больше к 6 версии (по тем же отзывам) Smile

Аватар пользователя akhmetshin akhmetshin 3 октября 2012 в 18:20

Дважды подумайте прежде чем на Друпал такой магазин делать, на сколько я помню на его интеграцию с 1С и Яндекс Маркет уходит больше ресурсов, чем стоит коммерческая CMS.

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

Аватар пользователя xxandeadxx xxandeadxx 3 октября 2012 в 18:58

"seolyric" wrote:
На коммерческом движке, где уже есть необходимый функционал.

название у этого движка какое? и какой функционал отсутствует в drupal commerce?

Аватар пользователя akhmetshin akhmetshin 3 октября 2012 в 19:46

"xxandeadxx" wrote:
название у этого движка какое?

В зависимости от задач. Например, UMI.

"xxandeadxx" wrote:
и какой функционал отсутствует в drupal commerce?

http://www.umi-cms.ru/editions/

Раз, два, три.

Видимо ты смысл моего первого сообщения не понял - целесообразнее (дешевле, эффективнее, быстрее, удобнее для конечного клиента) купить готовое решение.

Аватар пользователя xxandeadxx xxandeadxx 3 октября 2012 в 20:02

"seolyric" wrote:
Раз

http://drupal.org/project/services
http://drupal.org/project/feeds

"seolyric" wrote:
два

http://drupal.org/project/geoip

"seolyric" wrote:
три

насколько помню вконтакте давно прикрыл этот сервис

может что-то ещё, более весомое, отсутствующее в commerce?

"seolyric" wrote:
целесообразнее (дешевле, эффективнее, быстрее, удобнее для конечного клиента) купить готовое решение.

есть какие-то цифры или факты?

Аватар пользователя akhmetshin akhmetshin 3 октября 2012 в 20:34

xxandeadxx, почему так реагируешь?

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

"xxandeadxx" wrote:
есть какие-то цифры или факты?

сколько у тебя стоит заказать интернет магазин с функционалом, который описан здесь http://www.umi-cms.ru/editions/commerce/ ?

Аватар пользователя xxandeadxx xxandeadxx 3 октября 2012 в 20:54

"seolyric" wrote:
Если он ищет отзывы о CMS

он не ищет отзывы о CMS, он задал три вполне конкретных вопроса о drupal commerce

"seolyric" wrote:
сколько у тебя стоит заказать интернет магазин с функционалом, который описан здесь http://www.umi-cms.ru/editions/commerce/ ?

какой-то бред спросил. Сколько у тебя стоит заказать сайт с функционалом, который возможно создать с помощью этого http://drupal.org/project/modules ? или даже с помощью этого http://www.drupalcommerce.org/contrib/all ? начнём с малого

Аватар пользователя thumper thumper 3 октября 2012 в 20:57

Опыт разработки на Друпал есть, но не магазина таких масштабов.
В основном друпал выбирался из-за гибкости, наличия какого-то опыта и знаний по этой системе, дополнительные идеи по организации работы магазина в далеком и тд ))
Понравился магазин ktc-ua.com (тут где-то ссылка на него выкладывалась уже).
Судя по всему, вопрос по организации продукци и каталогов тут был таким же (поля характеристик для бумаги и ноутбуков отличаются) Smile

Вариант для продукции и каталогов был следующим:
Сделать кучу product types с определенными полями и пару (может один) дисплей со стандартными полями (у всей продукции есть описание, к примеру).
В дисплеях уже выставить поля таксономии.

Загрузка товара и дисплеев идет через feeds.

Аватар пользователя akhmetshin akhmetshin 3 октября 2012 в 21:30

"xxandeadxx" wrote:
какой-то бред спросил. Сколько у тебя стоит заказать сайт с функционалом, который возможно создать с помощью этого http://drupal.org/project/modules ? или даже с помощью этого http://www.drupalcommerce.org/contrib/all ?

Я не знаю, что можно создать с помощью этих модулей.

Бредишь это ты, та сборка на которую я сослался среднестатистический ИМ, а ты демонстрируешь свои глубокие знания, зачем?. Вопрос (сколько стоит) риторический на него отвечать не нужно, прикинь в уме сколько же все таки стоит сделать среднестатистический ИМ на Юми и Друпал. Речь идет именно о среднестатистическом ИМ бытовой техники, где нужен импорт в Яндекс Маркет и интеграция с 1С и учет некоторых поведенческих факторов (http://www.umi-cms.ru/editions/commerce/#ten). Я считаю, что заплатить хорошему друпалисту потребуется гораздо больше, чем стоит коммерческая CMS.

Если учесть удобство администрирования ИМ, то оно тоже не в пользу Drupal.

Вынужден напомнить свое первоначальное утверждение:

"seolyric" wrote:
целесообразнее (дешевле, эффективнее, быстрее, удобнее для конечного клиента) купить готовое решение.
Чтобы не разводить тут демагогию.

Насчет отзыва, да, я ошибся, показалось, что это сказал ТС:

"thumper" wrote:
Уберкарт подходит больше к 6 версии (по тем же отзывам) :)

"xxandeadxx" wrote:
начнём с малого

Нет, к концу уже все идет.

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 3 октября 2012 в 21:55

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

Аватар пользователя xxandeadxx xxandeadxx 3 октября 2012 в 22:07

"seolyric" wrote:
Я не знаю, что можно создать с помощью этих модулей.

я тебе расскажу — всё то, что umi даже не снилось

"seolyric" wrote:
а ты демонстрируешь свои глубокие знания, зачем?

глубокие знания чего?

"seolyric" wrote:
прикинь в уме сколько же все таки стоит сделать среднестатистический ИМ на Юми и Друпал

юми: 30000р.
друпал: 0р. или сколько там стоит пять минут в консоли?
drush dl commerce_kickstart
drush site-install commerce_kickstart

Аватар пользователя akhmetshin akhmetshin 3 октября 2012 в 22:53

"xxandeadxx" wrote:
или сколько там стоит пять минут в консоли?

Это для тебя 5 минут, а для ТС нет! Разумеется для разработчика друпал, самая любимая CMS на все случаи жизни это Д. Но если не возникает сильная эрекция при виде подобных вещей:

"xxandeadxx" wrote:

http://drupal.org/project/services
http://drupal.org/project/feeds
drush dl commerce_kickstart
drush site-install commerce_kickstart

То можно выбирать CMS в зависимости от поставленных задач! И есть системы которые более клиентоориентированы. Я не говорю, что Друпал плохой, в некоторых случаях он мне очень нравится.

Я не могу дальше мониторить эту тему. Удачи.

Аватар пользователя xxandeadxx xxandeadxx 3 октября 2012 в 23:10

"seolyric" wrote:
можно выбирать CMS в зависимости от поставленных задач!

не можно, а нужно. нет никаких "среднестатистических ИМ", есть цели и задачи

Аватар пользователя thumper thumper 4 октября 2012 в 0:06

"DanTeS" wrote:
Есть магазин с большим количеством видов товара, которые отличаются по своим характеристикам. например ноутбуки, мышки, карты памяти + стиралиные машины, морозилки и тд
Вопросы:
каким образом лучше организовать product types и product display
сделать 1 тип продукта или 1 дисплей или много продуктов много дисплеев (для каждого типа свое) и тд
каким образом лучше для этого варианта организовать каталог товаров и их вывод (taxonomy views)

"seolyric" wrote:
Это для тебя 5 минут, а для ТС нет!

Ну, зря Вы так... собственно вопрос в начале темы заключался именно в том, чтобы сделать организацию товара (схему) правильно, так, чтобы потом перекручивать не нужно было.
Друпал был выбран как раз исходя из гибкости, большого количества модулей на все случаи жизни, ну, и наличия опыта разработки разных проэктов на нем.
Вопрос не стоял в выборе CMS "все включено для юзера".

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

Также интересно было бы услышать все же что выбирают лиди - DC или UC. По отзывам я понял, что DC будет набирать обороты.

Аватар пользователя divined divined 4 октября 2012 в 0:04

Т.е. вы считаете купили ЮМИ и проект готов?
Даже при простоте его конфигурирования, придется потратить еще около 50-100к на его настройку и подгонку. Итого от 80 до 130к бублей.

За такую цену я сделаю его за 2-3 недели на друпале. Включая дизайн с версткой, импорт товаров и двухстороннюю синхронизацию с 1С. В любом случае дешевле чем выйдет минимальная цена на любом платном движке.

И опять таки: в ЮМИ проблема с матрицей атрибутов. Внутри товара вы можете на ЮМИ переключить цвет, вес, материал и чтобы менялась при этом цена?
А если этих атрибутов 10-ки да и у каждого из атрибутов 10-ки опций? Тут кроме уберкарта ничего не поможет, как бы вы не расхваляли другие возможные ЦМС-ки.

И много многое другое что не могут платные движки, но может срупал.

Аватар пользователя Andruxa Andruxa 4 октября 2012 в 3:34

"divined" wrote:
А если этих атрибутов 10-ки да и у каждого из атрибутов 10-ки опций? Тут кроме уберкарта ничего не поможет

нет
убер в этом случае (атрибутов 2 и более) не поможет - там логика такова, что он начнёт перемножать множества между собой, у меня этот эксперимент стабильно заканчивался коллапсом

Аватар пользователя divined divined 4 октября 2012 в 9:31

да, а у других вообще никакой логики на этот счет нет.

Я прекрасно знаю что он перемножает, другого варианта по идее нет. Есть, но я его не скажу Lol
Поэтому я и говорю про матрицу атрибутов.

И Уберкарт прекрасно справляет с такой матрицей 10х10.

Аватар пользователя thumper thumper 4 октября 2012 в 11:15

"thumper" wrote:

Этот же вопрос интересует.

Есть поля, которые для всех товаров одинаковые (текст с описанием, галерея, видеообзор и тд), а есть абсолютно разные, например "тип наушников", "тип подключения мышки", "диагональ" и тд
как бы это было правильнее организовать с точки зрения "эстетичности" и рациональности (кол-во записей в БД, нагрузка на сервер при работе с ними, удобство пользования).

Пока что было несколько вариантов

Product type <-> Product display
1) 1 <-> N
2) N <-> 1 (2,3,4)
3) N <-> N

1й вариант плох тем, что есть всего один тип товара и по одному шаблону грузятся все товары. Есть товары, которые имеют атрибуты типа "цвет", "размер", "диагональ" и тд, которые подходят именно для этого типа товаров, а есть продукты, которые такого вовсе не имеют (например карты памяти). и тогда с хранением таких данных и возникает проблема.
С Характеристиками товара тут особо проблем нету (если это мышка КОМПАНИИ Х, то "цвет на скорость не влияют" Smile

2й вариант более менее интересный. Создать 1 (или пару) дисплеев, в которых бы были включены поля, которые будут показаны для всех товаров (например: "диплей с текстом", "дисплей с текстом и видео",....)
Тут у товара можно хранить и атрибуты и характеристики.
Минус заключается в том, что для одного товара, имеющего разные атрибуты но одинаковые характеристики (мышки разного цвета, "цвет на скорость не влияет"), то в базе придется хранить кучу одинаковой инфы (записи в БД отличаются только атрибутом, но с кучей одинаковых полей по характеристикам).
Еще один минус, это то, что на страничке товара, как я понимаю, при смене атрибута постоянно будут обновлться поля характеристик.

3й вариант неплохо подходит.
Проблема в громоздкости. ну и в удобстве работы.

скопипастил свой пост с другой темы ) В этой как-то все активней обсуждается Smile

Аватар пользователя thumper thumper 4 октября 2012 в 12:15

"divined" wrote:
Безусловно N <-> N

N < - > N тоже привлекает больше всего.
Просто не возникнут ли потом проблемы при создании и настройки вьюх и фильтров?
Не повлияет ли такая громоздкость на работу сайта?

Спасибо большое за советы Smile

Аватар пользователя kinoz4 kinoz4 18 декабря 2014 в 22:48

Скажите,
есть ли реальный опыт решения поставленной ТС задачи?
Как все-таки лучше организовать хранение характеристик товаров?