Pavel Zarubin

При сравнении «специализированных» cms для интернет магазинов и minishop заметил общую тенденцию у первых выводить при входе в админку список заказов. После недолгой переписки с замечательным исполнителем Павлом Гвоздем возникло такое замечательное и гениальное по простоте решение:
заходим в настройки системы, далее в фильтре по ключу отыскиваем 2 значения:
1. welcome_action меняем с welcome на mgr/orders
2. welcome_namespace с core на minishop2
и вуаля на чистом клиенте отображается список заказов, очень удобно

Часто ли вам приходится расширять какие-то стандартные штуки в MODX или в компонентах для него? Мне вот часто! Поэтому, давно хотелось поделиться чем-нибудь интересным на этот счёт, что я собственно и сделал в статье Дополнительные поля профиля юзера, где описал, как можно расширить профиль юзера, чтобы всё выглядело натурально. На этот раз расскажу, как можно расширять компонент Collections, не прибегая к крайним мерам, вроде правки исходников приложения.

Как и обещал, выкладываю инструкцию — как на основе сборки siteExtra сделать свою сборку. Скачать исходники можно на гитхабе https://github.com/ilyautkin/siteExtra. Полученный архив загружаем на сайт и распаковываем.

• 
• 

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

В качестве решения получился очень простой плагин, который выполняет 2 действия:
1) Сохраняет содержимое корзины в extended поля пользователя после каждого изменения корзины
2) Восстанавливает содержимое корзины перед каждой обработкой запрошенной страницы.

Благодаря статье Михаила Воеводского заметил, что тема резервного копирования востребована в сообществе. Решил поделиться своим скриптом резервного копирования написанным на Python. Примечателен он тем, что полностью удовлетворяет закону импортозамещения заливает файлы на Яндекс Диск, раскладывая их по папочкам вида ГГГГ-ММ-ДД. Это не все его приятные особенности, вот список:

• Умеет удалять старые бекапы с ЯДиска, если они старее чем N дней (настраивается в config.yaml)
• Умеет удалять старые логи с сервера
• Раскладывает бекапы на ЯДиске по папкам вида: ГГГГ-ММ-ДД
• Бекапит системные папки: /etc/, /var/log/, /root/

Разрабатываю проект, в котором необходимо было реализовать более простое редактирование дополнительных полей профиля, чем есть из коробки. К слову, неудобное редактирование — это не единственный минус нативного способа расширения профиля полями. Ни для кого не секрет, что фильтрацию по JSON полям нормально не осуществить, только костылями. Фактически, мне надо было получить решение, которое бы расширяло стандартный код MODX, не трогая исходники, дабы сохранить карму в порядке возможность обновления системы.
Пришёл к выводу, что буду расширять стандартную вкладку профиля «Общая информация». При желании можно чуть переписать код в событии OnUserFormPrerender и создать свою вкладку со своими полями.

Добрый день.
Продолжаю изучать написание компонентов c использованием modExtra. В своем компоненте хочу использовать выпадающий список со множественным выбором superboxselect.
Пытаюсь разобраться c его работой на примере minishop2.
Итак, изменил схему БД modExtra.
Две таблицы, в первой таблице добавил поле 'tags':

<field key="tags" dbtype="text" phptype="json" null="true" />

для хранения выбранных значений опции 'tags'.
Вторая таблица 'testOption' список этих опций:

<object class="testOption" table="test_options" extends="xPDOObject">
		<field key="test_id" dbtype="int" precision="10" attributes="unsigned" phptype="integer" null="false" />
		<field key="key" dbtype="varchar" precision="255" phptype="string" null="false" />
		<field key="value" dbtype="text" phptype="string" null="true" default="" />

		<index alias="option" name="option" primary="false" unique="false" type="BTREE" >
			<column key="test_id" length="" collation="A" null="false" />
			<column key="key" length="" collation="A" null="false" />
		</index>

		<aggregate alias="Item" class="testItem" local="test_id" foreign="id" cardinality="one" owner="foreign" />
	</object>

Пока только на примере одной опции 'tags'. Её для теста через PhpMyAdmin заполнил произвольными значениями.

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

Обычно использую office, который обеспечивает готовый личный кабинет из коробки с минимальными усилиями, он же позволяет сохранять все в базу, пользователей. Но вот беда, полей катастрофически не хватает. Логичным решением было создавать страницы для каждого пользователя, и добавлять сколько угодно TV. Так я и делал, но решил заморочиться и не дублировать страницы, а расширить таблицу пользователей и работать с ней напрямую, как с ресурсом.

Вот что я сделал:

Описан алгоритм для модуля интернет-магазина minishop2. Для других модулей алгоритм похож, но объекты отличаются.

Задача: сделать автоматический пересчет стоимости товаров в зависимости от общего количества товаров, находящихся в корзине.

$cartArray = $cart->get(); // Массив товаров в корзине
$cartProduct = $cartArray[$key]; // Один товар в корзине

Решение: пройти по всему массиву корзины и изменить цену товаров.

UPDATE 20.03.2018: Сниппет обновлён на корректный и добавлен pdoTools для обработки чанка.

Появилась задача реализовать облако тегов для удобства поиска товаров в интернет-магазине. Для этого сделал простенький сниппет, где теги собираются со всех товаров на сайте.



Сниппет умеет принимать параметры базового размера(font), шага в пикселях(step), количества размеров(levels) и чанка для вывода(tpl).

Алгоритм работы прост:
1. Собираются теги со всех товаров сайта.
2. Подсчитывается количество товаров для каждого тега.
3. Рассчитываются размеры для каждого уровня и границы по количеству использования тега.
4. Если не указан шаблон вывода, то на экране также будет облако тегов, но без ссылок.