17 июня 2011 в 20:41
Ну а если серьёзно, делал на нем кто-нибудь магазин товаров с большим количеством аттрибутов и вариантов?
Я как-то не ожидал, что для того, чтобы добавить платье в пяти расцветках и 10-ти размерах, мне нужно создать 50 товаров, да еще и страницу отображения для них - и все это руками по типу добавления терминов таксономии - это же острая форма геморроя. Забить 50 одинаковых тайтлов, 50 цен и так далее.
Ок, поставил модуль Bulk Product Creation - один хер, научи теперь менеджера пользоватся токенами для генерации названий и SKU. И при этом ни цен разных не задать, ни конкретных комбинаций - только все возможные комбинации выбранных аттрибутов с одинаковой ценой херачит - а потом иди удаляй лишнее и редактируй цены. Токенов кот наплакал, таксономия как аттрибуты не поддерживается... И это еще без стока и прочих прелестей.
Как они это юзабельным сделать хотят?
Комментарии
Не уверен, конечно, но добавляете поле - ссылка на термин таксономии, там есть галочка "использовать как атрибут". Ставите количество значений - не ограничено.
Страница отображения - через views.
Таксономию не поддерживает именно Bulk Product Creation
А отображение там через тип данных идет и эта процедура привязки продуктов к ноде какое-то извращение. Автоматизировать можно, но только этим же глючным и малофункциональным Bulk Product Creation
Не о пользователях думали видимо, а о том как бы сделать модуль максимально друпаловским и апишным.
Сергей, я уверен у Вас есть очень хорошие идеи как улучшить commerce и сделать его юзабельным. Так вперед в контрибуторы!
Ненужно такого счастья!!!
Кому ненравится берите уберкарт, а эту афигенно-суперпупер-правильную систему оставте так как есть.
А то я тут делал магазинчик очень специфичный, так уберкарт его нифига неосилил. Вернее уберкарт осилил, но с его реализацией, при большом числе заказов, легко положет любой сервак, ибо вследствии кривизны апи нет возможности оптимизировано пописать(<-ударение на последний слог).
А вот на комерце все очень правильно получилось.
Если Вы не осилили комерс, то лучше Вам уйти от drupal в сторону других cms(мамба епт).
Ну так как, как у вас менеджер заносит товары с десятками вариантов?
Заказчик плевался от уберкарта, монструозный, сложный, неэффективный и тд, Commerce же мне показался легким, простым и приятным, но такое менеджеру для заполнения я отдать не могу, это ни разу не юзерфрендли и ни разу не интуитивно понятно.
Я подредактирую заголовок, я не со зла, а в шутку и внимание привлечь
А еше мне интересно что вы сделали на commerce и не смогли на ubercart
"Неэффективность" Уберкарта легко побеждается +5000 рублей в месяц на выделенный сервер. Никогда не понимал, и не пойму, наверное, этой тупорылой экономии на спичках владельцев интернет-магазинов. Эти 5000 рублей у большинства отбиваются с 1-2 заказов (ну или барыге нужно просто пару раз пропустить дежурный обед в ресторане). Нет, надо запихать друпал с уберкартом на шаред-хостинг с 64 мегабайта на PHP, и мучаться, и орать на всех перекрестках про "неэффективность". На Битриксе, млин, почему-то стараются не экономить (Битрикс отличная штука, но дорогая, сцуко
), а на Друпале с уберкартом экономят, хотя функционал часто один и тот же. В чем соль, млин?
p.s. И, да, не нанимайте тупых менеджеров, вам самим потом это не раз аукнется.
А есть посмотреть?
marazmus
+100500. Как бизнес может себе позволить экономить на основном средстве производства ?
Добавлю еще, что свой сервер в Германии начинается с очень смешных денег, гораздо меньших указанной суммы. А пинг из России может быть всего на 50-100мс выше, чем до московского ДЦ. Может горе-коммерсантам стоит задуматься об оптимизации затрат в эту сторону..
А кто этот сервер админить будет? Владелец? Если проблемы возникнут и т.д. С линуксом проблемы решать...
А на шареде сайт работает себе, системные вещи вообще не владельца проблемы, а с друпалом даже и программист особо не нужен. Ляпота.
Если ВАШ сайт не работает, то это - сначала ВАША проблема, и только потом - администратора хостинга. А чтобы определить, чтобы проблема есть, иногда тоже админ нужен. Или вы рассчитываете, что на любом хостинге будут копаться в ваших скриптах, чтобы выяснить, кто виноват в ситуации ?
Или вы хотите утверждать, что хостинг не будет переводить стрелки на клиента ?
А если в хостинге такой супер-сервис, значит этот хостинг может стоить как сервер в германии + админ.
Про шаред в 95% случаев это неправда. Да, базовую систему запустили, да, php поставили. И погнали... 200-400 аккаунтов на одном сервере.
При любых проблемах тех.поддержка на шареде априори считает, что клиент неправ. Медленный конект к базе -- "Проверяйте ваши скрипты". Убобищный пинг -- "Виноват ваш локальный интернет-провайдер". Руткиты в /tmp -- "Ой,
бля,это не наше".Вы реально думаете что некому?
а глянуть можно что использовали?
Речь не о ubercart и серверах.
Вы правда предлагаете учить менеджеров пользоваться токенами и объяснять им что вот это товар, но ему еще и отображение надо.. ему делать думаете больше нечего?
отдельно и за деньги? Понятно, что найдутся желающие.
Я понимаю, что наверное есть дедики, где все делают админы хостера, но я смотрел эти расценки, немало.
Что такое - заказал дедик? Это - тачку к инету подключили, а дальше - ты сам. Админь, php устанавливай, mysql оптимизируй. А конечный владелец постоянного себе админа держать то не будет. Вот и получится, чуть что - заказывай работу со всеми вытекающими трудностями.
Читаем http://www.ihc.ru/ds.html :
Несмотря на то, что сегодня большая часть частных предпринимателей и небольших компаний пользуются виртуальными выделенными серверами, крупные компании, работающие с большим количеством информации и имеющие обширные базы данных, покупают собственные или берут в аренду серверы
Это разовые работы.
Постоянный админ - "приглядывающий" за сервером стоит не так дорого. Там не так много работы, как может показаться. Есть еще аутсорсинг таких услуг, у них поставлено на поток, т.е. их издержки ниже, а значит они могут предложить более низкие цены своим клиентам.
Ну так в капиталистическом мире живём.
100-150 баксов за админство не великая сумма в месяц
читайте дальше, удачи. Про VPS Мастерхоста за 2500р "спешл фор битрикс" рассказывать или нет?
p.s. на нём битрикс еле заводится
может для вас. 180$ сервер + 150$ админ = 330$.
Это больше чем зарплата работнику за месяц(по Украине сужу). Т.е. бизнесмен еще одного сотрудника "нанимает" и оплачивает.
Сразу вопрос - а почему бы сайту не работать нормально например за 20$ на тарифе "Шестой" тут: http://dh.it-patrol.ru/drupal_hosting/drupal
Это же типа специальный друпал хостинг, не будет на нем инет-магазин что ли работать? Если не будет, то спрос - с хостера.
при большом количестве заказов первыми лягут поставки, комплектация заказов, их доставка курьерами и почтой
сервер тоже ляжет, но дело в том, что сайт - это процентов 20 всего инет-магазина, по моему опыту
люто, неистово плюсую
в последнее время меня терзают смутные сомнения насчет отдельного шареда под статику, расположенного поближе к покупателям,
что и хотелось бы обсудить с уважаемым сообществом:
- например, сам сайт (база, скрипты) расположены за бугром по причине более низких цен и недоступности для серых братьев,
а на шареде, расположенном в каком-нибудь московском (питерском, новосибирском - кому что ближе) дц стоит какой-нибудь энджинкс, раздающий статику
вроде бы и нагрузка на сайт должна уменьшиться, и скорость загрузки возрасти, особенно для анонимусов и поисковых ботов
что думаете?
Такая схема имеет право на существование, только должна быть очень весомая причина для такого усложнения схемы, ведь количество сущностей - серверов, аккаунтов и т.д. - увеличивается, а значит увеличивается сложность управления всем этим. Это может быть оправдано, например, в случае раздачи очень тяжелых картинок - например, если у вас куча качественных полноэкранных фотографий товаров. В таком случае пользователь из российской глубинки может гораздо быстрее их загрузить.
не соглашусь, зависит от ТП
не буду постить пруф, дабы не заниматься спамом хостинга
В случае с Друпалом - неэффективно. Если сервер грамотно настроен, у него на фронтенде и так стоит nginx, раздающий статику, причем в несколько потоков. А 99% нагрузки на сервер генерит не раздача статики, а как раз Друпал, то бишь Apache + PHP + MySQL. А для анонимусов и ботов должен быть настроен кеш
А если вы упретесь в производительность сервера, то первое, что нужно будет сделать - это вынести на отдельный сервер MySQL, а не статику.
Боюсь что нет, сервер и так +5000 р. И эта тема была хорошо обжевана на орге, не поленитесь поискать.
Ага, первыми лягут поставки электронных билетов на стадион, смешно.
Первой ляжет sql от кривых джойнов выбора паспортных данных из оплаченых заказов.
marazmus, спасибо за инфу
все-таки снятие нагрузки с друпала - это вторичная задача в данной ситуации, первичная - добиться более быстрой загрузки страницы
но похоже что да - ловить милллисекунды это все равно что ловить блох
согласитесь - специфичный пример, всё-таки большинство е-магазинов работают по принципу "деньги-товар-деньги"
Я так и написал, что магаз специфичный, и для обычных магазинов лучше юзать уберкарт или другую cms.
Получается так, что если берем уберкарт, то мы сразу получаем работоспособный магазин женских кофточек, а если нужно что то особенное то начинаем писать многобукаф кода.
Если берем комерц, то для того, что бы продавать кофточки, нужно сразу писать многобукоф кода.
А для специфичных магазов получается теже многобукоф как и для кофточек но они оптимизирование чем многобукоф для уберкарта в случае специфичности магазина.
Drupal можно сказать тоже cms для специфичных сайтов. Стартануть новичку какой-нить блог на drupal сложнее чем на вордпресе но drupal позволит легко масштабировать блог до сайта любого уровня в отличие о вордпреса.
Поэтому я считаю что комерц это тру-друпал-вэй и пусть он таким и останется.
Одно дело трудно делать, другое трудно использовать.
Будет работать, но ведь все хотят шаред за 100р, а модулей на облако, не так ли?
Ubercart 3 кстати тоже неюзабельный из-за багов, особенно в модуле stock
Ну и большей части must have дополнений нет, например out of stock notofication
короче коммерс может и друпал вэй, но ему идти до юзабельности убера еще долго. (напевая: дорогой длииинной, дорогой... )
Не знаю как множественный выбор и отсутсвие уникальных артикулов помогут мне быстро забить 50 вариантов одного товара, которые имеют различия в цене и для которых ведется складской учет.
Им Bulk Product Creation нужно переписать кардинально, ибо это тулза не уровня администратора магазина, а разработчика скорее
Самый простой способ все импортнуть, благо модуль Feeds позволяет сделать это очень просто.