Планы по разработке новой версии ShopModx озвучивались уже давно и не раз, и вот это время настало! Мы наконец-то приступили к разработке новой версии :)
Первая версия ShopModx вышла практически 3 года назад (первый коммит был опубликован 20-го февраля 2013-го года). За все это время в само ядро (а ShopModx является ядром для сборки ShopModxBox) был отправлен всего 21 коммит, большинство из которых являются незначительными. При чем за последние два года был всего один мелкий коммит. Это говорит в первую очередь о том, что ShopModx изначально имел грамотную и продуманную основу (а об основе мы действительно долго думали).
Но хотя ShopModx сам по себе за эти 3 года почти не развивался, мы-то не стояли в развитии на месте, выполнив на сборке ShopModxBox не один десяток проектов и проконсультировали/помогли еще большему количеству сторонних специалистов с их проектами. И вот сейчас мы хотим собрать воедино весь наш полученный за этот период опыт и выпустить обновленную версию ShopModx. Конечно же, мы попытаемся обеспечить максимальную обратную совместимость пакета с предыдущей версией (чтобы можно было, хоть и с правками, но все-таки накатить на ранее разработанные на ShopModxBox сайты), но в целом это будет абсолютно новая версия со значительными улучшениями/изменениями.
Вообще новая версия обещает быть очень крутой, хотя бы потому что мы ее готовим именно как альтернативу 1С-Битриксу, при чем не в теории, а на практике. Уже два месяца у нас на поддержке имеется весьма не маленький интернет-магазин на битриксе и есть ряд пожеланий со стороны клиента что хотелось бы доработать в магазине. Подробно про то, какие вещи больше всего расстраивают в битриксе, я напишу потом отдельной статьей, а пока же просто скажу, что, оценив тот объем работы, который необходимо выполнить и посчитав сколько это будет стоить на текущем битрикс-магазине, мы пришли к выводу, что все же дешевле получится переписать его на ShopModxBox с нуля, да еще и в дальнейшем развитие магазина будет обходиться значительно дешевле. И вот сейчас новая версия Shopmodx будет разрабатываться так, чтобы как минимум не уступать битриксу. Конечно, я не говорю про то, что мы вообще перепишем весь битрикс на MODX, но могу точно сказать, что тот функционал битрикса, который использует магазин клиента сейчас, мы перепишем в полной мере, и к нему еще кучу плюшек навешаем, так что для тех, кто будет думать делать ли магазин на битриксе или на чем-то другом, появится дополнительная весомая альтернатива битриксу.
Для начала мы постарались вычленить все плюсы и минусы предыдущей версии, в том числе и в рамках сборки ShopModxBox, и учесть их в новой версии ShopModx.
Плюсы.
- Корзина на базе данных. Вот это, на наш взгляд, самая убойная фишка ShopModx. Все создаваемые пользователями корзины изначально хранятся в БД. Если пользователь не авторизован, в сессии у него хранится только ID его корзины, но все равно сама корзина хранится в БД. В этом имеется масса весомых плюсов — это и отладка для программиста, и аналитика для маркетолога, да и пользователям удобней (даже если они не были авторизованы, они могут восстановить свою корзину хотя бы через менеджера).
- Шаблонизация Smarty.
- Производительность.
- Платежные системы.
- Гибкие выборки xPDO.
- Отладка.
- Мультивалютность.
Минусы.
- Не ставится на готовый сайт.
- Использует CRC.
- Отдельные контроллеры и процессоры для товаров.
- Сложность.
- Отсутствие документации.
- Ядро, биллинг и корзина вынесены в отдельные компоненты.
- Не оптимальное JS API.
- Отсутствие истории заказов.
- Отсутствие способов доставки.
Что мы хотим сделать в новой версии
1. Отказаться от CRC (расширяющих классов ресурсов)
CRC имеет кучу прикольных фишек и местами очень удобен, но есть, на мой взгляд, и серьезные минусы в его использовании. Один из таких минусов — слишком индивидуальная заточенность. Тут далеко ходить не надо: у нас в ShopModx есть ShopmodxResourceProduct (документ-товар) + ShopmodxProduct (данные товара), и в minishop тоже msProduct + msProductData. Каков итог такого подхода? Все просто — компоненты для минишопа работают чаще всего только под минишопом, а компоненты для шопмодикса работают только под шопмодиксом. Плюс к этому товаром может быть только специальный ресурс-товар. Вот как раз от этого мы и хотим уйти. Мы берем курс на бОльшую универсальность. То есть тот же биллинг шопмодикса должен вполне легко принимать минишоп-товары. Да и вообще товаром можно будет сделать любой документ, с любым полем, выступающим в качестве цены, даже если цена находится в связанном объекте.
Есть и еще один серьезный минус в парадигме использования CRC+дополнительный объект товара — элементарное неудобство в работе с объектами. Ведь $resource->price = $price; гораздо проще, чем $product_data = $resource->getOne(‘Data’); $product_data->price = $price;
2. Обеспечить большую универсальность.
Что лично мне не нравится в ShopModxBox? То, что все его технологии завязаны именно на нем же. Практически все знают, что для MODX есть три основных eCommerce-компонента: ShopModx, Minishop, ShopKeeper. У каждого есть свои плюсы/минусы, а главное — ни один из них не стоит на месте в развитии. И вот я думаю, что не должно быть очень жесткого выбора, что именно использовать для своего проекта — минишоп, шопкипер или что-то еще. Я предполагаю, что можно на одном проекте использовать и то, и другое. К примеру, уже сейчас можно получать одним и тем же кодом как данные минишоп-товаров, так и данные шопмодыкс-товаров.
Вот данные shopmodx-товара (который является обычным документом) joxi.ru/J2beE7ac4qonXm
А вот данные minishop-товара (точнее его связанного объекта msProductData) joxi.ru/brRDO4pfQB3qD2
В чем здесь выигрыш? Многие нам жалуются, что хотя у нашего движка есть серьезные технические преимущества, в том же минишопе есть также куча плюсов (включая удобное управление товарами в категориях, встроенная галерея и т.п.). Вот я считаю, что нам не надо стремиться переписать все, что есть в минишопе. Нам достаточно научить наш движок работать со всем, что есть в минишопе. Главное у нас — это биллинг, который мы сейчас планируем как следует прокачать. Таким образом, разработчик может взять наш eCommerce-механизм, и при этом использовать для редактирования товаров тот же минишоп (или это может быть просто обычный документ с указанием цен в TV-параметрах).
3. Включить billing и basket в само ядро ShopModx.
В текущей версии эти компоненты не входят в ядро. Так как изначально не было четкого видения как точно будут работать эти компоненты, было решено их вынести в отдельные модули. Идея была в том, что к шопмодиксу могут идти разные компоненты биллинга и корзины. Но так как эти два компонента все-таки очень сильно связаны с основной логикой модуля, и на смену им не появился ни один альтернативный компонент, то сейчас они будут отшлифованы и включены в само ядро. Логика их работы будет модифицироваться через дополнительные службы и плагины.
4. Добавить модуль способов доставок.
В большинстве проектов доставки нужны. Плюс к этому необходима централизованная логика способов доставок не только с самим заказом (влияние на его стоимость конечную), но и на выбор способов оплаты и прочие тонкости. Посему решено этот функционал доработать и включить в ядро.
5. Балансы.
Вот это вообще многие ждали и многим не хватало. Это не только возможность оплачивать товары/услуги с баланса, но и возможность организации накопительных систем скидок и т.п.
6. Скидки.
Вот что мне в битриксе нравится — так это как там реализованы скидки. Там предусмотрено практически все. Лично мое мнение — мы не сможем называть свой движок заменой битриксу, если не реализуем схожий скидочный функционал:)
7. Использовать Object-процессоры.
Object-процессоры наша довольно давняя разработка, но мы их пока официально нигде не светили. Вот сейчас они появятся в новой версии modxsite. Их-то и будет очень активно использовать ShopModx. Что это такое? В MODX есть процессоры (многие о них знают). В большинстве своем это специализированные процессоры под определенные действия: modObjectCreateProcessor — создание объектов, modObjectGetProcessor — получение объектов, modObjectUpdateProcessor — обновление объектов, modObjectRemoveProcessor — удаление объектов. Что здесь не так и что хотелось бы изменить? Собственно, разница между modObjectGetProcessor и modObjectUpdateProcessor только в том, что во втором процессоре, в общих чертах, выполняется обновление объекта $this->object->fromArray($this->getProperties()) и его сохранение $this->object->save(). Все остальное по сути то же самое. А между modObjectCreateProcessor и modObjectUpdateProcessor только в том, что в первом случае работа с новым объектом идет, а во втором с существующем. То есть собрать их в кучу — не особо большая проблема. А вот использовать их по отдельности часто бывает большая проблема. Почему? Вот у вас есть два процессора (на создание и обновление процессора). Работаете вы с одним и тем же объектом, и на создание, и на обновление этого объекта вам надо выполнять одни и те же проверки. Что тут получается? Или дублировать код и там и там (что крайне не круто), или делать, как это делается в самом MODX — инклюдить дополнительный класс-валидатор на создание и на обновление объекта. А вот теперь вам понадобилось изменить логику валидации объекта. Что делать? Переопределять код в двух отдельных процессорах. Согласитесь, это не хорошо.
Нам нужны ваши донейты!:)
Да, разработка предполагается в сжатые сроки и очень объемная. При этом в ядро важно запилить некоторые важные моменты, несколько выходящие за рамки потребностей текущего проекта клиента, и потому оплачиваются деньгами не клиента, а нашими собственными. Потому если кто-то уже использовал для себя нашу сборку, кто планирует и в дальнейшем ее использовать и не равнодушен к развитию ShopModx-а, присылайте нам свои донейты. Можно сделать это на спецстранице modxclub.ru/office/pyment/yandex/, или запросить у меня по почте n.lanets@modxclub.ru удобные вам реквизиты. Вместе с донейтами шлите и ваши вопросы/пожелания (лучше всего прям в топике, чтобы подключить коллективный разум). Пожелания донейтирующих будут учитываться в особом порядке. Но даже если вы не отпарвите нам никакой финансовой помощи (нет желания или возможностей, не важно), все равно пишите свои вопросы/пожелания в топике, не стесняйтесь, нам важно мнение каждого.
Кстати, Василий Наумкин на афтэпати в Минске тоже сделал свой донейт в пользу развития ShopModx:) Да, так и сказал “на развитие”. Хоть я тогда и напился не важно себя чувствовал, но это помню)))
Планы наполеоновские как всегда :) Так держать, ShopModxBox в каждый дом.
А как иначе? :)
Молодцы… Планы наполеоновские, но выполнимые вполне. Да и будущие владельцы оценят… удачи.
Вам спасибо за такие чудесные статьи и Ваш труд…
Николай, а что с первым пунктом миносов «Не ставится на готовый сайт.»? Будет ли решен этот вопрос?
Да. Это по сути главная задача, которую мы обязательно хотим решить. При чем должно быть не особо важно на чем каталог уже сделан — на минишопе, шопкипере, шопмодиксе или вообще документы+TV.
Вопрос на счёт политики распространения продукта — будет распространяться так же бесплатно, или как сейчас у многих вошло в моду — запилил бета-версию и сразу в магазин на продажу?
Все громогласно кричат надо популяризировать modx на территории России, и тут же закрывают свои разработки от использования — мне ваша текущая политика нравится, то что большинство ваших разработок можно опробовать бесплатно, и если нужен доп функционал, Вы всегда готовы помочь его реализовать за разумные деньги.
И совсем не нравится политика магазина modstore.pro где треть пакетов в бета-версиях с кучей недороботок, и авторы оказывают индивидуальную поддержку, только тем кто заплатил.
С таким подходом даже разрабатывать компоненты сложнее — коммитов нет, пулреквестов нет, все баги нужно искать самому — не эффективно.
Таким образом modx в нашей стране будет набирать популярность со скоростью черепахи и доверие у платежеспособных клиентов к этой системе появится в полной мере ещё не скоро.
Многие из моих клиентов на предложение сделать им сайт на modx — говорят — а что это? И после жалких попыток объяснить всю прелесть этой платформы они говорят давайте лучше на популярной cms wordpress или джумла или битрикс.
Вероятность появления платной версии ShopModx пока не рассматривается. Вряд ли эта политика поменяется.
На счет modstore.pro: обсуждение этого вопроса — это все холивары. Кому не нравится — проходят мимо. Кому нравится — пользуются. Кому-то это очень даже вариант. Мы вот тоже начали некоторые наши пакеты выкладывать туда и количество их увеличится. Не вижу причин почему так не делать.
Верно говорите — это всё холивары, а причина очень проста и я её уже указал в прошлом коменте, распространение, modx как серьёзного конкурента всем популярным cms, таким образом сильно тормозит, wordpress — лидер рынка, в свое время заслуживал свой авторитет сотнями тысяч бесплатных плагинов среди которых были и очень серьёзные разработки, поэтому спрос на него сейчас огромен, и уже на этом спросе теперь многие команды разработчиков делают платные продукты. А с modx получается всё наоборот, платформа ещё даже на слух у клиентов не воспринимается как что-то серьёзное, а уже все хоть сколько нибудь стоящие дополнения на старте становятся платными.
Семён, не вижу смысла это обсуждать. У меня совершенно другое видение этого. Не буду пытаться навязать свою точку зрения, но и слушать иное не готов сейчас, у меня другие данные.
Отличная новость!
И правильный, на мой взгляд, подход.
Внедрять слайдер или другие вкусности — это, на мой взгляд, лишнее. У каждого он свой любимый, да и от дизайна сильно зависит.
Поскольку shopmodx требует определенных навыков в программировании, то тем, кто с ним работает, довесить JS плюшки особого труда не составит.
Вполне достаточно гибкого, надежного и быстрого ядра и низкоуровневого, легко модифицируемого JS API.
Из конкретных пожеланий:
1. периодически приходится лезть в app.js и менять код. Скомпилировать его не всегда получается. Например, был случай — необходимо было изменить обработчик обновления корзины (после добавления товара).
Было бы очень неплохо, если бы была возможность просто вставить какую-нить функцию-заглушку в процедуры, обрабатывающие ответы ajax, а в своем проекте можно было бы эту функцию как-то переопределить или расширить, чтобы добавить к основному обработчику свой код, не меняя при этом код app.js
P.S.: Сейчас туговато с финансами, но как только что-то появится, обязательно закину на развитие этого очень полезного проекта :)
JS API полностью переписываем. И да, там будут события и т.п., что позволит модифицировать работу не залезая в мозги.
Планы хорошие!
Примерная дата выхода есть?
По пожеланиям, это боле менее хорошая документация нужна.
Из-за отсутствия ее в ShopModx пользуюсь ShopKeeper.
Установка shopmodxbox 2.7 из вашего репо выдает такую ошибку в логе установки:
Error 42S02 executing statement: Array ( [0] => 42S02 [1] => 1146 [2] => Table 'instance_c0609_modx.modx_modhybridauth_providers' doesn't exist ) Could not load package metadata for package modxsite.
Установка на облаке modxcloud, modx вер. 2.4.3.
При этом в конце все-таки установка завершается успешно.
Эти ошибки повлияют на работу сборки, это критично?
Куда лучше писать сообщения об ошибках, открывать новый топик или в комментариях, или есть какой-то другой способ?
После установки shopmodxbox 2.7 (модекс 2.4.3) не открывается sdk и управление заказами магазина. Выдает следующее:
Could not find action file at: /paas/c0609/www/core/components/modxsdk/controllers/index.php
При установке это не критично, просто таблицы нет, она устанавливается.
Удалите папку core/cache/, должно помочь.
shopmodxbox 2.7 (модекс 2.4.3)
Во вкладке «файлы» не отображается дефолтная файловая система «FileSystem». Как можно достучаться до полного дерева файлов модекса?
1. Лучше все-таки создать отдельный топик «У меня много вопросов и гуглить я не хочу». Здесь уже совсем флуд пошел.
2. Это бага MODX-а, смотрите дублированный «Basket assets»
Коля, привет! Меня мысль тут посетила — Если несложно будет, может быть, имеет смысл выложить список закладываемых обработчиков событий с кратким описанием — что делают. Я именно сейчас с магазином не работаю, и трудно с ходу сообразить, какие могут быть полезны. А так, если будет список перед глазами, может, я или кто еще что полезное предложит.
Спасибо за ответы! После ваших советов указанные выше проблемы устранены.
По поводу флуда. Не сразу разобрался что в меню Блоги есть разные тематики блогов, и там есть конкретно посвященный shopmoxbox2.7 раздел блогов. Буду внимательней! :)
Саша, привет!
Этим Сергей Прохоров у нас занимается. Он что-то там готовит с событиями.