Идеальный магазин. Часть вторая.

Почти всем спасибо большое за ответы, не понял только зачем и для чего ряд личностей, не будем называть по нику om1, написал ересь. Я даже когда бухаю не несу такой ереси. Но то такое.

Просмотрев ответы, я пришел к двум выводам.

1. Очень много ответов связанных не столько с модулем магазина, столько с организацией каталога. Например — каталог разделов товаров — отдельно, товары — отдельно, да, это хороший подход. И сириус же сделал отличные мультикатеории, но которые мало относя к самому магазину…
2. То что относится к магазину, не поверите, я делал на нашем SHk и почти без особых заморочек. И скидки. И синхронизации. И все что угодно.

Тем не менее я увидел ряд интересных предложений. Гит не покажу, пока не будет альфы, сорри. И у меня возник еще два вопроса.

Первый: а чем не устраивает SHk? По-пунктно.

Второй: Может знаете про ultron.pro? Да, не первый раз о нем пишу, но он реально крут. Так вот может имеет смысл заняться добавлением магазинов на Эво туда? И сделать хаб где будут различные пустые сборки магазина на bootstrap, что думаете?

P.S. Я сам бываю пишу ересь, но в комментах давайте не будем дуростью заниматься?

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

avatar
Для анализа сделать плагин и отдельную таблицу с изменением цены. Поля предлагаю такие IDPRODUCT — id товара(поле не уникальное), newprice — новая цена, time_newprice — время изменения, ID_USER — ID пользователя под которым изменилась цена, дополнительное поле с различной информацией типа цена изменена скhиптом и так далее. Магазин должен работать вне зависимости от этой таблицы — таблица только для анализа и по желанию. Для правильной работы автоматических скриптов изменяющих цену сделать свое событие которое добавляет изменения в таблицу.
avatar
НЕ читал первую часть сего обсуждения, но… Не вижу связи между непосредственной связью верстки и движка (MODx).
Компонентов достаточно много и вполне реально организовать ИМ на MODx с хорошим набором функций.
Как по мне надо просто сделать отдельный модуль (имеется ввиду сниппеты+модуль) для реализации. От Дмитрия был модуль в разработке и судя по скринам там всё очень грамотно, удобно и понятно было организовано должно было быть. Но релиз я так понимаю так и не состоялся((
SHK — хорош, но морально устарел по вполне понятным причинам. Хотя я по прежнему предпочитаю небольшие магазины делать на нём.
Я думаю с развитием 2.0.*(Laravel'ной) ветки сделать решение под коммерцию, да и давно назревает мысль делать не FREE решения, а как сейчас развивается REVO. Но понимаю что сейчас крайне сложно и затратно развивать на перспективу, нужны вложения и время.
avatar
Может стоит что-то готовое взять за основу?
Commerce, например.
А то магазинов на Эво уже штук 5 будет, не считая Шопкипера ))
avatar
Здравствуйте! Алексей — вы очень здорово все пишите — реально здорово, и классный спец. Часто тяжело разобраться в коде, чтобы переделать — это от простых юзеров голос подаю, тк с PHP на «Вы». С уважением к вашему труду и усилиям это пишу.
Вот по Шопкиперу старому был вопрос — не смог настроить, чтобы разные цены были в мультиязычном сайте в модуле Шипкипера — ведь в админке выставляется одна валюта магазина — она в модуле и показывается. Так-то это не для жалобы :)
Есть ли возможность в новом это предусмотреть?
Обязательно сделаю тест и постараюсь поучаствовать — может чего описать или тп простое сделать.
  • tmih
  • 0
avatar
Мое личное ИМХО:
Для развития оно конечно хорошо что-то переписывать и делать самому.
Но Commerce сейчас вне конкуренции. Непрост для первоначального понимания, но он уже далеко за тем, что было в SHK.
Без консолидации усилий разработчиков в одном направлении каждый будет пилить что-то свое.

Не хватает хорошего импорта. Это независимо от движка магаза. Который из того же YML распарсит категории, свойства, скачает изображения, будет хранить их сопоставление с теми, что есть в админке, сам периодически обновлять товары
avatar
Мне кажется, все упирается в отсутствие магазина дополнений. Импорт легче пишется под конкретную задачу, но на продажу такой модуль обязательно появился бы.
avatar
Первый: а чем не устраивает SHk? По-пунктно.
1). У него заведомо забит список полей — чтобы их исправить, надо лезть в код.
2). Убогая шаблонизация, для правки которой опять же надо лезть в код. Морально она устарела даже в сравнении с тем же DLTemplate классом, который все уже по-дефолту используют.
3) Нет связи с другими дополнениями. Хочешь избранное в личном кабинете — лезь в код. Мы давно пришли к тому, что личный кабинет — это не только магазин, а ещё и куча другого функционала: избранное, какие-то настройки, интеграция с сервисами, выгрузки, загрузки, редактирование чего-либо.

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

И, случись что дорабатывать, любой разраб без боли в заднице спокойно пробежится по шаблонам, дереву и вызовам стандартных сниппетов. Это проще, чем читать функционал shk_userprofile, который где-то кто-то в каком-то месте допилил. Серьёзно, я столько уже раз обжигался на этом (
Комментарий отредактирован 2019-11-22 09:20:22 пользователем 1px
  • 1px
  • +2
avatar
В итоге получаем, что кабинет проще и быстрее сделать ресурсами в дереве, закрыть доступ к ним ролями Эво, потом запилить для нужного функционала FormLister

О. А я думал, что я единственный извращенец, кто так делает :) Но у меня пошло дальше, у меня и «служебная» функциональность магазина так же сделана (всякие отчеты по продажам, остатки по складам, списки отгрузок/оплат и т.д.), так как в ресурсах все работает прекрасно, а вот еслив тот же модуль засунуть вызов DocLister-a, то начнутся проблемы и с формированием ссылок пагинации, и с шаблонзатором, и еще фиг знает чем…
avatar
Это не извращение, а прогресс и удобство. А вот каждый раз колупать функции shk_userprofile — как раз и есть подстава для других разработчиков.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.