Как стать автором
Обновить

Комментарии 27

Спасибо! Как раз вовремя!
Пожалуйста!
Пишу без наездов

Жмём кнопку «купить»
image



Переходим к оформлению заказа
image



Заполняем поля
image



и долго-долго ждём эту страницу (более минуты!)
image

Вот уже ступор. А где вариант выбора оплаты/доставки? Зачем всё так усложнять пользователю?

А вот это очень даже неприемлемо, ведь вы предлагает пройти пользователю дальше и просмотреть заказ. И вот что дальше, если нажать

страница управления заказами
image

«эта ссылка»
image

Скромные пункты todo

  • Регистрировать пользователя в процессе оформления заказа и в процессе заказа предлагать авторизацию или регистрацию с последующим редиректом на продолжение оформления.
  • Сделать пошаговое оформление заказа (авторизация/регистрация → выбор доставки → выбор оплаты → просмотр данных заказа → отправка заказа)


Извините за долгий ответ. Отдыхал.

Спасибо, что подробно все расписали! Да, все именно так. И сейчас этот момент сразу разберем.
На самом деле просто еще не все сделано. Мы вдвоем с напарником эту обновленную сборку сделали дней за 5 (правда в авральном режиме), и закладывали только самую основу. При этом очень многое уже заложено, и расчет на то, чтобы примерно движок можно было оценить и оценить примерный объем работ по доработке, но доработки индивидуального — это как правило на любом проекте.

и долго-долго ждём эту страницу (более минуты!)
С задержкой ясности нет. Сам ни разу не видел тормозов на сайте. Может в сети перебой был, а может хабраэффект (таки заказов новых в системе уже 760). И серверочек оочень простенький за $10 с одним ядром.

Вот уже ступор. А где вариант выбора оплаты/доставки? Зачем всё так усложнять пользователю?
Сами мы в процессе конечно на основе отзывов и советов постараемся какую-то оптимальную схему заложить, но всем мы все равно не угодим, так как на многих магазинах наблюдаются совершенно разные пользовательские сценарии. Но я могу вам гарантировать, что на этой сборке свой сценарий заложить вообще не проблема. Если вы со Smarty работали, то поймете почему.

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

Не был получен заказ
Скорее всего вы попытались открыть ссылку оплаты без GET-параметра с ID заказа. Если сразу открыть ссылку оплаты (с ID-шником), или перейти в управление заказами и оттуда открыть, то все будет ОК.

Регистрировать пользователя в процессе оформления заказа и в процессе заказа предлагать авторизацию или регистрацию с последующим редиректом на продолжение оформления.
А другие требуют возможность оплаты и оформления заказов без авторизации :-) На самом деле это все уже делается конечным программистом, так что если у вас будет интерес и вы доберетесь попробовать это попрограммировать, то обращайтесь с любым вопросом, я все подскажу.

Кстати, в админке есть онлайн-среда для программирования и основные модули добавлены в проект
www.youtube.com/watch?feature=player_detailpage&v=g_cSfGgSO9g#t=464

Сделать пошаговое оформление заказа (авторизация/регистрация → выбор доставки → выбор оплаты → просмотр данных заказа → отправка заказа)
Так же будем думать над каким-то универсальным сценарием, но в большинстве случаев все равно же каждый под себя будет дорабатывать.

P.S. у меня карма минусовая, отвечать могу раз в час. Если не сложно, плюсуйте карму.

P.P.S. по поводу багов и обновлений: если баги находите, не стесняйтесь, шлити багрепорты. Если кто переживает, что поставит сборку, а потом вылезут баги и кто и как это будет править — не переживайте. Будут выкладываться патчи и так же через менеджер пакетов в админке вы всегда сможете накатить свежий патч. Никакой переустановки или ручного патчинга не потребуется.
Баги исправил. Выпустил патч (ShopModxBoxPatch (так же доступный для скачивания в менеджере пакетов) ) и новую сборку ShopModxBox-2.0.1

Помимо исправления добавлены вход через Яндекс и госдеповская таблица транслитерации.
подтверждаю глючок.
неправильно считается количество товаров в корзине
image
Спасибо за багрепорт!

Да, причина понятна. Вы скорее всего добавили два товара, а потом один удалили. Из соображений сбора статистики товар из корзины не удаляется на самом деле, а просто устанавливается кол-во 0 (потом будет статус скорее всего докручен). А при выборке товаров корзины я забыл добавить условие quantity != 0.

Поправлю, патч выложу.
Да нет же.
1. зашел на сайт
2. ткнул на название товара (открылось как бы его описание)
3. нажал «купить» (появилась черненькая плашка, что товар добавлен)
4. нажал на ссылку в правом углу
5. увидел этот результат
— Только что повторил это в другом браузере с полностью чистыми куками и т.д.
глюк тот же. «в корзине 2 товара»
ОК. Будем тестировать и поправлять.
Этот баг тоже пофиксили. Спасибо за багрепорт!
Если выбирать из модх то выбор очивиден :-)
А если нет то тогда мадженто
А почему не Drupal + Commerce?

Меня всегда поражает, когда топик про одно, а там навязывают другое. Почему бы не отписаться по делу?
Только по тому что маджента лидер рынка, а значит на многие грабли там уже наступили сотни раз. Но если для вас легче тратится на поддержку (ну например сайт умрёт через год) то любое решение сойдёт

По делу мне нечего сказать. Как то с этим продуктом не довелось столкнутся. Слышал только о наличии двух веток развития, что дополнительно отталкиват от платформы

А продукт для которого сразу нашёлся баг в основном функционала втопку
| А продукт для которого сразу нашёлся баг в основном функционала втопку
Это бета. Вы где-то видели бету без багов? Бага будет поправлена.

По поводу магенты: каждый выбирает то, что ему больше нравиться/подходит — это однозначно. Но говорю вам точно, что обращался к нам заказчик после того, как изначально они хотели делать магазин на магенте (вопрос бюджетов вообще не стоял). Но как ни странно, именно магенто-разработчик после детального изучения ТЗ сказал, что он замахается дорабатывать эти хотелки на магенте (так как магента — узкопрофильная) и посоветовал именно MODX. Вот то, что получилось: www.factum-doors.ru/ (13 000 товаров). Вообще это только один из двух сайтов (розничный). Вообще на этом же движке крутится еще один сайт (для оптовиков), который внешне полностью отличается (к сожалению, не могу его показать, заказчик просил не показывать). Так вот, это не два отдельных сайта на копиях движка, а именно два сайта на одном движке, но на разных доменах. И каталог они используют единый. Просто в товарах проставлены сразу розничная и оптовая цены.

Сайты полностью отличаются, даже пути к картинкам.

Но это еще не все. Там каталог не просто Производитель-Товар. Там товары собраны в модели товаров. Это потому что есть модель двери, к примеру Венеция, и у нее есть куча всяких исполнений (цвет, материал и т.п.). Порой таких вариантов до 160-ти штук. Так вот, основное описание делается в модели товара, а индивидуальные параметры (цена, картинка, материал и т.п.) — это уже в самом товаре. И вот можете глянуть как сделана карточка товара вот здесь: www.factum-doors.ru/dveri_mezhkomnatnye/milyana/venecija/
Выбирая параметры двери, подставляется картинка именно соответствующая этим параметрам. А выбирая картинку, меняются параметры.

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

Поэтому, не было бы прецедентов, и разговора не было бы.
Картинки к комменту смотрите в UPD3 топика.
Но это еще не все. Там каталог не просто Производитель-Товар. Там товары собраны в модели товаров. Это потому что есть модель двери, к примеру Венеция, и у нее есть куча всяких исполнений (цвет, материал и т.п.). Порой таких вариантов до 160-ти штук. Так вот, основное описание делается в модели товара, а индивидуальные параметры (цена, картинка, материал и т.п.) — это уже в самом товаре. И вот можете глянуть как сделана карточка товара вот здесь: www.factum-doors.ru/dveri_mezhkomnatnye/milyana/venecija/
Выбирая параметры двери, подставляется картинка именно соответствующая этим параметрам. А выбирая картинку, меняются параметры.
Drupal + Commerce из коробки с условием, что у разработчика прямые руки и есть знания :)
А factum-doors.ru мне понравился

Удачи в нелёгком деле!
Спасибо!
Будем стараться.
И в маджента тоже из коробки
Но согласен что друпал Ито лучше
Как бы запускать сайт на бета версии интересное решение…

Но зато вы смо ли сделать то что хотели — это уже успех:-)
Хотя велосипедом так попахивает

Модуль — бета. А сам движок MODX — не бета. Так что ничего особо страшного нет. И это только пакет. Реальный проект будет доработан и нет никаких проблем.
В любом случае ни магенту, ни друпал ничто другое лично я не возьму. Просто потому что мне не хочется. И другие так же делают, выбирая то, что ему хочется, иначе все бы сидели только на одном каком-то движке, но они этого не делают. Поэтому, если вам это не нравится — здесь с моей стороны нет никаких упреков. Понравится кому-нибудь другому.

| Но зато вы смо ли сделать то что хотели — это уже успех:-)
спасибо.
Спасибо за сборку! Работает интересно!
Пожелание: сделайте проверку на наличие адреса доставки с почтовым индексом, чтобы конечному менеджеру пришлось меньше обрабатывать заказы. Или разбейте это на отдельные поля. Я думаю, что учитывать такое в заказах будет куда проще. Индекс показывает относительную адресацию до района или почтового отделения. Заодно отобьет спам-ботов
У меня карма минусовая, поэтому топики писать могу раз в неделю всего :-)
На днях подготовлю топик, в котором опишу принципы кастомизации. Суть заключается в том, что это не один компонент. Здесь несколько слоев и направлений. К примеру, Smarty-шаблон можно назвать самым высоким уровнем. По сути патчи и новые сборки не предполагают внесение изменений в шаблоны, так как изменение их — это уже дело конечного разработчика. Так же для надежности рекомендуется сразу переименовывать или делать копии паблик- и смарти-шаблонов default (затем просто меняете имя шаблона в настройке компонента modxSmarty).
На уровне шаблона можно уже очень многое поменять. К примеру, прописать собственную дополнительную проверку, вызвать другой/другие процессоры и т.п.

Далее (если рассматривать процесс заказа товара (да и в принципе большинство логики через него проходит)) — это компонент basket. basket — это и фронтовая работа с заказами, и модуль управления заказами в админке. Но он — средний слой. То есть если доработки предполагаются довольно большие, то можно смело делать его копию и полностью переделывать. Если изменения предполагаются, но не большие — то просто можно написать свои расширяющие процессоры-классы в своем модуле и все.

А вот дальше идет модуль billing. Вот его уже трогать ни в коем случае не советую. Ежели решите трогать, считайте, что обратной совместимости на апдейтах уже не будет. Именно этот компонент обеспечивает самую важную логику по заказам, оплатам и т.п. При этом логика там минимальная, чтобы обеспечить гибкость на уровне модулей типа basket. То есть логических проверок там минимум, только самое необходимое (к примеру, обязательное указание order_id в процессорах, которые работают с заказами, или new_status в процессорах, отвечающих за смену статуса). Но самая логика когда статус можно менять или нет, или какие поля обязательные — это уже basket.

Расчет на самом деле ни в коем случае не на то, что эта сборка из коробки сможет покрыть 95% задач всех магазинов. Расчет именно на быстрый старт и легкость модификации. Кому-то надо индекс, а кому-то оплата в один клик нужна. У каждого магазина свои задачи. Но по опыту могу утверждать, что многие проекты после того, как разрабатываются до какой-то логической точки со своими индивидуальными фишками, почти не обновляются в плане ядра. Свои плюшки дописываются, это да, а вот ядро порой по года два не обновляют. Особенно если низкобюджетный проект. И вот как раз на это и был расчет — чтобы программист с малыми бюджетами быстро мог реализовать проект со своими плюшками.
Вопрос по реализации. Как реализовано хранение товаров через ресурсы или в сторонних таблицах?
Я сам тоже реализовывал магазин на MODX. Моя реализация на сторонних таблицах. Но в моем случае без этого было никак, т.к. магазин работает под 1С (через обмен данными) и категоризация товаров там двойная: по структуре номенклатуры из 1С и по свойствам товара. Отображение во фронтенде по свойствам. Пришлось изрядно попотеть и конструкцию со стороны БД пришлось укреплять процедурами. А для управления всем этим чудом использовал MIGX.
И так, и так. То есть есть документ-товар (ShopmodxResourceProduct, расширяющий класс modResource), и есть таблица с сопутствующими данными товара (ShopmodxProduct). Это дает несколько плюсов:
1. Возможность получить разом все товары без перебора категорий и т.п., просто за счет inner join. Таким образом отсекаются все остальные документы сайта.
2. Хранение основных полей товара не в TV или типа того, а в одной строчке своей таблицы (к примеру цена, артикул, валюта и т.п.).
3. Генерация УРЛов и кеширование карты ресурсов средствами самого MODX-а, нет необходимости написания собственного роутера.
4. Совместимость с большинством родных пакетов для MODX-а.
5. Можно использовать TV-шки, различные шаблоны, уровни доступов и т.п.
Еще куча всяких плюшек.
А вот с хранением товаров в нескольких категориях — это и мы делали. Это просто через дополнительную таблицу Товар-Категория и собственный роутер. В принципе, не возникало кучи проблем.
Ничего не скажешь. Для большинства магазинов такого движка более чем хватит. Надо будет на досуге поковыряться.
Поковыряйте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории