Это демо-версия магазина. Если вы хотите поддержать проект, пишите на почту n.lanes@modxclub.ru.

Можно поделиться эфиром.

ShopModxBox - это бесплатный готовый интернет-магазин на базе MODX Revolution + React-js + GraphQL.

Все вопросы можно задавать на сайте modxclub.ru

Новости

Summary для MODX Revolution

В Ditto для MODX Evolution был классный плагин — summary. Если кто не в курсе — он позволял получать сокращенные анонсы из контента страницы. С тех пор, как я перешел на Рево, пожалуй, именно этой штуки мне всегда и не хватало (в его аналог getResources эта штука не попала). Кто-то не поверит, но за эти годы я так и не написал альтернативы этому, и не нашел альтернативный пакет (хотя может и плохо искал).

А вот сегодня я взял, и написал замену :-) Точнее, я не с нуля это написал, а просто взял код из этого плагина для Ditto, и чуть-чуть его переписал в виде процессора для MODX-а. Под катом код процессора и некоторые особенности.

В общем, этот функционал еще экспериментальный, и я его пока не планирую ни в какой пакет оформлять. Но вставил этот процессор в корневой процессор web/getdata. (про базовый процессор подробно писал здесь). После недолгой обкатки скорее всего включу его в сборку сайта.

Так вот, теперь в вызов процессора достаточно передать логическое summary=>true, и в массиве конечных ресурсов будут элементы ['summary'].

Полная статья: http://modxclub.ru/blog/research/164.html

Пре-релиз ShopModxBox-2.0.0

Всем, кто ждет с нетерпением новой сборки ShopmodxBox, на которую был анонсирован сбор средств: есть две новости (хорошая и плохая).

Плохая: скорее всего выпуск сборки задержится на пару-тройку дней.

Хорошая: основная причина — более обширный функционал, чем был анонсирован в топике. Я реанимировал свой давний самый крупный проект (что интересно, я уже там использовал Smarty, хотя это был конец 11-го года). В том проекте было много интересных плюшек, которые я и решил перенести в эту сборку. В частности, там была оплата не только через платежные системы (можно было даже использовать несколько штук одной и той же системы, к примеру несколько робокасс (зачем? Там у нас была мультидоменность и партнерская программа, и надо было чтобы на разных доменах оплата проходила через разные робокассы для разных владельцев)), но и оплата с баланса. А так же не только продажа, но и подписки (при чем на подписки можно было завести сколько угодно тарифных планов, с различными сроками действия, количеством включенной в пакет внутренней валютой и т.п.). В общем, там был полноценный биллинг. И вот этот биллинг я и решил перенести на ShopmodxBox. Само собой там тоже не было все идеально, в связи с чем это не пятиминутный перенос, а по сути переписка всего с нуля, просто тот проект помогает вспомнить какие ошибки были допущены и что можно было улучшить.

В итоге сразу хочу отметить, что новая сборка полностью переделана и обратной совместимости не имеет вообще. О таких вариантах говорилось изначально, но в данном случае хочу это отметить особенно, так как не только структура изменения претерпела, но и база данных.

Еще об изменениях: изменения в сборке реально кардинальные, и коснулись вообще всего, и главным образом корзины. Раньше корзина хранилась только в сессии, и в базу попадал только оформленный заказ. Здесь сразу несколько минусов есть, и главный для маркетологов — они не знают какие товары вызывали интерес, сколько было оформлено заказов, сколько не оформлено, какова конверсия и т.п. Так же если по какой-то причине сессия слетела (даже у авторизованного пользователя), то и корзина слетала. Сейчас есть куча вариантов в этом направлении, в том числе даже найти корзину не авторизованного пользователя, и передать ее ему, если он авторизовался. А если это был авторизованный пользователь, то он найдет свою корзину в личном кабинете в любой момент.
И вот как раз в этом и кроется причина многих изменений. Во-первых, чисто идеологически. Я долго думал над тем, чем же на самом деле является корзина, и пришел к выводу, что это по сути своей Заказ, только еще не оформленный (то есть статус у него Новый). И Корзину (с товарами) от полноценного Заказа отличает только статус Оформлен. При этом не следует плодить сущности и выполнять всякие метаморфозы (то есть, к примеру, в момент оформления заказа перекидывать товары из Корзины в Заказ и т.п.). И очистка Корзины — это смена статуса на Отменен. То есть сам заказ никуда не деется, он просто отменяется (меняется статус). Для маркетологов это опять-таки полезная информация, так как для оценки поведения клиентов важно понимать что они делают, чтобы потом понять почему они так делают.

В связи с этим, хочу сразу отметить, что мы берем курс на очень серьезное решение, в котором очень много всего будет уделено именно маркетингу. Это все равно как некоторые ЦМСки выделяют именно как SEO-friendly, потому что они не только управляют контентом, но и имеют какие-то инструменты для только, чтобы делать сайт более индексируемым. А мы вот плюс к этому будем пытаться делать так, чтобы магазин не просто работал (показывал товары), а имел серьезную маркетинговую составляющую.

А вот сейчас полезная информация в плане идеологической структуры сайта.

Главное: появляется новый компонент Billing, в котором содержится все, что связано с оплатами, счетами, заказами, контрагентами и т.п.

Итак, мы определили базовую сущность — Заказ (Order). У заказа есть Статусы (OrderStatus). Есть связка Заказ-Товар (OrderProduct). Вот с этим как раз и работает корзина. Сама корзина осталась отдельным компонентом Basket, но процессоры она вызывает из компонента Billing.

Далее, на заказ уже может быть сформирован счет (Invoice). Счета так же имею статусы (InvoiceStatus).

Оплата (Payment). Это один из самых сложных моментов, и не буду грузить сейчас всеми тонкостями проводок, оплатой сразу по нескольким счетам и т.п. В общем, пока делаем попроще (один платеж — один счет, без всяких там транзакций и т.д. и т.п.), но в дальнейшем будем биллинг постепенно развивать.
Так же Payment содержит информацию о том, через какую платежную систему был совершен платеж, ID счета в платежной системе и т.п.

В общем, все это — очень большой объем работ, и лучше подождать пару дней, и получить более комплексную сборку сразу, чем потом пытаться докинуть доработки (так как это будет сделать очень сложно, ибо все это — основа, и очень сложная. Там много изменений будет в самой базе данных и т.п.).

А в ShopmodxBox я постепенно хочу сделать еще больше функционала (само собой буду стараться, чтобы объем кода не был очень большой, и все было структурировано).

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

Кеширование результатов getdata-процессоров

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

Теперь в вызов процессора можно передать параметр cache=true, и тогда результат выполнения процессора будет закеширован. В дальнейшем при повторном вызове процессора данные будут получены из кеша.

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

Второе важное замечание: не следует кешировать данные, которые могут меняться в зависимости от авторизованного пользователя.

И еще замечание: если у вас включено кеширование, вы редактировали какие-то документы, а данные на странице не меняются, не забудьте очистить кеш сайта (в админ-панели Сайт -> Обновить сайт).

В текущей версии сборки пока кеширование включено только на новостях.

ShopModxBox-2.1.0

В новой версии:

  • Обновлен пакет shopModx до версии 0.2.0-beta.
  • Добавлено TV-поле keywords. Теперь легко можно указать ключевые слова для документа.
  • Полностью переписан класс  modMgrOrdersProductsAddProcessor компонента billing. Удален метод getInstance(). Теперь логика вызова Add- или Create- процессора выполнена прям в методе process() текущего класса. Это позволяет гораздо легче расширять логику на уровне классов.
  • Улучшен компонент basket:
    • Механизм корзины полностью переписан на основе базы данных. В сессии хранится только id заказа, и то исключительно для того, чтобы поддерживать механизм корзины для неавторизованных пользователей. Если пользователь авторизованный, то будет автоматически получен id его актуальной корзины. В остальном все данные хранятся в базе данных.
    • Созданы новые basket/web/orders/update и basket/web/orders/status/update процессоры. Вupdate-процессоре прописана проверка, действительно ли данный заказ принадлежит текущему пользователю.
    • Переписан процессор очистки корзины. Теперь дополнительно еще проверяется, чтобы статус корзины (заказа) был только 1 - то есть новый. После того, как он оформлен, ее уже нельзя очистить. В дальнейшем еще будет дописан процессор orders/cancel, чтобы пользователь имел возможность отменить уже оформленный заказ, но не взятый в работу менеджерами.
    • Все процессоры теперь не в папке processors/, а в папке processors/basket/. Это необходимо, чтобы не было конфликтов имен классов с процессорами других компонентов (например биллинга). Дело в том, что механизм MODX-а устроен так, что лучше использовать автоматически создаваемые имена классов (MODX имена генерирует). И если у нас процессоры будут лежать в одинаковых папках, но в разных модулях, то имена классов могут совпасть, и будет фатальная php-ошибка. А там процессоры именуются по маске modBasketWeb... и modBasketMgr...
      Старые процессоры оставлены для обратной совместимости, но они все помечены как _depricated. От их использования необходимо отказываться, изменив пути в вызовах процессоров.
      Обновляется basket простой заменой файлов.
      Внимание! Если вы  планируете обновлять текущую сборку ShopModxBox, готовьтесь к скорейшему изменению путей вызываемых процессоров компонента basket, так как в логи будут писаться ошибки об использовании устаревших процессоров.
      Если у вас возникнуть проблемы с обновлением имеющегося магазина на ShopModxBox-е, обращайтесь в MODX-Клуб , обязательно поможем.

 

P.S. Смотрите запись мастер-класса по новому модулю оформления заказов.

Новый модуль - Оплата через платежный агрегатор Единая Касса

В наш репозиторий выложил новый пакет - EdinayaKassa. Это дополнительный модуль оплаты для нашей сборки ShopModxBox. Таким образом, теперь на сайте можно использовать помимо Робокассы и Единую Кассу. В самое ближайшее время выйдет новый релиз ShopModxBox с уже установленным и настроенным компонентом EdinayaKassa, но если для тех, у кого уже работает наша сборка, под катом подробно опишу как установить и настроить этот компонент. Следует иметь ввиду, что данный компонент рассчитывался только для работы с ShopModxBox, так что если вы его хотите использовать отдельно, то он годится скорее только в качестве примера.

Установка и настройка компонента EdinayaKassa.

 

1. Регистрируемся в ЕдинойКассе. 2. Качаем из нашего репозитория и устанавливаем данный компонент.

 

 

 

 

3. Создаем документы для работы компонента. Особое внимание сразу же обратите на соответствие ID-шников спецдокументов в настройках. Само собой в настройки надо указывать актуальный ID. Так же имейте ввиду, что кроме валюты, все настройки будут пусты, их надо будет прописать самостоятельно.

 

 

3.1 В документ Result прописываем [[!edinayakassa.payResult]] Шаблон Пустой. Снимаем галочку "Использовать HTML редактор". 3.2 В документы Success и Failure прописываем произвольные сообщения об успешности или не успешности платежа. Шаблон Основной. Все эти три документа снимаем галочки "Доступен для поиска", чтоы в sitemap.xml не попадали. 4. В шаблон страницы оплаты сразу после {assign var=order value=$result.object[0]} дописываем подключение директории шаблонов модуля и вызов сниппета.

{$modx->smarty->addTemplateDir("{$modx->getOption('core_path')}components/edinayakassa/templates/web/default/")}
{snippet name="edinayakassa.getButton" params="&WMI_PAYMENT_AMOUNT=`{$order.sum}`&order_id=`{$smarty.get.order_id}`"}

Вообще Smarty хороша тем, что шаблоны можно переопределять. К примеру, в сниппете вызывается шаблон edinayakassa/button.tpl Так как он находится в папке шаблонов самого модуля EdinayaKassa, то нам и приходится указывать Smarty дополнительную директорию шаблонов.

{$modx->smarty->addTemplateDir("{$modx->getOption('core_path')}components/edinayakassa/templates/web/default/")}

Но, если вы создадите шаблон edinayakassa/button.tpl в основной директории шаблонов сайта, то будет использован ваш шаблон. Собственно, тогда можно и не подключать папку шаблонов EdinayaKassa. 5. Надо еще добавить в базу данных еще один платежный сервис (он будет учитываться в биллинге). Для этого заходим через PhpMyAdmin (или кто что использует) в базу данных, и в таблицу modx_billing_paysystems добавляем запись со значением name=EdinayaKassa.

 

 

Значение id новой записи указываем в системную настройку edinayakassa.bill_serv_id Ну и все. Если все правильно сделано, то на странице появится кнопка оплаты через ЕдинуюКассу.

 

 

Проект компонента на гитхабе: https://github.com/Fi1osof/EdinayaKassa