evoCart – простая и гибкая корзина с модулем заказов

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

инструкции и сам пакет тут: https://github.com/gadev/evoCart

модуль управления заказами:


37 комментариев

avatar
При всех, хорошо известных, недостатках SHk у него есть несколько существенных плюсов:
1) Каждую строчку кода мы уже знаем «в лицо»
2) Для него есть десятки «обвесов» как готовых, так и кастомных, лежащих у каждого по гитхабам
3) Имеет систему событий
В связи с чем вопрос: Ваш проект вы позиционируете как альтернативу или как полноценную замену (тогда поясните в чем, на ваш взгляд, преимущества)?
avatar
а доклистер — это полноценная замена или альтернатива дитто? :) (там ведь тоже хватало готовых решений и все косяки все знали влицо)

преимущества описаны в топике (и на гитхабе):
— быстрый запуск
— все выводы и почти вся логика через doclister и prepare-сниппеты (соответственно никакого лишнего апи или параметров и полная свобода действий)
— никаких динозавров типа phx или jquery-функций типа .bind() (тут вообще без jquery)
— работает на php 7+

по событиям — всегда было достаточно того, что есть (на пересчет доставки).

да, доки на гитхабе пока неполные, потому что писались постфактум, но кода тут мало и все оч просто, чтобы понять, что решение позволяет покрыть большой объем недефолтных потребностей, если вы в состоянии написать/отредактировать dl_prepare-сниппет. если нет, то тогда это простенькая корзина (добавить товар / оформить заказ)
Комментарий отредактирован 2018-09-12 09:39:48 пользователем arty
avatar
DL, конечно, замена Ditto, а вот CfgTv, ClientSettings или customSettings — это альтернативы друг-другу. Ну, в моем понимании.
Касательно непосредственно ваших преимуществ:
1) SHk тоже ставится в один клик.
2) DocLiter и его prepare это то, что используется для вывода каталога и особого отношения к корзине не имеют.
3) phx? давненько его в глаза не видел. На счет jQury — полезно, но не столь критично ИМХО.
4) Модуль в виде простой таблицы со сменой статуса… Ну у меня такой модуль и под SHk валяется...)
Поймите правильно: я не домататься хочу, а понять плюсы вашего решения и возможность его расширения. Если оно поставляется как есть, а затем для его расширения нужно будет каждый раз что-то дописывать, и готовые дополнения для него нельзя будет взять и скопировать (как например в случае с ШК), это один расклад. Если вы планируете его и дальше развивать и дать возможность развивать другим участникам (как например через систему плагинов) — другой.
Ну и в связи с тем что по обещаниям Дмитрия модуль для evoShop вот-вот должен выйти, который даже по первым впечатлениям несколько интересней вашего, хочется понять ценность evoCart для сообщества в целом.
avatar
очевидно, для вас ценности нет, проходите мимо. какой смысл мне вас в чем-то убеждать? пользуйтесь шопкипером и ждите evoShop
avatar
Я не просил меня убеждать) Я задал вполне конкретные вопросы, на которые хоть и получил ответы, но посчитал их недостаточными.
За выкладку решения — в любом случае спасибо! Просто обидно будет если очень необходимое решение в виде корзины превратится в очередной TVShop(
avatar
1. речь не об установке (теперь любой пакет ставится в один клик), а о полноценном старте базовой корзины. на всякий случай уточню – для меня.
2. вероятно вы поленились посмотреть код или вкладываете в корзину что-то другое, но она выводится и просчитывается именно через dl и prepare. соответственно, ничто не мешает вам переносить 1-3 файлика prepare-сниппетов с вашей логикой из проекта в проект
4. вы молодец

код лежит на гитхаб — любой может отправить ишью или пуллреквест. или даже написать здесь. но «мне нужна система ивентов для плагинов», как очень голословно. я исхожу из своих задач и пока не вижу где и как они могут понадобиться, поэтому хотелось бы конкретики.
Комментарий отредактирован 2018-09-12 11:09:57 пользователем arty
avatar
Советую отказаться от prepare-сниппетов в пользу контроллеров, что для DL, что для FL: удобнее будет и разработчикам и пользователям. Ну и верстку из кода лучше вынести.
avatar
верстку уберу. про контроллеры — хорошо, посмотрю, я как-то этот момент пропустил, хотя и сталкивался в других решения.
Комментарий отредактирован 2018-09-12 12:03:16 пользователем arty
avatar
Не поленился и смотрел.
Корзина для меня это не просто вывод содержимого, это целый инструмент, который включает в себя мультивалютность, интеграцию с платежными системами, изменение параметров на странице оформления заказа и т.д. и т.п.
Так же не совсем ясно как менять цену в зависимости от различных опций влияющих на цену.
На счет событий: при отправке заказа нужно записывать заказ в CRM, при достижении какой-то суммы или какого-то количества делать скидку, при отправке прикреплять счет-фактуру. Вот последние несколько задач которые у меня были.
И на счет гитхаба — в том то и дело, что либо нужно вносить изменения в код, который затрется при обновлении, либо кидать ишью для одной конкретной задачи, что есть бред. То же касается различных шаблонов. У вас картинка должна быть названа img и не может быть multiTv и ресайзится будет строго 70x70.
Я вижу что код прост и лаконичен, но я не вижу возможности расширения без правки основного кода, а ведь именно это и есть логика MODX…
P.S. Я задаю все те вопросы, которые мы уже не раз обсуждали и в телеге, и пи личном общении с коллегами, а не критикую ради критики.
avatar
вы упустили первое предложение этого топика и его заголовок. это не комбайн, а простая базовая корзина, которую можно легко расширить как раз в prepare-сниппетах и чанках (это не основной код). и то, о чем вы говорите, что у меня зашито — зашито, это когда в ядре. а в prepare-сниппете вы вольны выводить, обрабатывать и пересчитывать как вам угодно. хоть из мультитв, хоть 150х10, хоть с внешнего сайта.

мультивалютность мне никогда не была нужна, поэтому тут все понятно для текущего релиза.
скидки можно получать при авторизации пользователя и загонять в сессию — она будет учтена
прикреплять счет-фактуру — нет проблем зааттачить что угодно к письму в formlister'e
записывать в crm — опять же в том же prepare от formlister'a ничто не мешает вам дописать строку записи в бд или постучаться на апи.
инициировать платежку оттуда же
Комментарий отредактирован 2018-09-12 12:07:15 пользователем arty
avatar
Переименуйте ваши prepare в .php.example и сделайте возможность подключения любых из них. Не будет тогда лишних вопросов.
На счет prepre для formLister — как я вижу у вас идет очистка сессии ДО вызова FL, а идентификатор новой строки (чтобы потом можно было вытащить из базы) нигде не сохраняется.
avatar
вы неправильно видите. оно выполняется внутри FL и все, о чем мы выше говорили вы должны выполнять как раз до очистки сессии корзины. отправка письма — это финальный шаг – который происходит после генерации файла и его аттача, после формирования платежки в платежной системе (чтобы вывести кнопку или типа того в чанк ответа FL), после простукивания api и так далее)

по-моему, вы не оч владеете prepare-параметрами…
Комментарий отредактирован 2018-09-12 12:27:51 пользователем arty
avatar
Переименуйте ваши prepare в .php.example и сделайте возможность подключения любых из них.
это так не работает, но в целом это раз то, о чем выше писал Pathologic – переписать на контроллеры
Комментарий отредактирован 2018-09-12 12:31:05 пользователем arty
avatar
Спасибо arty!!! Действительно все сделано просто доступно понятно и работает как нужно решая свою задачу. Смотрю, тестирую.

Не понимаю возгласы людей кто вечно чем то не доволен когда кто то выкладывает здесь свои решения для той или иной задачи, все не этак и не так им вечно, ну так раз такие умные выложите свое и не нужно бить по рукам тем кто старается внести хоть какой то свой вклад в evolution и делиться своими наработками. Все недовольные это банальные жлобы жадные в вечном негативе, прыскающие вечно свой яд везде от своей внутренней ущербности, глупости, тупости, жадности… Вот из за таких людишек в evolution все превращается в болото, потому что такие сами болото в своем нутре, и другим еще по рукам бьют и вечно всем не довольные…
avatar
Если это был камень в мой огород, то несколько моментов:
1) Я не говорил что решение плохое. Я спросил о его плюсах по сравнению с другими.
2) Я не увидел систему событий, которая для меня критична. Мой вопрос заключался в том что это я ее не увидел, или она как-то хитро сделана.
3) Я всегда поддерживал и поддерживаю любые решения в evolutionCMS. Пусть даже незначительные.
4) Мои решения вообще разносят в пух и прах (а не просто задают вопросы касательно их работы), при том что зачастую это действительно новые решения. Ничего, не обижаюсь же)
avatar
Здесь вечно так, сколько вон Сергей (64j) выкладывал решений своих и тоже негатив один лился в комментариях в лице некоторых людей что все не так да не этак работает видишь ли, типо зачем выложил такое и код не правильно написан не использована ООП и еще какой нибудь бред, когда надо всегда смотреть в суть всего (включая код) решает ли тот или иной код нужную задачу быстро просто и доступен для понимания дальнейшего и расширения, а не извращения в виде каких то там ООП в коде и прикапываться к этому… а решения отличные многими его решениями пользуюсь до сих пор, спасибо ему за его идеи и реализации, и что то под себя переписал…

Чем больше люди будут делиться своими наработками, даже если они написаны на ваш чей то взгляд как то не так, но задача решается быстро просто доступно, все эти разработки достойны быть и иметь право на жизнь как и все в этом мире, тем быстрее система evolution сделает мощный рывок в своем развитии.
Комментарий отредактирован 2018-09-12 10:59:15 пользователем diosmedia
avatar
«Здесь вечно так» — таки может быть, но а я то тут при чем?) А решениями Сергея мы все пользуемся)))
avatar
Объективная критика никогда не повредит (:
avatar
Еще бы пару скринов модуля было бы совсем хорошо
avatar
он пока слишком прост)


сейчас как раз делается для одного заказчика модуль с редактированием заказов и их сортировкой/фильтрацией. так что в последствии перенесется и сюда.
avatar
Прикольно :)

Правда хранить правила для скидок в сессии как-то не очень, мне кажется.

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

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

Само использование аббревиатуры dsq тоже смутило — надо смотреть код, вспоминать и т.п. — можно же назвать просто и понятно discount :)

По части модуля — тут как и во всех остальных модулях одна беда — управление заказами, в том числе их модификация и создание новых заказов админом в удобном виде.
Для экранирования в DocLister имеются собственные инструменты: &e=`pagetitle` и соответственно в чанке [+e.pagetitle+].
avatar
а что не так с сессией для скидок? подразумеваются или персональные (которые мы сразу закидываем в сессию при авторизации), или промо-коды (но это уже в корзине, и живут они столько же, сколько и сама корзина).

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

про модуль, как уже писал выше — редактор в планах )
avatar
а что не так с сессией для скидок?
Примерно то же, что и с хранением там цены, например, или отправкой цены товара в корзину прямо из формы :) Все это дело достаточно легко подменяется и потом придется продавать товар со скидкой 99.5% :) Именно поэтому в том же shk передается только id товара, а все манипуляции с ценой проводятся без доступа с фронта.
avatar
вы что-то пытаете или я туплю, но как пользователь может добраться до сессии?

у меня, если что, кроме id товара ничего больше и не передается во фронте
Комментарий отредактирован 2018-09-13 10:13:33 пользователем arty
avatar
у меня, если что, кроме id товара ничего больше и не передается во фронте
А можно ли как-то передать произвольные дополнительные параметры товара — например размер, цвет, материал и т.п. и изменить при необходимости цену товара в зависимости от переданных параметров?
avatar
передать можно что угодно через дата-аттрибуты (в доке об этом упомянуто). что касается их влияния на цену, то там те же замуты в prepare, что и с кол-вом – получить можно, но сложно и это надо упростить
avatar
Через data- часто не очень удобно, особенно когда надо дать выбор пользователю. К примеру — продаются духи и пользователь выбирает флакон 5мл или 10млн. Естественно, и цена разная и его выбор передать надо. Т.е. писать дополнительный js, который будет из селекта брать и писать в data-.
Да и насчет вывода этих доп параметров в корзине есть вопрос — когда товар однотипный, то использовать заранее известный [+data.color+] это конечно удобно и приятно. Но что если товар разный и заранее неизвестно какие именно параметры у товара будут выбраны. Т.е. неплохо бы организовать какой-то дополнительный цикл, который все эти дополнительные data просто выведет по определенному шаблону, а иначе снова все придется писать самому (а этим никто заниматься не будет :))
avatar
вы очень усложняете. я приму к сведению некоторые моменты, конечно. но если человеку сложно дописать 2 строчки кода в js, то видимо это решение ему не подойдет. никаких форм для добавления товаров типа шопкипера или твсшопа тут точно не будет.
avatar
Я вижу, вы не сильно настроены на конструктивное обсуждение, потому, пожалуй, оставлю вас наедине с вашим великолепным дополнением :)
avatar
а что вы понимаете под конструктивным обсуждением — делать все, что все говорят? я не хочу сделать из этого решения второй шопкипер, которым перестал пользоваться как раз по тем причинам, которые вы пытаетесь подать как крайне необходимые. и честно об этом сказал. отсутствие формы — критично? ну ок — всем не угодишь, благо есть другие решения. а ваша реакция странная – просите принимать ваше мнение, но на мое реагируете так себе…
Комментарий отредактирован 2018-09-13 12:42:15 пользователем arty
avatar
Здравствуйте.

Хорошая попытка — сам пользуюсь своими собственными скриптами магазина, так как толкового «обкатанного» решение для EVO нет, ShopKeeper уж больно монстрообразен и не обновляется.

Комплектации у товаров поддерживаются?
(Например: флакон малый стоит 500 рублей, флакон большой — 900 рублей?)
Доставка сохраняется как отдельный параметр заказа, или как услуга в корзине?

Без аякса работать может?
В таблицу заказов какие параметры попадают?
avatar
через дата-аттрибуты вы передаете параметры, которые можно будет принять и обработать в prepare выставив нужную цену, которая записана у вас в твшках (момент с «принять в prepare» надо еще дописать, потому что сейчас он неочевиден, хоть и возможен)
доставка сохраняется как параметр заказа (тип доставки отдельно, сумма доставки в json с составом заказа)
без аякса не может
структуру таблицы заказов можете посмотреть тут. в поле контент попадает json с товарами и всеми суммами по заказу, плюс все, что вам еще может пригодиться.
avatar
Судя по скриптам создания таблиц — отдельной таблицы для хранения заказаных товаров у вас нет — соответственно, сама информация о товарах у вас хранится в json или каком-то другом строковом формате? Чтобы к примеру поменять количество товаров в заказе — нужно распарсить этот формат и пересохранить заново?

Как производится статистическая обработка заказов — например, вам нужно посмотреть, сколько товара комплектации А, и сколько товара комплектации Б продано в течение полугода, и сколько товара С заказано на доставку в декабре — просто запросом в базу данных не получится сделать, сначала придется расшифровать все сохраненные заказы и только потом их обрабатывать?
Комментарий отредактирован 2018-09-14 08:47:20 пользователем Dreamer
avatar
mysql начиная с версии 5.7 позволяет работать с json.

1 запрос в бд и дальше распарсить json и накинуть кол-во для каждого товара из этого json можно в одном цикле. но если углубитесь в работу с json в mysql, возможно там есть и просчет сум, и группировки (я не сильно вникал в это за ненадобностью). в любом случае, все о чем вы пишите реализуемо.
avatar
Ну у меня в моих магазинчиках это реализовано хранением заказанных товаров в отдельной таблице — соответственно всякие подсчеты сумм по проданным товарам делаются просто.
Заказчики у меня в основном такие, которые любят всякого рода «отчеты по продажам» строить и анализировать что-нибудь там проданное или заказанное чуть ли не за весь текущий год.

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