3 апреля 2012 в 12:51
Добрый день!
Подскажите как лучше сделать,
делаю интернет магазин одежды на Drupal Commerce,
как разбить товар: к примеру женская одежда, мужская одежда или лучше разбить на категории брюки, майки, куртки и т.д.?
Возможно ли будет объединить в одной ноде при формировании продукт дисплей размер и цвет товара?
Комментарии
Если вопрос непонятен, уточните
????
почему нет ответов?
Хочу сделать выбор размера одежды в ноде, но не создавая дополнительный товар. Например создал товар джинсы, а в ноде указал несколько размеров этого товара на выбор. Вопрос реализуемое ли это в Drupal Commerce?
имхо:
словарь sex
муж жен унисекс
словарь age
взрослый детский
словарь weartype
рубахи брюки куртки и тд
словарь material
словарь brand
это референсами в поля отображения товара
по ним и фильтровать и меню
к товару поле список текст в него размеры - разрешить ему быть атрибутом при добавлении в корзину
к отображению товара - поле ссылка на товар (множественный выбор значений)
создавая отображения товара добавлять несколько товаров с разными размерами
делать
пациму!!!
))
успехов в работе.
Спасибо, так и сделал
Только непонятно как сделать выбор по размеру не забивая товар в товары,
забил один товар в товары, а потом сделать выбор по размеру уже в ноде?
Сейчас приходится забивать товар с размерами в товары,
т.е. джинсы M, джинсы ХL, джинсы XXL, а потом объединять все товары в одной ноде и делать выбор по размеру, а как сделать чтобы в товары забить один раз джинсы, а в ноде сделать выбор по размеру?
По-умолчанию только так и надо.
Как быть, например, если товар с размером XXL раскупят?
Это не проблема сейчас, учета остатков на складе не будет
ничто не проблема))
ошибка в фундаментальном конструктивном решении - не проблема....
ведь всегда можно все переделать с ноля без ущерба сроку и бюджету...
и следующий - опять с ноля клепать под новые изье..
))))))))
универсальный подход
есть в риале товар (цена характеристики) - вот и в коммерце товар.
штанья M и XXL - разные вещи по сути))
а то что они лихо группируются в один дисплей ибо обладают всеми общими признаками кроме размера - так это ГУД!!
Делай как разработчики коммерца рекомендуют, а потом обогати функционал своими наработками
вот тогда и мудруй и с автосозданием дисплеев или товаров, с удобными отчетами и редакторами контента для манагера и тд.
тут уж негде крутиться - если это не 25й магаз склепанный на коммерце - для себя и окружающих дешевле проплыть по течению ))
Это замечательно... Но в товаре есть картинки. Да, для желтых и малиновых штанов нужны отдельные картинки, но зачем мне разные картинки для желтых штанов размера M и желтых штанов размера L? Ведь новый product требует загрузки своей собственной картинки. А если у меня в товаре 5 картинок для желтых штанов (с разных сторон)? Умножим на семь размеров - 35 картинок. Хотя реально нужно только 5. А ImageCache сделает три размера картинки и их будет 105. 105 изображений желтых штанов!!! Ведь 5 картинок - это обычная ситуация для хорошо сделанного магазина. Неужели это нормальная практика: плодить множество копий одной картинки? Как-то некрасиво. Как быть?
Commerce BPC поставить.
С product и нодой-дисплеем вроде бы разобрались, позволю себе немного пофлудить.
Итак, DC-way предполагает, что особенности товара (product) хранятся в его филдах, а в ноде-дисплее они группируются виджетом одноимённого филда.
Например - магазин по продаже футболок, product - это непосредственно футболки, каждая имеет 2 поля-атрибута: цвет и размер.
Хочется сделать фильтры в представлении-каталоге, чтобы покупатель мог сформировать свой запрос: "покажите мне все футболки белого цвета размера XL"
Поскольку представление выводит ноды-дисплеи, а не сами product, то выборка становится достаточно сложной: нужно отфильтровать ноды, которые не ссылаются на product, имеющие определенный цвет и размер.
Второй пример - блок "самые продаваемые товары".
Следуя логике DC, сначало надо найти N product, количество которых максимально среди оплаченных заказов, а потом -=tada.wav=- надо найти ноды-дисплеи, содержащие ссылки на эти product.
Причем, ситуация может усугубляться тем, что никто не запрещает создавать одному product несколько нод-дисплеев, например шнур USB A-B может преподноситься как "шнур для передачи данных от фотоаппарата SONY к ноутбуку" ну и т.д. - бывают такие юзабилити-френдли магазины для идиотов.
В этот момент мой диссонанс становится всё более когнитивным - а надо ли было мудрить сущность product, если её использование в ситуациях, хоть немного отличающихся от типовых, тянет за собой столько неудобств?
Что думаете?
Не очень просто из-за множественного поля, но сделать кажись можно. С бэкреференсами на товары сейчас пока вроде туго, да. Хотя видел где-то подвижки.
в самое яблочко)
с появлением product возникло вполне обдуманное разделение на витрину и бухгалтерию,
типовые задачи - 90% всех задач))
для меня коммерц понятен и удобен - правда пилить под него много,
но буду пилить именно под него а не под убер ))
я воспринял в своё время появление product как материализацию SKU из уберкарта, тут всё хорошо и правильно
но вот дальнейшее наращивание фичей непосредственно в product - штука сомнительная, имхо
что касается бухгалтерии - ей надо обмениваться ценами, остатками и заказами с CMS, остальное - от лукавого
навороты product тут не только не нужны, но и порою вредны
Я картинки на складе не вставлял, а поставил их уже в ноде и описание товара там же
Но если захотите, чтобы картинки товара отображались в корзине, то такой вариант не подойдет, если не ошибаюсь
Подойдет такой вариант.
Более детально обсуждали не так давно)
однако сие не снимает вопроса поднятого vmogila
сижу вот теперь, кручу, как его кошерно то сделать,
зачем только прочел ..
)))
А я на всякий случай повторю: Commerce BPC решает данную проблему. Только что специально создал товар с четырьмя размерами и тремя разными картинками. В Commerce BPC на сайте появилось ровно 3 файла изображения. Не 4*3=12, а 3.
А есть еще "упрощенка" http://drupal.org/project/commerce_option - которая позволяет отойти от принципа "отдельная сущность product для каждой комбинации атрибутов". Но конечно пользоваться плюсами принципа тогда тоже нельзя. И если скомбинировать Commerce BPC и Option - можно сделать цвет атрибутом, а размер - опцией.
А Вы реально пользователись этим модулем? Судя по описанию, он решает проблему с размерами-цветами без создания новых артикулов. Но реально - у меня получается какая-то хрень :(. Поле в товаре появляется. Но забивать размерами при добавлении товара в магазин возможности нет. И так покрутил и так, и "по колесу пинал" - "не выходит каменный цветок" :(. Помогите советом?
Нет, я bulk-ом создаю товары с разными артикулами под разные атрибуты.
Похоже, http://drupal.org/project/commerce_option depricated. Более не развивается.
Нашел для себя решение, чуток модифицировав код, предложенный другим участником. Суть: при помощи hook_form_alter() исключить из списка значения, которые недоступны для выбора (их нет в наличии).
Решение описал тут: